> 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 or view it on GitHub: https://github.com/geany/geany/pull/3413#issuecomment-1465298474 You are receiving this because you are subscribed to this thread. Message ID: <geany/geany/pull/3413/c1465298...@github.com>
