I live in English speaking area. Even for me some way things are written and or words used doesn’t always make sense. I may know English but there are a lot of English words and terms i too don’t understand without some prior use or knowledge of them and or their meanings.
Then I was reassured that I wasn’t the only one who was so “clueless”. In addition, Google’s translation based on artificial intelligence often hinders rather than helps, in which case it is better to trust one’s own sense of language.
2 Likes
I think this is both harder to use conversationally and harder to understand. The use of “sign” here is very strange in English. “program lines” also seems like it doesn’t encompass many situations.
It is also incorrect since commenting works completely differently in various formats. It isn’t always accomplished by adding a single character or even by putting things at the beginning of the line.
This really doesn’t have to turn into a philosophical debate. 
To preserve some practicality, let’s summarize what we’ve learn so far so that we can all come to a consensus.
@zoli62 My friend, your mind is a truly beautiful thing because it possesses a great deal of curiosity and a strong desire to seek the truth, something that this society sorely lacks nowadays. For that, I commend you. 
And now, allow me to clarify why the practice of “leaving default settings of configurations as comments” came about. For this, let us take a concrete example; i.e, by looking at an actual configuration file.
On my system, the configuration file for lightdm (/etc/lightdm/lightdm.conf) looks something like this:
[Seat:*]
#
# General configuration
#
# start-default-seat = True to always start one seat if none are defined in the configuration
# greeter-user = User to run greeter as
# minimum-display-number = Minimum display number to use for X servers
# minimum-vt = First VT to run displays on
# lock-memory = True to prevent memory from being paged to disk
# user-authority-in-system-dir = True if session authority should be in the system location
# guest-account-script = Script to be run to setup guest account
# logind-check-graphical = True to on start seats that are marked as graphical by logind
# log-directory = Directory to log information to
# run-directory = Directory to put running state in
# cache-directory = Directory to cache to
# sessions-directory = Directory to find sessions
# remote-sessions-directory = Directory to find remote sessions
# greeters-directory = Directory to find greeters
# backup-logs = True to move add a .old suffix to old log files when opening new ones
# dbus-service = True if LightDM provides a D-Bus service to control it
#
[LightDM]
#start-default-seat=true
#greeter-user=lightdm
#minimum-display-number=0
#minimum-vt=7 # Setting this to a value < 7 implies security issues, see FS#46799
#lock-memory=true
#user-authority-in-system-dir=false
#guest-account-script=guest-account
#logind-check-graphical=true
#log-directory=/var/log/lightdm
run-directory=/run/lightdm
#cache-directory=/var/cache/lightdm
#sessions-directory=/usr/share/lightdm/sessions:/usr/share/xsessions:/usr/share/wayland-sessions
#remote-sessions-directory=/usr/share/lightdm/remote-sessions
#greeters-directory=$XDG_DATA_DIRS/lightdm/greeters:$XDG_DATA_DIRS/xgreeters
#backup-logs=true
#dbus-service=true
#
# Seat configuration
#
# Seat configuration is matched against the seat name glob in the section, for example:
# [Seat:*] matches all seats and is applied first.
# [Seat:seat0] matches the seat named "seat0".
# [Seat:seat-thin-client*] matches all seats that have names that start with "seat-thin-client".
#
# type = Seat type (local, xremote)
# pam-service = PAM service to use for login
# pam-autologin-service = PAM service to use for autologin
# pam-greeter-service = PAM service to use for greeters
# xserver-command = X server command to run (can also contain arguments e.g. X -special-option)
# xmir-command = Xmir server command to run (can also contain arguments e.g. Xmir -special-option)
# xserver-config = Config file to pass to X server
# xserver-layout = Layout to pass to X server
# xserver-allow-tcp = True if TCP/IP connections are allowed to this X server
# xserver-share = True if the X server is shared for both greeter and session
# xserver-hostname = Hostname of X server (only for type=xremote)
# xserver-display-number = Display number of X server (only for type=xremote)
# xdmcp-manager = XDMCP manager to connect to (implies xserver-allow-tcp=true)
# xdmcp-port = XDMCP UDP/IP port to communicate on
# xdmcp-key = Authentication key to use for XDM-AUTHENTICATION-1 (stored in keys.conf)
# greeter-session = Session to load for greeter
# greeter-hide-users = True to hide the user list
# greeter-allow-guest = True if the greeter should show a guest login option
# greeter-show-manual-login = True if the greeter should offer a manual login option
# greeter-show-remote-login = True if the greeter should offer a remote login option
# user-session = Session to load for users
# allow-user-switching = True if allowed to switch users
# allow-guest = True if guest login is allowed
# guest-session = Session to load for guests (overrides user-session)
# session-wrapper = Wrapper script to run session with
# greeter-wrapper = Wrapper script to run greeter with
# guest-wrapper = Wrapper script to run guest sessions with
# display-setup-script = Script to run when starting a greeter session (runs as root)
# display-stopped-script = Script to run after stopping the display server (runs as root)
# greeter-setup-script = Script to run when starting a greeter (runs as root)
# session-setup-script = Script to run when starting a user session (runs as root)
# session-cleanup-script = Script to run when quitting a user session (runs as root)
# autologin-guest = True to log in as guest by default
# autologin-user = User to log in with by default (overrides autologin-guest)
# autologin-user-timeout = Number of seconds to wait before loading default user
# autologin-session = Session to load for automatic login (overrides user-session)
# autologin-in-background = True if autologin session should not be immediately activated
# exit-on-failure = True if the daemon should exit if this seat fails
#
[Seat:*]
#type=local
#pam-service=lightdm
#pam-autologin-service=lightdm-autologin
#pam-greeter-service=lightdm-greeter
#xserver-command=X
#xmir-command=Xmir
#xserver-config=
#xserver-layout=
#xserver-allow-tcp=false
#xserver-share=true
#xserver-hostname=
#xserver-display-number=
#xdmcp-manager=
#xdmcp-port=177
#xdmcp-key=
greeter-session=lightdm-slick-greeter
#greeter-hide-users=false
#greeter-allow-guest=true
#greeter-show-manual-login=false
#greeter-show-remote-login=true
user-session=i3
#allow-user-switching=true
#allow-guest=true
#guest-session=
session-wrapper=/etc/lightdm/Xsession
#greeter-wrapper=
#guest-wrapper=
#display-setup-script=
#display-stopped-script=
#greeter-setup-script=
session-setup-script=~/.screenlayout/monitor.sh
#session-cleanup-script=
#autologin-guest=false
#autologin-user=
#autologin-user-timeout=0
#autologin-in-background=false
#autologin-session=
#exit-on-failure=false
Now, you can clearly see that many of these “comments” are really just the default settings that the programmer left as comments to make it more convenient for the users of his program to configure the application.
My friend, I implore you to put aside any linguistic/philosophical considerations for now and consider this scenario from a perspective of practicality. Suppose you want to start configuring an application, and that application is sophisticated in nature (it has dozens of configurable options, etc.). Which do you prefer?
Flipping back and forth between your favorite web browser (with the application’s documentation opened) and your text editor, checking the spelling and syntax of every configuration line you added so that the program doesn’t spit out a bazillion of confusing error messages because you screwed up the syntax or spelling or God knows what else?
Or opening the application’s configuration file to find that all the configurable options + their default values are already listed inside the config file in the form of comments. All you have to do to tweak that configuration is to simply delete a few characters to change that line from a comment to something that the application will read. You don’t even have to worry about the syntax/spelling/etc.
Bear in mind that programmers do this stuff to help users, not to confuse them. At the same time, we as users of applications also have the responsibility to be a bit more flexible in our thinking so that we can understand where the programmers are coming from. I mean, come on now. 
At the end of the day, does it really matter whether or not programmers leave the default settings of their applications as comments? This practice, like pretty much everything else in life, is merely a tool and every tool has its place depending on the situation. For programs that have lots of configurable options with long names, leaving them as comments might be a good idea. On the other hand, if the config file itself is too large, then leaving such comments might end up bloating the config file? In a way, it’s just like Design Patterns. Sometimes, an Abstract Factory is better than a Prototype, and vice versa. It all depends on the situation.
Therefore, I do not agree that this practice should be made universal/banned; the application’s creator and/or user should decide whether or not to adopt the practice.
I did expound on the structure of the phrase in my earlier post, but I think it’s worth reiterating so that everyone can see how intuitive and simple the phrase is to understand. Comment + out. The verb (comment) represents and action that removes something (the code containing the configuration) from a particular state (out). I’m sure everyone understands the term “kick someone out of the house?” When you kick someone out, you physically remove them from a place? Kick out. Comment out. They are a bit similar, right?
What I’m trying to say is that language really has very little to do with this, in my opinion. In my case, English is actually my second language; my native language is actually Chinese. The important thing here is to recognize the benefits of leaving default settings as comments and using comments to remove lines from config files. That’s all that matters if you think about it.
Anyway, I digress. Now, I’d like to wrap up this long essay of mine by pointing out the root cause of this “confusion.”
There. That’s the reason the OP disagrees with the semantics of “commenting out,” most probably because the OP misunderstood the role of config files. Consider what the OP was suggesting in those three statements. It seems to me like he was suggesting that the config file should contain ALL of the application’s configurable states for those states to be registered/recognized by the application. That if a particular line was removed from the config file (turned into a comment), then the configurable state should be gone. In other words, the OP assumed that a config file works like the application’s database file which stores the application’s state! Needless to say, a config file is NOT a database file that stores the application’s state. A config file is more like source code with lines of text that the application parses in order to read the user’s preferences; anything marked as a comment inside the config file will simply be ignored, and rightly so.
If config files really work like the OP suggested, then it would be far too easy for users to mess up the entire program by accidentally corrupting the application’s internal state.
Okay. 
Okay I’m going to comment it all out! ############## 
Edit: These posts will simply be ignored. 
I agree with this, different languages mark comments differently, so it’s not uniform either. However, there must still be some coherence.
“Commenting out” or “comment out” are phrases in standard usage. You can find the phrases used across forums for various linux distros.
https://forums.debian.net/viewtopic.php?t=146076
https://bbs.archlinux.org/viewtopic.php?id=125957
https://forums.linuxmint.com/viewtopic.php?t=177025
The phrase is pretty universal. If someone doesn’t understand what “comment out” means, they can always ask for clarification.
1 Like
To comment or uncomment … that is the question. 
2 Likes
I think it’s quite easy to help with this matter. If I accept what you say, then the programmer should start each line marked as a comment containing default settings after # by saying that the following settings are default interpretations, which you as a user can modify within certain limits. So: # #Default# Hello World=Hello World or # #Default# Linux_distribution=EndeavourOS etc.
Hmm? Or is it tag it or untag it? 
The phrase is also present in programming. It’s common for people to say that they “commented out” a few lines in the source code.
1 Like
A Shakespearean question.
No comment!
1 Like