[Geany-devel] Changes to templates

[Lex Trotman]

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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>