[Geany-devel] Changes to templates

[Lex Trotman]

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.

>>> 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.

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