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