Great, thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3413#issuecomment-1466312299
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #3413 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3413#event-8731951767
You are receiving this because you are subscribed to this thread.
Message ID:
@b4n approved this pull request.
This needs squashing, but apart from that, LGTM and WFM :+1:
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3413#pullrequestreview-1337076274
You are receiving this because you are subscribed to this thread.
Message
@b4n commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@techee commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@techee pushed 1 commit.
1adb0baec35b054eb6bce275b94a32589ddf4347 fixup! Improve code commenting-out
global config files
--
View it on GitHub:
https://github.com/geany/geany/pull/3413/files/94c3e110e1a9b5da60faaa81be42759d95365886..1adb0baec35b054eb6bce275b94a32589ddf4347
You are receiving
@b4n commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@b4n commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@techee commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
@techee commented on this pull request.
> @@ -2096,6 +2096,33 @@ void ui_table_add_row(GtkTable *table, gint row, ...)
}
+/* comment-out all lines that are not already commented out except sections */
+static void comment_conf_files(ScintillaObject *sci)
+{
+ gint line, line_count;
+
@b4n commented on this pull request.
> + gint pos_start = sci_get_position_from_line(sci, line);
+ gint pos_end = sci_get_position_from_line(sci, line + 1);
+ gint pos;
+
+ for (pos = pos_start; pos < pos_end; pos++)
+ {
+
> > > 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
>> 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
> 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
>
> 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…
Wait,
> 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.
Yeah, that provides no guidance to users.
> I think those are the ones showing up in filetypes definitions. E.g.
>
[read the thread]
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
:upside_down_face:).
* `# ` as documentation comments in conffiles is most common
* `#key=value` as commented-out
(FWIW, I didn't read everything yet nor looked at the implementation, but I
like the idea and it probably would have saved the author of #3425 some trouble)
--
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/3413#issuecomment-1462884540
You are receiving
> I just had a look at a few filetype's configurations and it's really a mixed
> bag of styles.
Thats the problem with software development that is contributed by lots of
different people :-D
I am not sure about the suggestion to document only in `filetypes.common`, in
one way I see your
I just had a look at a few filetype's configurations and it's really a mixed
bag of styles. I think it would make most sense to document all the config
options in `filetypes.common` _only_ and language-specific config files would
contain only those values they override to some other value than
> Looks good to me, and its simple, just add # to every line except headings.
And also except empty lines.
> I would not worry about the indented example, after adding a #, it is no
> longer an accurate example whichever way its done.
I actually don't think this is even a valid conf file
@techee pushed 1 commit.
94c3e110e1a9b5da60faaa81be42759d95365886 fixup! Improve code commenting-out
global config files
--
View it on GitHub:
https://github.com/geany/geany/pull/3413/files/766f756495e0704e7656773bdbf29f096ef45d16..94c3e110e1a9b5da60faaa81be42759d95365886
You are receiving
```
## set to false if a comment character/string should start at column 0 of a
line, true uses any
## indentation of the line, e.g. setting to true causes the following on
pressing CTRL+d
# #command_example();
## setting to false would generate this
## command_example();
## This
I wouldn't make the setting variable comments too similar to the actual
comments - they then become hard to distinguish, see:
```ini
# set to false if a comment character/string should start at column 0 of a
line, true uses any
# indentation of the line, e.g. setting to true causes the
The reference to the desktop spec was what I was looking for, wonder why that
doesn't appear in the docs, it used to? Unfortunately it is not explicit about
leading spaces either, but [the
docodementation](https://gitlab.gnome.org/GNOME/glib/-/blob/main/glib/gkeyfile.c#L1277)
says leading
@techee pushed 1 commit.
766f756495e0704e7656773bdbf29f096ef45d16 fixup! Improve code commenting-out
global config files
--
View it on GitHub:
https://github.com/geany/geany/pull/3413/files/d43357f8cf8d08abda80a767c462c778e3e60683..766f756495e0704e7656773bdbf29f096ef45d16
You are receiving
> Probably not to new users who are the ones fiddling with conf files, using #
> for a comment is "well known", but whats this #~ thing? And do I leave the ~
> or what? Have had all those during various support interactions.
This is definitely a good reason to use just the simple `#` then.
>
> Maybe it's a good idea also because it makes it more obvious which line was
> commented out.
Well with the current patch there are three types of lines, headings which are
uncommented, comments which are "# " commented and settings that are "#" no
space are commented[^1].
Probably not to
> Just a comment [Edit: pun intended :-)], the original concept was that it
> used the toggle comment marker so blocks of settings could just be toggled.
I could do it too with this patch too - right now the patch only inserts `#`
but it could also be `#~ `. Maybe it's a good idea also because
Just a comment, the original concept was that it used the toggle comment marker
so blocks of settings could just be toggled.
But `Edit->Format->Toggle line Commentation` is pretty well hidden and obscure
so that only experienced users know about it and they already have their
configs fettled
30 matches
Mail list logo
