IMO, just use one single # as you did at the start, and don't worry about the comment_use_indent comment comment comment (oops, got carried away 🙃).
# as documentation comments in conffiles is most common
#key=value as commented-out default/suggestion is common (many things in e.g. /etc do this)
## is a lot less common, so is #~ indeed.

OK.

The one thing you possibly could do is still add a leading # to the \t#comment line, e.g. "if line is an indented comment, add a documentation comment prefix", but that might be an overly specific case to warrant it, and special cases have a tendency to come back to bite you…

I don't think we should do anything about this in the code - but I think we should modify this comment in all the conf files so it already contains the leading # so we ship conf files with valid syntax. I'll create a separate PR for this.

Wait, if we don't need to handle leading whitespaces (which we don't need AFAIK, although it might be nice), the logic is merely if (*line && *line != '[' && *line != '#') comment();, isn't it?

Yes, but I also think we shouldn't add # on empty lines or lines containing only whitespaces.

Hum, I'm not sure it's a great idea. Some settings make sense to be modified per-filetype rather than necessarily globally, and I think those are the ones showing up in filetypes definitions. E.g. comment_use_indent: it's both a user preference, but also not all languages are happy about it, or their canonical style isn't. Similarly, wordchars has some use per-filetype, where identifiers are not limited to the usual (say, they contain - for example).
So yeah, there surely is room for improvement, but I don't think going whole "no non-overriden settings can ever be mentioned in filetype definitions" is the best move.

OK.

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.