Re: [Geany-devel] Changes to templates
On 21 March 2011 02:19, Colomban Wendling lists@herbesfolles.org wrote: Le 20/03/2011 00:09, Lex Trotman a écrit : Agreed. But supporting both single and multiline comments as a filetype setting seems still a good idea. I think it should go near the top of the to-do list. We have been talking about the technical reasons for using block or line comments, but there is also the local style reasons. Many places *require* that fileheaders and function descriptions be block comments. That means you can't insert nestable comments because there is only one setting. Done in r5609, I added new filetype setting comment_single, and use it in priority for ^E-style commands, and comment_open/close for templates. I also updated all filetypes.* to use this new setting. Great, well done, and you updated the documentation! +100 points Cheers Lex Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
Le 19/03/2011 00:55, Matthew Brush a écrit : On 03/18/11 14:10, Colomban Wendling wrote: we got two new lines. I'm not saying it's OK, just that this is logical (read ahead). I thought I had tested this exact scenario and it was still adding a newline, but like you said, it doesn't. As said, the code don't add new lines, though it's true the final result actually looks weird. What I propose is to strip the last implicit new line at the end of all the loaded template files if they have one. This would fix your issue (in an Unices world at least) IIUC. Do you (all) think it's OK to strip the last new line of the end of template files, since it's most likely to be an implicit new line? Knowing that it comes from the file itself, I'd like to reverse my opinion on this and say to leave it up to the template. What I think would be better, would be to modify the default license templates to not have any trailing newlines at all. This way it's exactly like in the text file and if someone wants to change it, and still not have the trailing newline, all they have to do is turn off the automatic newline feature of Geany and remove the newlines before saving. Well... I don't really feel comfortable having files without one trailing newline. Many tools consider a line being stuff\n, at least in the UNIX world, so... Do some others have an opinion on this? No, even if I hardly know Java, I doubt nesting C-style comments is valid in Java. Not sure why it's the default in the Java filetype... does Java support C++-style comments? AFAIK, all the languages where there is /* */ style comments in the filetypes.* files (except older versions of C) support C++ // style comments. What's more, AFAIK none of them allow nesting /* */ style comments. I'm not expert on any languages, let alone all these, but this seems to be the case. My opinion is that all applicable filetypes.* files should use // except CSS since it neither supports // style comments, nor nested comments, there is no hope for him :) I still don't think C should use // style comments for the reasons previously mentioned but I'll concede that it's more convenient in most cases and easy enough to change. Agreed. But supporting both single and multiline comments as a filetype setting seems still a good idea. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
Le 15/03/2011 23:15, Matthew Brush a écrit :
On 03/15/11 14:10, Colomban Wendling wrote:
Le 15/03/2011 21:08, Matthew Brush a écrit :
[...]
I noticed Geany's default templates end with 2 trailing newlines,
perhaps that should be changed to 1 to sort of split the difference?
Not sure I understand what you mean, sorry :/ Could you rephrase please?
I mean if you `cat data/templates/gpl`, by default it has a trailing
line (blank line at the end) and then Geany code adds another newline.
My issue is that even if your template only has 1 newline at the end,
Geany appends another one, so no matter what, it's not following what's
in the file exactly.
Actually, Geany *strips* one newline at the end of the finally-inserted
template. I know, regarding your example below (that is right), it might
sound weird, but let me show you:
A typical file on Unices *always* ends with a newline. So your templates
actually looks like:
first-line\nsecond-line\nlast-line\n
This is OK, no problem: Geany strips this last implicit new line.
But now, try including a template inside another template:
my_tpl:
first-line\nsecond-line\n
my_other_tpl:
first-line\n{my_tpl}\n
Took alone, both looks OK. But now, parse my_other_tpl as expected, so
including my_tpl:
first-line\nfirst-line\nsecond-line\n\n
...shit, we got two new lines. I'm not saying it's OK, just that this is
logical (read ahead).
It should be consistent, either read the file
exactly, and don't append a newline, or strip all trailing newlines and
append only the last one (to make sure */ ends up on its own line).
In case I'm still not clear on what I mean, I'll try to demonstrate:
[...]
So my idea is to 1) remove the 1 trailing newline from the template file
(personal preference, others might disagree)
I agree with this, I don't see why a license template would have an
extra newline at the end -- though it's not necessarily true with all
templates, for example in a function description template it would make
sense to have extra new lines at the end (or start) to include the
description.
and 2) make the code not add its own newline at the end (inconsistent,
if it should be exactly as in file).
As said, the code don't add new lines, though it's true the final result
actually looks weird.
What I propose is to strip the last implicit new line at the end of
all the loaded template files if they have one. This would fix your
issue (in an Unices world at least) IIUC.
Do you (all) think it's OK to strip the last new line of the end of
template files, since it's most likely to be an implicit new line?
Attached the possible patch, if you like to test it before.
Fix filetypes.c to use /* */ style comments rather than C++ style
comments.
I'd personally agree with this change, but it has a drawback:
multi-line
C comments can't be nested. So the comment/un-comment command becomes a
little less useful since it'd break if commenting stuff including
comments.
So it's ok in Java then? (I don't think it's valid in Java).
No, even if I hardly know Java, I doubt nesting C-style comments is
valid in Java. Not sure why it's the default in the Java filetype...
does Java support C++-style comments?
This is true, and I didn't think of this, however, I still don't agree
that for C filetype to insert invalid C code (by default).
C++-style single-line comments are not invalid in C. They are invalid in
ANSI C89 and ISO C90 (it's almost the same anyway), but totally valid in
ISO C99, and supported by most compilers (when not in strict C89/C90
conformance mode, of course).
I guess my point is that it should be lowest common denominator. Where
/* */ style comments are always valid, sometimes // comments are not. I
know it seems like a small problem, but it's really annoying having to
create a .java file from template, and copy its file header into the C
file, every single time I need a file header.
I've already given my POV on this: I think ^E should use // comments and
templates /* */ in C. It just need to be implemented.
Too bad C don't have D's /+ +/ comments ;(
But in the meantime (hopefully :D), I still think that it's important to
keep nestable comments by default for ^E (maybe because I use ^E to
temporarily comment stuff out and rarely to create true comments).
And moreover, I think that if you prefer /* */ comments it's not *this*
hard to change your filetypes.c accordingly (although it's a bit a
power-user thing, I agree).
3) backward compatibility would most probably be lost.
Not sure what you mean by this, but probably also good point :)
I mean that if somebody wrote his own templates, they wouldn't work at
all anymore (they'd miss the comment around); it'd not only be a few
newlines at the start or the end that would have changed.
The other thing I notice, since we're discussing it; shouldn't the
Python Function Description insert a triple-quoted docstrings below
the function def, not hash (#) comments
Re: [Geany-devel] Changes to templates
On 03/18/11 14:10, Colomban Wendling wrote: we got two new lines. I'm not saying it's OK, just that this is logical (read ahead). I thought I had tested this exact scenario and it was still adding a newline, but like you said, it doesn't. As said, the code don't add new lines, though it's true the final result actually looks weird. What I propose is to strip the last implicit new line at the end of all the loaded template files if they have one. This would fix your issue (in an Unices world at least) IIUC. Do you (all) think it's OK to strip the last new line of the end of template files, since it's most likely to be an implicit new line? Knowing that it comes from the file itself, I'd like to reverse my opinion on this and say to leave it up to the template. What I think would be better, would be to modify the default license templates to not have any trailing newlines at all. This way it's exactly like in the text file and if someone wants to change it, and still not have the trailing newline, all they have to do is turn off the automatic newline feature of Geany and remove the newlines before saving. No, even if I hardly know Java, I doubt nesting C-style comments is valid in Java. Not sure why it's the default in the Java filetype... does Java support C++-style comments? AFAIK, all the languages where there is /* */ style comments in the filetypes.* files (except older versions of C) support C++ // style comments. What's more, AFAIK none of them allow nesting /* */ style comments. I'm not expert on any languages, let alone all these, but this seems to be the case. My opinion is that all applicable filetypes.* files should use // except CSS since it neither supports // style comments, nor nested comments, there is no hope for him :) I still don't think C should use // style comments for the reasons previously mentioned but I'll concede that it's more convenient in most cases and easy enough to change. I think that if you prefer /* */ comments it's not *this* hard to change your filetypes.c accordingly (although it's a bit a power-user thing, I agree). I was being dramatic for effect :) 3) backward compatibility would most probably be lost. Not sure what you mean by this, but probably also good point :) I mean that if somebody wrote his own templates, they wouldn't work at all anymore (they'd miss the comment around); it'd not only be a few newlines at the start or the end that would have changed. Ah, OK, that makes sense. Maybe take a look at GeanyGenDoc, it should be able to do the right thing (just need to teach it with the appropriate configuration file, not done yet) -- and if it isn't able, file a bug report ;) I actually tried looking for this plugin in the Plugin Manager before posting about Python to see what it could do, but I couldn't find the plugin. I'll have to see why it's not building. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 16.03.2011 00:29, Lex Trotman wrote: Fix filetypes.c to use /* */ style comments rather than C++ style comments. I'd personally agree with this change, but it has a drawback: multi-line C comments can't be nested. So the comment/un-comment command becomes a little less useful since it'd break if commenting stuff including comments. My Geany comments C code with // so nesting can be infinite and that makes function headers as /* comments */ fine and works on C99 + compilers and the inserted function headers work on all compilers. When compilers won't let you use // to comment out blocks and you can't nest /* comments */ then thats a limitation of that version of the language and no matter what Geany does you will always have to comment around other comments. So I'd agree with Matthew that the built in functionality should support the lowest common denominator. FWIW, C99 is the current standard in effect, since more than a decade already, and thus //-style comments are perfectly valid. It's not Geany's fault if you can't use them. For CTRL+E, it's user configurable even, isn't it? Then I see no problem. But defaulting to //-style seems sane because it's very annoying to work around the nested comment problem. But for templates /* */-style should be used, I agree. Best regards. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 16 March 2011 20:57, Thomas Martitz thomas.mart...@student.htw-berlin.de wrote: On 16.03.2011 00:29, Lex Trotman wrote: Fix filetypes.c to use /* */ style comments rather than C++ style comments. I'd personally agree with this change, but it has a drawback: multi-line C comments can't be nested. So the comment/un-comment command becomes a little less useful since it'd break if commenting stuff including comments. My Geany comments C code with // so nesting can be infinite and that makes function headers as /* comments */ fine and works on C99 + compilers and the inserted function headers work on all compilers. When compilers won't let you use // to comment out blocks and you can't nest /* comments */ then thats a limitation of that version of the language and no matter what Geany does you will always have to comment around other comments. So I'd agree with Matthew that the built in functionality should support the lowest common denominator. FWIW, C99 is the current standard in effect, since more than a decade already, and thus //-style comments are perfectly valid. It's not Geany's fault if you can't use them. As above agree. For CTRL+E, it's user configurable even, isn't it? Then I see no problem. But defaulting to //-style seems sane because it's very annoying to work around the nested comment problem. IIUC its the filetype comment_open and (for multiline) comment_close options that set what ctrl-E uses, but those are also what are used to comment the templates. We need a new option to be able to separate /* commented */ templates and ctrl-E using // Cheers Lex But for templates /* */-style should be used, I agree. ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 03/16/11 02:57, Thomas Martitz wrote: On 16.03.2011 00:29, Lex Trotman wrote: For CTRL+E, it's user configurable even, isn't it? Then I see no problem. But defaulting to //-style seems sane because it's very annoying to work around the nested comment problem. So then Java and PHP and all the other filetypes should be changed to // style comments too, since they suffer from the same issue, except with them AFAIK, // comments are actually valid code in all versions of their languages, unlike say C and CSS. No matter what happens, CSS is always going to have problems when inserting comments where nesting will occur[1]. It's not such a huge deal since its easy for users to change to their preference, but it seems inconsistent to have the defaults be a strange mix of the two comment styles. The defaults, IMO, should be whatever style is idiomatic to each particular language, and my observation is that /**/ is far more widely used in C than C++ style // comments are. But for templates /* */-style should be used, I agree. Currently it's the same setting AFAIK (in filetypes.*) for both features. [1] http://www.w3.org/TR/CSS21/syndata.html#comments Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
Since there's an open thread for templates, i'll post my suggestion here. Is it possible to use a color for keywords in a specific language (const, var, public, private, protected, if, else etc.) and another for build in functions (like echo, print, substr in PHP and toString, toLowerCase in JavaScript etc.)? It would look nicer :) ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 03/15/11 09:54, Colomban Wendling wrote: Le 15/03/2011 04:12, Matthew Brush a écrit : [...] Make a constant for the amount of indentation used for template comments, so that they are consistent and also set to a more reasonable value of 3 instead of 8. Related to feature request: Specify spacing before fileheader - ID: 3193527[1]. Sounds good -- though, we may want to make this a setting at some point. Committed, renaming GEANY_TEMPLATES_HEADER_INDENT to GEANY_TEMPLATES_INDENT since it's not only for headers anymore. That makes sense. Strip all leading and trailing whitespace on the text read from template files. What if somebody *wants* whitepaces/newlines at the end of her template? I can easily imagine one wants this, for example for function descriptions [1] or whatever (it's seems to be the case with the Geany's default function template). Moreover, Geany's default templates seems to work OK without the patch, don't they? I noticed Geany's default templates end with 2 trailing newlines, perhaps that should be changed to 1 to sort of split the difference? I agree that in some cases it might not be desirable (I mentioned this concern in my initial message) to completely strip leading/trailing whitespace. Currently you just need to write your template carefully, with this change, it won't be possible at all. So... I'm not sure about this one. Fix filetypes.c to use /* */ style comments rather than C++ style comments. I'd personally agree with this change, but it has a drawback: multi-line C comments can't be nested. So the comment/un-comment command becomes a little less useful since it'd break if commenting stuff including comments. This is true, and I didn't think of this, however, I still don't agree that for C filetype to insert invalid C code (by default). Maybe a better fix would be to allow a filetype to define both single-line and multi-line comments, and use them when appropriate? (e.g. multi-lines comment for template comments, single-lines for ^E) Another way would be to let users embed the comments directly into the templates, and not have it done automatically by software, letting the user choose the indentation and comment style for those. There is still the issue Lex brought up about the encoding of the text being read from file and set into Scintilla. True, this should be fixed. I'll take a look at it. I think there's a function in documents.c called read_text_file (or similar), that if exposed in documents.h, could solve this issue. I only had a cursory glance though, so I could be mistaken. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 03/15/11 10:13, Росен Стоянов wrote: Since there's an open thread for templates, i'll post my suggestion here. Is it possible to use a color for keywords in a specific language (const, var, public, private, protected, if, else etc.) and another for build in functions (like echo, print, substr in PHP and toString, toLowerCase in JavaScript etc.)? It would look nicer :) If I understand the question properly, yes it's possible at least in some languages, for example in filetypes.c (or anything using CPP lexer), there's: [keywords] primary=built ins for example secondary=other things Then in the [styling] section, the 'word' key would be the style for 'primary' keywords, and the 'word2' would be the style for 'secondary' keywords. Like this: [styling] ... word=style for primary keywords ... word2=style for secondary keywords ... For PHP it might not work since the PHP lexer is mushed into the HTML lexer, and there's only 1 set of keywords available for PHP. At least this is my understanding. Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
Le 15/03/2011 21:08, Matthew Brush a écrit : On 03/15/11 09:54, Colomban Wendling wrote: Le 15/03/2011 04:12, Matthew Brush a écrit : Strip all leading and trailing whitespace on the text read from template files. What if somebody *wants* whitepaces/newlines at the end of her template? I can easily imagine one wants this, for example for function descriptions [1] or whatever (it's seems to be the case with the Geany's default function template). Moreover, Geany's default templates seems to work OK without the patch, don't they? I noticed Geany's default templates end with 2 trailing newlines, perhaps that should be changed to 1 to sort of split the difference? Not sure I understand what you mean, sorry :/ Could you rephrase please? Fix filetypes.c to use /* */ style comments rather than C++ style comments. I'd personally agree with this change, but it has a drawback: multi-line C comments can't be nested. So the comment/un-comment command becomes a little less useful since it'd break if commenting stuff including comments. This is true, and I didn't think of this, however, I still don't agree that for C filetype to insert invalid C code (by default). C++-style single-line comments are not invalid in C. They are invalid in ANSI C89 and ISO C90 (it's almost the same anyway), but totally valid in ISO C99, and supported by most compilers (when not in strict C89/C90 conformance mode, of course). Maybe a better fix would be to allow a filetype to define both single-line and multi-line comments, and use them when appropriate? (e.g. multi-lines comment for template comments, single-lines for ^E) Another way would be to let users embed the comments directly into the templates, and not have it done automatically by software, letting the user choose the indentation and comment style for those. I see 3 major problems at first glance: 1) comments are different in different languages (e.g. C and Python), would then need a template per language (please, no); 2) how would we nest templates without nesting comments? (e.g. fileheader includes gpl) 3) backward compatibility would most probably be lost. Cheers, Colomban ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 03/15/11 14:10, Colomban Wendling wrote:
Le 15/03/2011 21:08, Matthew Brush a écrit :
On 03/15/11 09:54, Colomban Wendling wrote:
Le 15/03/2011 04:12, Matthew Brush a écrit :
Strip all leading and trailing whitespace on the text read from template
files.
What if somebody *wants* whitepaces/newlines at the end of her template?
I can easily imagine one wants this, for example for function
descriptions [1] or whatever (it's seems to be the case with the Geany's
default function template).
Moreover, Geany's default templates seems to work OK without the patch,
don't they?
I noticed Geany's default templates end with 2 trailing newlines,
perhaps that should be changed to 1 to sort of split the difference?
Not sure I understand what you mean, sorry :/ Could you rephrase please?
I mean if you `cat data/templates/gpl`, by default it has a trailing
line (blank line at the end) and then Geany code adds another newline.
My issue is that even if your template only has 1 newline at the end,
Geany appends another one, so no matter what, it's not following what's
in the file exactly. It should be consistent, either read the file
exactly, and don't append a newline, or strip all trailing newlines and
append only the last one (to make sure */ ends up on its own line).
In case I'm still not clear on what I mean, I'll try to demonstrate:
In data/templates/fileheader:
start
{filename}
Copyright {year} {developer} {mail}
{gpl}
end
In data/tempalates/gpl:
start=
{filename}
...
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
MA 02110-1301, USA.
end
Notice, by default, there is 1 newline in the GPL template. So you
would expect the output comment block for fileheader to look like this:
start=
/*
* foo.c
* ...
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301, USA.
*
*/
end
But the actual output comment block looks like this:
start=
/*
* foo.c
* ...
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
* MA 02110-1301, USA.
*
*
*/
end
Notice the 2nd newline that gets added in here from somewhere. I hope
that makes sense.
So my idea is to 1) remove the 1 trailing newline from the template file
(personal preference, others might disagree) and 2) make the code not
add its own newline at the end (inconsistent, if it should be exactly as
in file).
Fix filetypes.c to use /* */ style comments rather than C++ style
comments.
I'd personally agree with this change, but it has a drawback: multi-line
C comments can't be nested. So the comment/un-comment command becomes a
little less useful since it'd break if commenting stuff including
comments.
So it's ok in Java then? (I don't think it's valid in Java).
This is true, and I didn't think of this, however, I still don't agree
that for C filetype to insert invalid C code (by default).
C++-style single-line comments are not invalid in C. They are invalid in
ANSI C89 and ISO C90 (it's almost the same anyway), but totally valid in
ISO C99, and supported by most compilers (when not in strict C89/C90
conformance mode, of course).
I guess my point is that it should be lowest common denominator. Where
/* */ style comments are always valid, sometimes // comments are not. I
know it seems like a small problem, but it's really annoying having to
create a .java file from template, and copy its file header into the C
file, every single time I need a file header.
Maybe a better fix would be to allow a filetype to define both
single-line and multi-line comments, and use them when appropriate?
(e.g. multi-lines comment for template comments, single-lines for ^E)
Another way would be to let users embed the comments directly into the
templates, and not have it done automatically by software, letting the
user choose the indentation and comment style for those.
I see 3 major problems at first glance:
1) comments are different in different languages (e.g. C and Python),
would then need a template per language (please, no);
Good point. It would at least have to be per lexer, which would be pain.
2) how would we nest templates without nesting comments? (e.g.
fileheader includes gpl)
Also good point. It would have to remove the comments first, then
insert the template, and then re-comment the whole thing. Probably more
work than it's worth.
3) backward compatibility would most probably be lost.
Not sure what you mean by this, but probably also good point :)
The other thing I notice, since we're discussing it; shouldn't the
Python Function Description insert a triple-quoted docstrings below
the function def, not hash (#) comments above the def? I don't think
the hash-style comments would be understood by Doxygen, Epydoc, or
Sphynx, for example, but I might be wrong. I'm pretty sure it won't end
up in the __doc__ attribute of the function
Re: [Geany-devel] Changes to templates
Hi Guys, But the actual output comment block looks like this: start= /* * foo.c * ... * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, * MA 02110-1301, USA. * * */ end Notice the 2nd newline that gets added in here from somewhere. I hope that makes sense. So my idea is to 1) remove the 1 trailing newline from the template file (personal preference, others might disagree) and 2) make the code not add its own newline at the end (inconsistent, if it should be exactly as in file). Now I understand your motivation, I would recommend your option 2 because it gives the user full control over what they get, otherwise they are forced to get what Geany builds in, which might not be what they want. Fix filetypes.c to use /* */ style comments rather than C++ style comments. I'd personally agree with this change, but it has a drawback: multi-line C comments can't be nested. So the comment/un-comment command becomes a little less useful since it'd break if commenting stuff including comments. My Geany comments C code with // so nesting can be infinite and that makes function headers as /* comments */ fine and works on C99 + compilers and the inserted function headers work on all compilers. When compilers won't let you use // to comment out blocks and you can't nest /* comments */ then thats a limitation of that version of the language and no matter what Geany does you will always have to comment around other comments. So I'd agree with Matthew that the built in functionality should support the lowest common denominator. So it's ok in Java then? (I don't think it's valid in Java). This is true, and I didn't think of this, however, I still don't agree that for C filetype to insert invalid C code (by default). C++-style single-line comments are not invalid in C. They are invalid in ANSI C89 and ISO C90 (it's almost the same anyway), but totally valid in ISO C99, and supported by most compilers (when not in strict C89/C90 conformance mode, of course). I guess my point is that it should be lowest common denominator. Where /* */ style comments are always valid, sometimes // comments are not. I know it seems like a small problem, but it's really annoying having to create a .java file from template, and copy its file header into the C file, every single time I need a file header. Agree. Maybe a better fix would be to allow a filetype to define both single-line and multi-line comments, and use them when appropriate? (e.g. multi-lines comment for template comments, single-lines for ^E) Another way would be to let users embed the comments directly into the templates, and not have it done automatically by software, letting the user choose the indentation and comment style for those. I see 3 major problems at first glance: 1) comments are different in different languages (e.g. C and Python), would then need a template per language (please, no); Agree with Colomban, no way. Good point. It would at least have to be per lexer, which would be pain. 2) how would we nest templates without nesting comments? (e.g. fileheader includes gpl) Also good point. It would have to remove the comments first, then insert the template, and then re-comment the whole thing. Probably more work than it's worth. Yes, Messy 3) backward compatibility would most probably be lost. Not sure what you mean by this, but probably also good point :) The other thing I notice, since we're discussing it; shouldn't the Python Function Description insert a triple-quoted docstrings below the function def, not hash (#) comments above the def? I don't think the hash-style comments would be understood by Doxygen, Epydoc, or Sphynx, for example, but I might be wrong. I'm pretty sure it won't end up in the __doc__ attribute of the function though. I'd agree that it should insert a docstring, but of course thats not a comment and not delimited by comment characters, hmmm. Cheers Lex Cheers, Matthew Brush ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
Sorry all, I've been having mail client issues, I hope this goes to the
list this time.
Cheers,
Matthew Brush (codebrainz)
Original Message
Subject:Re: [Geany-devel] Changes to templates
Date: Sun, 13 Mar 2011 11:53:46 -0700
From: Matthew Brush matthewbr...@gmail.com
To: Lex Trotman ele...@gmail.com
On 03/13/11 03:19, Lex Trotman wrote:
I don't think this is a good idea since g_strstrip() doesn't actually
change the size recorded in the GString, it might appear to work
sometimes but it might also fail. Note that a GString also does not
have to be null terminated so the g_strstrip might write beyond the
buffer if you are unlucky. I think you are better not to do this.
I have updated the patch (see attachment) to be more safe, based on your
comments. I'm not 100% confident this is the Best Way, but maybe if
someone has time to review the way it's being done, they could fix it or
suggest the best way. My idea is to allocate a buffer filled with
zeroes, one bigger than the -len size, copy the -str member into the
new buffer, except its nul char, and the new buffer is sure to have at
least a nul at the end. After, the new buffer is stripped of whitespace
and split into lines. From reading the GString docs, it sounds like the
-str member *is* always nul terminated, but this way is safe even if it
isn't, I think.
Is this better? Overkill? Stupid?
Cheers,
Matthew Brush (codebrainz)
Index: src/templates.c
===
--- src/templates.c (revision 5587)
+++ src/templates.c (working copy)
@@ -506,12 +506,22 @@
prefix = g_strconcat(line_prefix, tmp, NULL);
g_free(tmp);
+ /* try to strip the comment_text */
+ tmp = g_try_malloc0(comment_text-len + 1);
+ if (tmp != NULL)
+ {
+ memcpy(tmp, comment_text-str, comment_text-len);
+ lines = g_strsplit(g_strstrip(tmp), template_eol_char, -1);
+ g_free(tmp);
+ }
+ else
+ lines = g_strsplit(comment_text-str, template_eol_char, -1);
+ len = g_strv_length(lines);
+
/* add line_prefix to every line of comment_text */
- lines = g_strsplit(comment_text-str, template_eol_char, -1);
- len = g_strv_length(lines);
if (len 0) /* prevent unsigned wraparound if comment_text is empty */
{
- for (i = 0; i len - 1; i++)
+ for (i = 0; i len; i++)
{
tmp = lines[i];
lines[i] = g_strconcat(prefix, tmp, NULL);
@@ -527,7 +537,7 @@
if (frame_start != NULL)
g_string_append(comment_text, frame_start);
/* add the new main content */
- g_string_append(comment_text, tmp);
+ g_string_append_printf(comment_text, %s%s, tmp, template_eol_char);
/* add frame_start */
if (frame_end != NULL)
g_string_append(comment_text, frame_end);
@@ -549,7 +559,7 @@
templates_replace_default_dates(template);
templates_replace_command(template, DOC_FILENAME(doc), doc-file_type-name, NULL);
- make_comment_block(template, doc-file_type-id, 8);
+ make_comment_block(template, doc-file_type-id, GEANY_TEMPLATES_HEADER_INDENT);
convert_eol_characters(template, doc);
return g_string_free(template, FALSE);
@@ -566,9 +576,9 @@
{gpl}, templates[GEANY_TEMPLATE_GPL],
{bsd}, templates[GEANY_TEMPLATE_BSD],
NULL);
-
+
/* we don't replace other wildcards here otherwise they would get done twice for files */
- make_comment_block(template, ft-id, 8);
+ make_comment_block(template, ft-id, GEANY_TEMPLATES_HEADER_INDENT);
return g_string_free(template, FALSE);
}
@@ -625,7 +635,7 @@
templates_replace_default_dates(text);
templates_replace_command(text, DOC_FILENAME(doc), doc-file_type-name, func_name);
- make_comment_block(text, doc-file_type-id, 3);
+ make_comment_block(text, doc-file_type-id, GEANY_TEMPLATES_HEADER_INDENT);
convert_eol_characters(text, doc);
return g_string_free(text, FALSE);
Index: src/templates.h
===
--- src/templates.h (revision 5587)
+++ src/templates.h (working copy)
@@ -30,6 +30,8 @@
#ifndef GEANY_TEMPLATES_H
#define GEANY_TEMPLATES_H 1
+#define GEANY_TEMPLATES_HEADER_INDENT 3
+
enum
{
GEANY_TEMPLATE_GPL = 0,
Index: data/filetypes.c
===
--- data/filetypes.c (revision 5587)
+++ data/filetypes.c (working copy)
@@ -47,11 +47,11 @@
#wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
# if only single comment char is supported like # in this file, leave comment_close blank
-comment_open=//
-comment_close=
-# this is an alternative way, so multiline comments are used
-#comment_open=/*
-#comment_close=*/
+comment_open=/*
+comment_close=*/
+# this is an alternative way, so single line comments are used
+#comment_open=//
+#comment_close=
# 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
[Geany-devel] Changes to templates
Hi,
I wasn't sure if I should make a feature request or a bug report, so if
needed, let me know which and I'll file it on the project site.
The patch attached to this message does a few things, sorry I didn't
split them into different patches, but it's so small and related that
it's hardly worth it.
Here's what the patch does:
#1
--
Makes the indent parameter value used for calls to make_comment_block()
a global, so that it's settable from a single location. It also makes
it 3 instead of 8, where before it was 3 for function templates, and 8
for license and fileheader. I guess it's a matter of taste on this
value, but IMHO, 8 is just too much. This is related to feature request
'Specify spacing before fileheader - ID: 3193527'[1].
#2
--
Strips whitespace from the start and end of the templates before passing
to make_comment_block() so that trailing newlines are consistent. I'm
not sure if this is desired or not, but I think the resulting comment
looks better than before where there was 2 empty comment lines before
the closing */. I'm also not sure if the 3 calls to g_strstrip() should
be just a single call inside the make_comment_block() function. Also,
not being very familiar with GString, I'm not 100% sure if calling
g_strstrip() on the -str member behind its back is OK, but it seems
fine since g_strstrip() changes the string in place without changing the
amount of memory used.
#3
--
Change filetypes.c to use /* */ style comments rather than // style, to
prevent those ISO C90 warnings from GCC. It's probably best to make the
default for C not be C++ style comments.
With the small amount of testing I've done, it seems to all work fine.
[1]
https://sourceforge.net/tracker/?func=detailaid=3193527group_id=153444atid=787794
Cheers,
Matthew Brush (codebrainz)
Index: src/templates.c
===
--- src/templates.c (revision 5587)
+++ src/templates.c (working copy)
@@ -511,7 +511,7 @@
len = g_strv_length(lines);
if (len 0) /* prevent unsigned wraparound if comment_text is empty */
{
- for (i = 0; i len - 1; i++)
+ for (i = 0; i len; i++)
{
tmp = lines[i];
lines[i] = g_strconcat(prefix, tmp, NULL);
@@ -527,7 +527,7 @@
if (frame_start != NULL)
g_string_append(comment_text, frame_start);
/* add the new main content */
- g_string_append(comment_text, tmp);
+ g_string_append_printf(comment_text, %s%s, tmp, template_eol_char);
/* add frame_start */
if (frame_end != NULL)
g_string_append(comment_text, frame_end);
@@ -549,7 +549,9 @@
templates_replace_default_dates(template);
templates_replace_command(template, DOC_FILENAME(doc), doc-file_type-name, NULL);
- make_comment_block(template, doc-file_type-id, 8);
+ g_strstrip(template-str);
+
+ make_comment_block(template, doc-file_type-id, GEANY_TEMPLATES_HEADER_INDENT);
convert_eol_characters(template, doc);
return g_string_free(template, FALSE);
@@ -566,9 +568,11 @@
{gpl}, templates[GEANY_TEMPLATE_GPL],
{bsd}, templates[GEANY_TEMPLATE_BSD],
NULL);
+
+ g_strstrip(template-str);
/* we don't replace other wildcards here otherwise they would get done twice for files */
- make_comment_block(template, ft-id, 8);
+ make_comment_block(template, ft-id, GEANY_TEMPLATES_HEADER_INDENT);
return g_string_free(template, FALSE);
}
@@ -625,7 +629,9 @@
templates_replace_default_dates(text);
templates_replace_command(text, DOC_FILENAME(doc), doc-file_type-name, func_name);
- make_comment_block(text, doc-file_type-id, 3);
+ g_strstrip(text-str);
+
+ make_comment_block(text, doc-file_type-id, GEANY_TEMPLATES_HEADER_INDENT);
convert_eol_characters(text, doc);
return g_string_free(text, FALSE);
Index: src/templates.h
===
--- src/templates.h (revision 5587)
+++ src/templates.h (working copy)
@@ -30,6 +30,8 @@
#ifndef GEANY_TEMPLATES_H
#define GEANY_TEMPLATES_H 1
+#define GEANY_TEMPLATES_HEADER_INDENT 3
+
enum
{
GEANY_TEMPLATE_GPL = 0,
Index: data/filetypes.c
===
--- data/filetypes.c (revision 5587)
+++ data/filetypes.c (working copy)
@@ -47,11 +47,11 @@
#wordchars=_abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
# if only single comment char is supported like # in this file, leave comment_close blank
-comment_open=//
-comment_close=
-# this is an alternative way, so multiline comments are used
-#comment_open=/*
-#comment_close=*/
+comment_open=/*
+comment_close=*/
+# this is an alternative way, so single line comments are used
+#comment_open=//
+#comment_close=
# 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
___
Geany-devel mailing list
Geany-devel@uvena.de
Re: [Geany-devel] Changes to templates
On 13 March 2011 19:18, Matthew Brush matthewbr...@gmail.com wrote: Hi, I wasn't sure if I should make a feature request or a bug report, so if needed, let me know which and I'll file it on the project site. The patch attached to this message does a few things, sorry I didn't split them into different patches, but it's so small and related that it's hardly worth it. Here's what the patch does: #1 -- Makes the indent parameter value used for calls to make_comment_block() a global, so that it's settable from a single location. It also makes it 3 instead of 8, where before it was 3 for function templates, and 8 for license and fileheader. I guess it's a matter of taste on this value, but IMHO, 8 is just too much. This is related to feature request 'Specify spacing before fileheader - ID: 3193527'[1]. #2 -- Strips whitespace from the start and end of the templates before passing to make_comment_block() so that trailing newlines are consistent. I'm not sure if this is desired or not, but I think the resulting comment looks better than before where there was 2 empty comment lines before the closing */. I'm also not sure if the 3 calls to g_strstrip() should be just a single call inside the make_comment_block() function. Also, not being very familiar with GString, I'm not 100% sure if calling g_strstrip() on the -str member behind its back is OK, but it seems fine since g_strstrip() changes the string in place without changing the amount of memory used. I don't think this is a good idea since g_strstrip() doesn't actually change the size recorded in the GString, it might appear to work sometimes but it might also fail. Note that a GString also does not have to be null terminated so the g_strstrip might write beyond the buffer if you are unlucky. I think you are better not to do this. #3 -- Change filetypes.c to use /* */ style comments rather than // style, to prevent those ISO C90 warnings from GCC. It's probably best to make the default for C not be C++ style comments. Sounds a good idea. With the small amount of testing I've done, it seems to all work fine. I havn't the chance to test it, but so long as you don't muck up my personalised templates its ok :-) Cheers Lex [1] https://sourceforge.net/tracker/?func=detailaid=3193527group_id=153444atid=787794 Cheers, Matthew Brush (codebrainz) ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 14 March 2011 05:53, Matthew Brush matthewbr...@gmail.com wrote: On 03/13/11 03:19, Lex Trotman wrote: I don't think this is a good idea since g_strstrip() doesn't actually change the size recorded in the GString, it might appear to work sometimes but it might also fail. Note that a GString also does not have to be null terminated so the g_strstrip might write beyond the buffer if you are unlucky. I think you are better not to do this. I have updated the patch (see attachment) to be more safe, based on your comments. I'm not 100% confident this is the Best Way, but maybe if someone has time to review the way it's being done, they could fix it or suggest the best way. My idea is to allocate a buffer filled with zeroes, one bigger than the -len size, copy the -str member into the new buffer, except its Well it looks like it will work, but see below. nul char, and the new buffer is sure to have at least a nul at the end. After, the new buffer is stripped of whitespace and split into lines. From reading the GString docs, it sounds like the -str member *is* always nul You're right, it is guaranteed to be nul terminated. terminated, but this way is safe even if it isn't, I think. Is this better? Overkill? Stupid? Sorry to do this to you Matthew, but I think that there is a problem with the original code and I think that might also bite you. It seems to me that the assumption is that the template file encoding is UTF-8 or ASCII (as a subset of UTF-8) as its contents are just pasted straight into the Scintilla buffer. The standard templates are ASCII, but it may not be true for user defined templates, for instance Enrico has non-ASCII characters in his name. I am not sure how well the g_str and g_string functions work in this case. Can someone with more understanding of such things comment. Should the templates be passed through encodings_convert_to_UTF_8? Cheers Lex Cheers, Matthew Brush (codebrainz) ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Re: [Geany-devel] Changes to templates
On 03/13/11 20:23, Lex Trotman wrote: It seems to me that the assumption is that the template file encoding is UTF-8 or ASCII (as a subset of UTF-8) as its contents are just pasted straight into the Scintilla buffer. The standard templates are ASCII, but it may not be true for user defined templates, for instance Enrico has non-ASCII characters in his name. I am not sure how well the g_str and g_string functions work in this case. Can someone with more understanding of such things comment. Should the templates be passed through encodings_convert_to_UTF_8? I don't know much about encodings, but I can definitively observe some strange things by loading non-UTF8 encoded files as the templates. Cheers, Matthew Brush (codebrainz) ___ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
