Hi,
I'm terribly sorry for re/top/whatever posting, I've had serious issues using GMail with the mailing list, so I've switched accounts and unsubscribed my GMail account. Please see the other thread (or this one if all goes well) for context.
I've updated the patch based on feedback I've received and updated knowledge I've acquired about GString (namely that it's not just a skimpy garment).
Effects of the patch:
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].
Strip all leading and trailing whitespace on the text read from template files.
Fix filetypes.c to use /* */ style comments rather than C++ style comments.
There is still the issue Lex brought up about the encoding of the text being read from file and set into Scintilla.
Thanks for your time. Please ask any questions needed, and as always feel free to tell me if I've done something stupid.
[1] https://sourceforge.net/tracker/?func=detail&aid=3193527&group_id=15...
Cheers, Matthew Brush (codebrainz)
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.
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? 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. 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)
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.
Cheers, Colomban
[1] though they should use GeanyGenDoc plugin in this particular case :D
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 :)
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
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
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
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:
- 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.
- 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.
- 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.
Cheers, Matthew Brush
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:
- 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.
- 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
- 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
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.
On 16 March 2011 20:57, Thomas Martitz thomas.martitz@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.
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
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).
- 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 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.
This may be fixed by supporting two comment types per filetype, one single-line (or at least nestable) to use with ^E, and one for multi-line comments. Though, it wouldn't probably be enough for Python since you still want to use sharp-comments in e.g. fileheader but triple-quote-strings as comments for doc... 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 ;)
Cheers, Colomban
Hi Colomban,
[..]
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.
I think its ok to strip only one newline, then people who actually do want extra blank lines in their templates can still have them, they just have to remember one gets stripped.
Only comment on the patch is that you have swapped the order of frame_end and template_eol_char at the end of the template. (compare lines 21 and 67/68 of the patch)
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?
/* comments */ don't nest and it does support //
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.
Agree, but needs two separate options.
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).
I'm not sure we should consider changing a config file too power-user, after all the assumption is that *all* users are programmers of some type.
- 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.
Agree
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.
This may be fixed by supporting two comment types per filetype, one single-line (or at least nestable) to use with ^E, and one for multi-line comments. Though, it wouldn't probably be enough for Python since you still want to use sharp-comments in e.g. fileheader but triple-quote-strings as comments for doc...
Yes we need a separate template_comment_open and template_comment_close in filetypes.*.
After some consideration I think that docstrings are not comments so they should not be inserted by "insert comments".
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 ;)
But docstrings can be handled by your friendly plugin :-)
Cheers Lex
Le 18/03/2011 23:52, Lex Trotman a écrit :
Hi Colomban,
[..]
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.
I think its ok to strip only one newline, then people who actually do want extra blank lines in their templates can still have them, they just have to remember one gets stripped.
Yep, and the idea of stripping one being that most editors add it implicitly, at least on Unices.
Only comment on the patch is that you have swapped the order of frame_end and template_eol_char at the end of the template. (compare lines 21 and 67/68 of the patch)
It was indented actually (not as swapping though): * I added a line before the frame_end since the template no longer have a trailing new line. * I removed the newline after because it added implicitly an extra newline in e.g. template files (main.c, etc.) after the comment, but maybe we better keep it (e.g. inserting a template comment adds a new line); not sure.
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).
I'm not sure we should consider changing a config file too power-user, after all the assumption is that *all* users are programmers of some type.
True. Anyway, it'd be good to have both (single and multi-line comment).
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.
This may be fixed by supporting two comment types per filetype, one single-line (or at least nestable) to use with ^E, and one for multi-line comments. Though, it wouldn't probably be enough for Python since you still want to use sharp-comments in e.g. fileheader but triple-quote-strings as comments for doc...
Yes we need a separate template_comment_open and template_comment_close in filetypes.*.
This wouldn't solve the problem since in Python you don't want all template to use """ ... """
After some consideration I think that docstrings are not comments so they should not be inserted by "insert comments".
Maybe. Not sure the distinction is really needed though.
Cheers, Colomban
On 19 March 2011 10:26, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 18/03/2011 23:52, Lex Trotman a écrit :
Hi Colomban,
[..]
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.
I think its ok to strip only one newline, then people who actually do want extra blank lines in their templates can still have them, they just have to remember one gets stripped.
Yep, and the idea of stripping one being that most editors add it implicitly, at least on Unices.
Only comment on the patch is that you have swapped the order of frame_end and template_eol_char at the end of the template. (compare lines 21 and 67/68 of the patch)
It was indented actually (not as swapping though):
- I added a line before the frame_end since the template no longer have
a trailing new line.
Maybe ok, I don't care up to to others to say.
- I removed the newline after because it added implicitly an extra
newline in e.g. template files (main.c, etc.) after the comment, but maybe we better keep it (e.g. inserting a template comment adds a new line); not sure.
Needs the eol after the comment close, otherwise if I insert a function description before a function the prototype ends up on the same line as the comment close, yuk.
[...]
Maybe. Not sure the distinction is really needed though.
Well then we need (at least) a third set of options, better to leave it to the plugin.
Cheers Lex
Cheers, Colomban
Le 19/03/2011 02:32, Lex Trotman a écrit :
On 19 March 2011 10:26, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 18/03/2011 23:52, Lex Trotman a écrit :
Only comment on the patch is that you have swapped the order of frame_end and template_eol_char at the end of the template. (compare lines 21 and 67/68 of the patch)
It was indented actually (not as swapping though):
- I added a line before the frame_end since the template no longer have
a trailing new line.
Maybe ok, I don't care up to to others to say.
If we remove the last EOL of the input template, we need to add one between the template and the frame end, otherwise that frame end will not end up in its own line.
- I removed the newline after because it added implicitly an extra
newline in e.g. template files (main.c, etc.) after the comment, but maybe we better keep it (e.g. inserting a template comment adds a new line); not sure.
Needs the eol after the comment close, otherwise if I insert a function description before a function the prototype ends up on the same line as the comment close, yuk.
Right, my bad. Maybe this would need to do something different depending on whether we're replacing in a template or inserting interactively?
Cheers, Colomban
On 19 March 2011 13:09, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 19/03/2011 02:32, Lex Trotman a écrit :
On 19 March 2011 10:26, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 18/03/2011 23:52, Lex Trotman a écrit :
Only comment on the patch is that you have swapped the order of frame_end and template_eol_char at the end of the template. (compare lines 21 and 67/68 of the patch)
It was indented actually (not as swapping though):
- I added a line before the frame_end since the template no longer have
a trailing new line.
Maybe ok, I don't care up to to others to say.
If we remove the last EOL of the input template, we need to add one between the template and the frame end, otherwise that frame end will not end up in its own line.
Ok.
- I removed the newline after because it added implicitly an extra
newline in e.g. template files (main.c, etc.) after the comment, but maybe we better keep it (e.g. inserting a template comment adds a new line); not sure.
Needs the eol after the comment close, otherwise if I insert a function description before a function the prototype ends up on the same line as the comment close, yuk.
The documentation says that function description is inserted "one line above" the function, ie a blank line between. Geany 0.20 does do this.
Right, my bad. Maybe this would need to do something different depending on whether we're replacing in a template or inserting interactively?
You can only insert a function description interactively so no problem.
AFAICT only BSD GPL and fileheader can be inserted into other templates and also inserted interactively.
Cheers Lex
Cheers, Colomban
On 03/18/11 15:52, Lex Trotman wrote:
I'm not sure we should consider changing a config file too power-user, after all the assumption is that *all* users are programmers of some type.
That's too bad really, because turning off the sidebar, message window and toolbar, the interface is strikingly similar to a basic text editor (with tons of power under the hood..err, bonnet). Geany blows Gedit out of the water in terms of speed and Mousepad in terms of functionality, so I think there is a "market" to use Geany as a general purpose text editor like those.
I'm still curious why XFCE isn't using Geany as the default text editor since it's fast and light like XFCE and quite frankly Mousepad completely sucks.
Cheers, Matthew Brush
On 19 March 2011 11:00, Matthew Brush mbrush@codebrainz.ca wrote:
On 03/18/11 15:52, Lex Trotman wrote:
I'm not sure we should consider changing a config file too power-user, after all the assumption is that *all* users are programmers of some type.
That's too bad really, because turning off the sidebar, message window and toolbar, the interface is strikingly similar to a basic text editor (with tons of power under the hood..err, bonnet). Geany blows Gedit out of the water in terms of speed and Mousepad in terms of functionality, so I think there is a "market" to use Geany as a general purpose text editor like those.
But then they aren't using the filetype features anyway :-)
I'm still curious why XFCE isn't using Geany as the default text editor since it's fast and light like XFCE and quite frankly Mousepad completely sucks.
Funny, I first came across Geany because an XFCE based distro (zen) installed it by default. If a distro wanted to use Geany as its default editor and wanted everything GUI configurable then I'm sure we would happily accept patches they push upstream.
There was some work done on a general config GUI but I'm not sure where it got to, and if it covers filetypes files.
Cheers Lex
Cheers, Matthew Brush _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
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 :)
- 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
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
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.
This is the case for Geany itself (see hacking).
Cheers Lex
Cheers, Colomban _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
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.
Cheers, Colomban
On 21 March 2011 02:19, Colomban Wendling lists.ban@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