Add support for automatic continuation of single-line comments

[danpla]

It would be nice to have automatic continuation of single-line comments, as long as such a comment is not inline (that is, there is no code before the comment).

For example, pressing Return after this comment (C++, | is caret):

// First line|

Will result in:

// First line
// |

One of the reasons why it's useful is writing Doxygen documentation. Along with C-style multiline comments, Doxygen supports C++-style comments in the following two forms:

///
/// Variant 1
///

//!
//! Variant 2
//!

Currently, writing such comments is extremely tedious, not only because you have to type /// or //! every time, but also because the indentation within the comment is lost. Detecting such special cases
(/// and //!) is easy to implement as long as basic form (//) is supported.

[elextr]

This sort of thing is language specific (particularly if you are detecting doc comments in their various forms and doing special things. That sort of thing should be in plugins not in core.

Also how do you stop it repeating the comment on the next line when you press return at the end of the comment block?

[codebrainz]

Given that the current multi-line C comment auto "indentation" (adding a *) is often annoying, this seems like it would be potentially even more annoying given that the normal use case for // is for single-line comments.

I wonder if it'd fit better in a plugin like Addons or GenDoc?

[danpla]

Also how do you stop it repeating the comment on the next line when you press return at the end of the comment block?

Since there is no explicit end of the block (like */ in C comments), you will need to remove the added // manually to stop repeating.

[danpla]

the normal use case for // is for single-line comments

That's true, but in come C++ projects (LLVM, for example) people prefer C++ comments even for comment blocks and Doxygen.

[elextr]

Yes, multiline // comments are common in C++, and as @codebrainz noted above the current Geany multiline comment behaviour is very "GNU C idiom we will force on everybody".

So similar to my comment on #2082, this is language specific and either:

1. should be in a plugin, or

2. it should be language agnostic and driven by settings in the filetype file. But given the number of doxygen permutations that may be difficult. For example Python uses """ strings in strategic places as doxycomments.

So I suggest this is more likely a plugin thing. Plugins should not be thought of as some sort of second class feature, and they have many advantages for developing new features like this, being outside core and because they can be disabled by users if they cause problems, they are not so heavily reviewed, so plugins and changes to them are usually accepted much faster. They can be added to the Geany-Plugins collection and get packaged by distros, and if they become very popular they can become "core plugins" so they are automatically distributed with Geany itself. And all still not in core.

Anyway, back to the actual functionality 😁 @danpla your suggestion of having to delete comments to end the block doesn't sound very satisfying, it just swaps having to type the comments with having to delete them. The plugin could have an unbound keybinding that the user could bind, eg to Windows-return.

[danpla]

@elextr Yes, a key binding may be an option. But I think manual removing is somewhat consistent with the current termination of a block comment, and, in fact, it needs the same number of keystrokes (or even one less if smart Home key is enabled):

• To terminate a block comment, you need 3 keystrokes:

  1. Backpace to remove the space after *
  2. / for terminator
  3. Enter to go to the next line

• To terminate a single-line comment (including Doxygen cases), you just need to select the added continuation, and then anything you type will replace it. Selection only takes 2 keystrokes if smart Home is active (Shift + Home) or 3 if not (Ctrl + Shift + Left).

Anyway, I understand that such things should be in a plugin, so I close the issue.