"Comment tool" does not work properly if static word wrap is on

[Katsudon]

Ubuntu 8.04, kile 2.0.0, package 1:2.0-1

If static word wrap is enabled (Settings->Configure Kile->Editor->Editing->Enable static word wrap) and a longer paragraph is selected (several lines, each line close in length to the maximal length as defined by the static word wrap) then Ctrl-D ("Comment") tool does not really comment the paragraph in the right way.

Example: set "wrap words at: 80", then attempt to comment the paragraph:

a a a aaaa aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa
a a a aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa aaaa
aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa

results with:

% a a a aaaa aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa
aaaa
% a a a aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa aaaa
aaaa
% aaaaaaa aaaa aaaa aaaa aaaaaaa aaaa

in other words, there are two lines which consist of "aaaa" and are not commented.

[1uf1w-alexander-sd4cm (1uf1w-alexander-sd4cm)]

Version: 2.4 (using KDE KDE 3.4.0)
Installed from: Gentoo Packages
Compiler: gcc 3.4.3
OS: Linux

I use CTRL-D a lot to comment blocks of Perl code. It simply places "# " (a pound sign and a space) at the head of each highlighted line.

When I have static word wrap turned on, any lines that are within two characters of hitting the wrap limit have their last word moved to a new line (they're pushed by the two new characters). That's all fine and dandy, but the problem is that the new line _is not commented_. Which means the code doesn't compile and I have to go searching for the problem.

[Anders Lund (anders-alweb)]

Monday 09 May 2005 21:26 skrev Xan Charbonnet:
> I use CTRL-D a lot to comment blocks of Perl code.  It simply places "# "
> (a pound sign and a space) at the head of each highlighted line.

Yes, as perl does not have multiline comment markers (don't suggest 'podding
it out', it's something different ;) )

> When I have static word wrap turned on, any lines that are within two
> characters of hitting the wrap limit have their last word moved to a new
> line (they're pushed by the two new characters).  That's all fine and
> dandy, but the problem is that the new line _is not commented_.  Which
> means the code doesn't compile and I have to go searching for the problem.

Right, that is a problem.

[1uf1w-alexander-sd4cm (1uf1w-alexander-sd4cm)]

It would also be nice if, upon uncommenting with CTRL-SHIFT-D, the new line's contents went back to the end of the old line. That's probably more of a wishlist thing though.

[Anders Lund (anders-alweb)]

Tuesday 10 May 2005 19:01 skrev Xan Charbonnet:
> It would also be nice if, upon uncommenting with CTRL-SHIFT-D, the new
> line's contents went back to the end of the old line.  That's probably more
> of a wishlist thing though.

Yes :-)

[Thomas Friedrichsmeier (tfry)]

*** Bug 125123 has been marked as a duplicate of this bug. ***

[Thomas Friedrichsmeier (tfry)]

This does not only apply to perl. It's a general problem (at least for languages without multiline comments). Hence retitling.

Also confirming this for both KDE 3.5.8 and KDE 4.

[Thomas Friedrichsmeier (tfry)]

*** Bug 139892 has been marked as a duplicate of this bug. ***

[Holger Krause (holger-krause)]

I guess the same happens, when using the include graphics function from the LaTeX menu. If the file to be inserted has a long filename, the automatically inserted comment line will be wrapped in this way:

  \includegraphics{directory/quite_long_filename_quite_long_filename.pdf}
  % quite_long_filename_quite_long_filename.pdf: 595x842 pixel, 72dpi, 20.99x29.70 cm,
bb=0 0 595 842

[Stefan Kottwitz (stefan.k)]

I can confirm it using Kile 2.0.0 on Ubuntu 8.04 amd64. It can be reproduced for a single line too, also without Ctrl-D if just % is inserted at the beginning of such a long line.

[Alessandro Rossini (alessandro.rossini)]

I can confirm the bug for:
Version: 3.2.1 (using KDE 4.2.1)
Installed from: Kubuntu Intrepid 8.10

This bug is four years old now, and it is quite annoying since it regards many languages.
Any chance to see it fixed?

Best regards.

[Dhaumann (dhaumann)]

*** Bug 185110 has been marked as a duplicate of this bug. ***

[Thomas Braun (tbraun1234)]

*** Bug 201322 has been marked as a duplicate of this bug. ***

[Andreas Wenning (andreas-wenning)]

Also affects kile 2.1~beta2 in karmic.

[mokabar (tim-klingt)]

i hope, it won't take another 5 years to fix this.

[Michel Ludwig (michel-ludwig)]

*** Bug 240610 has been marked as a duplicate of this bug. ***

[Michel Ludwig (michel-ludwig)]

*** Bug 240790 has been marked as a duplicate of this bug. ***

[Michel Ludwig (michel-ludwig)]

*** Bug 243345 has been marked as a duplicate of this bug. ***

[Dhaumann (dhaumann)]

*** Bug 170881 has been marked as a duplicate of this bug. ***

[Dhaumann (dhaumann)]

*** Bug 243443 has been marked as a duplicate of this bug. ***

[Michel Ludwig (michel-ludwig)]

*** Bug 248766 has been marked as a duplicate of this bug. ***

[Marco Lackovic (marco-lackovic)]

Also affects Kile 2.0.85 in Ubuntu 10.10-64.

[Yngve-levinsen (yngve-levinsen)]

So this bug is now 6 years old and no one is picking it up? :(
It is annoying for me when I use Kile and static word wrap, which is my preferred setup.
If I use dynamic word wrap then it makes a problem for svn/git and friends because you have so few lines so the chance that several authors edited the same line is high. Would really appreciate this being improved!

[Yngve-levinsen (yngve-levinsen)]

Created attachment 60859
patch that I believe fixes this bug?

I managed to get annoyed enough that I had a look at the source code. Static word wrap is very practical when you keep your code in a revision control system to reduce merge conflicts, but this bug made it very unpractical for at least latex editing (using Kile).
 I wrote a small patch which at least when I tested it seemed to work. Then again, I realize that the code has dependencies right and left being a tool for so many other programs, so perhaps I with this patch break something else. Please review.

[Dhaumann (dhaumann)]

As a workaround this works.

However, if you edit the comment then at some places it will immediately break, and you still run into the problem. But still, this is better than nothing imo.

[Yngve-levinsen (yngve-levinsen)]

That is true. My current gripe is when I want to comment out a paragraph (or several), and use ctrl+d on a marked set of text. It is not always that I note immediately that one or several lines went "overboard". If I am editing a comment and it does a linebreak I will notice at least (or so I believe). I believe this workaround solves the first situation.

I know it is not a perfect patch, and you as experienced developers might have a better idea. This is in fact my first patch to KDE :)

[Dhaumann (dhaumann)]

What we could do is: never wrap single line comments. This however is currently not possible, as we don't have a flag in the highlighting system that tells us whether it's a single or multiline comment.

[Thomasdn (thomasdn)]

2011/6/10 Dominik Haumann <email address hidden>:
> What we could do is: never wrap single line comments.

Or just break it, but add another % in the front of the next line.
Isn't this what most other editors/IDEs do? Like, say, Eclipse.

Med venlig hilsen/Kind regards
Thomas Damgaard Nielsen
http://thomasdamgaard.dk

[Yngve-levinsen (yngve-levinsen)]

@Thomas I think that is a better solution, absolutely. I just didn't know how to do that since I am not yet very familiar with the source...

[Michel Ludwig (michel-ludwig)]

*** Bug 274545 has been marked as a duplicate of this bug. ***

[Dhaumann (dhaumann)]

Unfortunately it's more complex. Simply inserting e.g. a '%' for wrapped lines does not work if you edit a line as follows:

% text text text text text text text text text text text

Assume, we wrap in the next column. Insert a word as follows:

% word text text text text text text text text text text
text

Insert another words:

% word word text text text text text text text text text
text text

And so on:

% word word word word word word text text text text text
text text text text text text

In other words: Kate adds the text to be wrapped to the already wrapped text.

Now apply your solution, you'd get:

% word text text text text text text text text text text
% text

Another word:
% word word text text text text text text text text text
% text % text

And so on:
% word word word word word word text text text text text
% text % text % text % text % text % text

This is not what you want. Without the smart concatenation, you'd get:
% word word word word word word text text text text text
% text
% text
% text
% text
% text
% text

Also not what you want. This is btw the reason why it's not fixed. Because it's not that simple. Or maybe a good solution for all cases does not even exist.

[Yngve-levinsen (yngve-levinsen)]

@Dominik good point, which I did not think about. I guess you'd somehow need to treat the comment character (+ whitespaces) as a separate column entity and then the wrapped text would need to start after the comment character.

I also realized another difference between my proposed patch and what Thomas suggested. If you comment out a paragraph and then uncomment it again, you are back at the same line count if you do what I propose, since you just halt the word wrap when commenting. If you break the lines when commenting you get some lines with one word.

[Dhaumann (dhaumann)]

Yes, that's why I think the patch you propose in comment #18 is a very good one as workaround.

@ comment #27 part b) Yes, another reason for just applying this patch.

We (some Kate developers) once had a discussion about static word wrap. And essentially it's probably impossible to always get it right for the user (keep the smart wrapping in mind explained in comment #26). That's the reason why it right now simply wraps, and that's it.

Christoph, ok to commit the patch?

[Thomasdn (thomasdn)]

2011/6/11 Dominik Haumann <email address hidden>:
> We (some Kate developers) once had a discussion about static word wrap. And
> essentially it's probably impossible to always get it right for the user (keep
> the smart wrapping in mind explained in comment #26). That's the reason why it
> right now simply wraps, and that's it.

Impossible? Really? Then, how come other editors can get this right?
Eclipse and Vim comes to mind. I am almost sure that I remember seing
Emacs doing this right also.

Med venlig hilsen/Kind regards
Thomas Damgaard Nielsen
http://thomasdamgaard.dk

[Alvaro-aguilera (alvaro-aguilera)]

>This is not what you want. Without the smart concatenation, you'd get:
>% word word word word word word text text text text text
>% text
>% text
>% text
>% text
>% text
>% text

that would be an acceptable solution for me. it's not perfect, but _way_ better than it currently is.

[Yngve-levinsen (yngve-levinsen)]

Just to add, this is how I believe the logic of the static word wrap for a complete solution should be:
- when commenting/uncommenting lines, suspend static word wrap.
- when word wrap:
   - if current line is a comment line:
     - if next line has comment character at same indentation, push last
       word from current line to after the comment character (+ whitespace)
       of next line.
     - else, push last word from current line to next line, keep indendation,
       add comment character (+ whitespace) at the beginning of that line.

Such logic would be how I'd expect it to work at least (and I realize that others might be of a different opinion). I think it is perfectly possible to implement, and should not have any of the problems mentioned in comment #26.

[Jonas (jonas743)]

Hi, can we expect this in the next version?

I just want to add that for me as a kile-user, it doesn't matter so much if it is the basic variant of the patch, or the more sophisticated one described in #31. It is just that I sometimes want to comment large parts of a document (like several chapters), and with the current implementation that means that I have to scroll through to check for wrapped lines each time.

The problem of editing comments is really a comparatively minor one, so the behaviour in this case doesn't matter so much. Thus, instead of searching for a perfect solution, I suggest just including the simple one.

[Dhaumann (dhaumann)]

Git commit 30c06cf383d0fbc8ebdc125fc180dc90b4af7738 by Dominik Haumann.
Committed on 17/07/2011 at 21:32.
Pushed by dhaumann into branch 'master'.

prevent word wrap from breaking comments

CCBUG: 105373

M +6 -0 part/document/katedocument.cpp

http://commits.kde.org/kate/30c06cf383d0fbc8ebdc125fc180dc90b4af7738

[Dhaumann (dhaumann)]

Git commit 682fa5ac9376bf5cd6e556259d531c895a31172c by Dominik Haumann.
Committed on 17/07/2011 at 21:32.
Pushed by dhaumann into branch 'KDE/4.7'.

prevent word wrap from breaking comments

CCBUG: 105373

M +6 -0 part/document/katedocument.cpp

http://commits.kde.org/kate/682fa5ac9376bf5cd6e556259d531c895a31172c

[Dhaumann (dhaumann)]

Workaround from commment #18 committed for KDE 4.7. This works quite well. The basic problem when manually editing this comment still exists so far.

Comment #31 suggests further solution, but this also not always works. Example:
/// doxygen comment
/// some text ... doxygen list:
/// - bla bla bla bla bla bla bla
/// - foo foo foo

Wrapping bla would lead to
/// doxygen comment
/// some text ... doxygen list:
/// - bla bla bla bla bla bla bla
/// bla - foo foo foo

Hence, the list would be wrongly interpreted. In other words, since this also does not solve the issue to 100%, I'm against implementing this.

[Yngve-levinsen (yngve-levinsen)]

@Dominik Ah, that one I had not thought of! I checked how static word wrap is done without comments, and then it seems to solve the issue you mention. I guess by reusing the "normal" static word wrap logic, with some added logic to treat the comments as a separate entity would work at least as well as static word wrap without comments.. Or?

Then again I don't know enough about Kate (or programming in general) to know how difficult it would be to implement. This bug being open for now 6 years tells me it is probably not an easy matter.. :)

Happy to hear my patch made it into KDE, a small feat for me to have my first patch accepted! :)

[Jay (jdeyoun1)]

Also impacts me. I'd also like to comment that word-wrap doesn't work very well. Kile basically doesn't auto-wrap documents I open. It also doesn't adjust well to changing its size. It seems the way word-wrap is implemented is via inserting newlines into the document, which is not the purpose of word-wrap.

Curious - if I started using vi mode, would that cure this issue (assuming my vimrc is correct)?

[Cullmann-t (cullmann-t)]

The workaround is ok, more logic will not went into this. Kate doesn't fully understand the text you have, therefore all other "magic" on static word wrap will just make it worse.

[Michel Ludwig (michel-ludwig)]

*** Bug 255300 has been marked as a duplicate of this bug. ***

[Dhaumann (dhaumann)]

For the record, a similar issue again appeared when removing trailing spaces on save, see bug #328900. Fixed in the same way.