When editing a multi-line comment, it would be
convenient if the editor's behavior changed: when a
preset width is reached, the editor inserts a newline
before the last word break and moves the next word and
cursor to the next comment line. When deleting the
beginning or end of a line, the comment is
automatically re-wrapped.
For example ("|" indicates cursor):
/*
* This is my comment that has a rather long line t|
*/
When typing continues, this is the result:
/*
* This is my comment that has a rather long line
* that just keeps going ...|
*/
If the user removes the word "long", this is the result:
/*
* This is my comment that has a rather |line that
* just keeps going ...
*/
If the user then moves the cursor to the end of the
word "that" and presses delete, here is the result:
/*
* This is my comment that has a rather line
* that|just keeps going ...
*/
Of course, since newlines would apparently be
hard-coded into the source file, there is an ambuguity:
what if the user introduces his own newline:
/*
* This is the first line.|
* This is the second line.
*/
When the user keeps typing, does he get this:
/*
* This is the first line. I've decided to add
* a bit more text.| This is the second line.
*/
Or this:
/*
* This is the first line. I've decided to add
* a bit more text.|
* This is the second line.
*/
Resolving that ambiguity is a key task necessary to
make this work. In either case, though, it wouldn't be
that hard for the user to to add a desired newline or
remove an unwanted one.
Logged In: YES
user_id=697810
I don't generally like automatic adding of hard line breaks
in files. I'd recommend behavior similar to that of pico,
where you push a command sequence to format the current
block of text. In this case, the breaks aren't reformatted
at every keystroke. In any case, I think automatically
adding the breaks in the first place should be optional.
Still a very nice idea.