[Users] more line wrapping

[Neels Hofmeyr]

"H.Merijn Brand" <h.m.brand at xs4all.nl>:
> On Wed, 3 Apr 2013 10:38:30 -0400, Steve Litt
> <slitt at troubleshooters.com> wrote:
> > Thank you very much for volunteering to code, debug, and test this
> > enhancement.  When you code it, please make a configuration option
> > to keep it like it is now, because I like it just the way it is,
> > and I have a feeling I'm not alone.
> 
> I like it the way it is, but having the *extra* possibility to
> wrap/format selected code would be very welcome. And with that,
> I see no need for an option,  as it currently does nothing and
> re-flow selected text on Control-L seem very DWIM to me.

Thanks for your support. In the meantime I have found occasional other
weird issues with line wrapping. I don't understand why you guys like
it the way it is :)


Reproduce:

1) Have line wrapping configured at line width = 72, and a paragraph
like this:

One two three four five six seven eight nine ten eleven twelve and
thirteen fourteen fifteen sixteen..... One two three four five six seven
eight nine ten.

2) Place cursor near the end of the second line, just after the word
'six':

[...]..... One two three four five six| seven

3) Add a space -- the situation must be such that adding the space
triggers wrap.


My result *sometimes* looks like so (cursor pos indicated by |):

One two three four five six seven eight nine ten eleven twelve and
thirteen fourteen fifteen sixteen..... One two three four five six|
seven
eight nine ten.

Two issues:
1) The cursor is still directly after 'six', and no space was added.
2) 'seven' is on its own line.

However, other times the second issue doesn't happen. When I add the
space in the first, freshly typed reproduction paragraph above, both
problems happen. When I copy-paste the paragraph and try in the pasted
copy, only the first problem appears (being that the cursor is still
just after 'six' and the space is swallowed), while 'seven' is wrapped
correctly. Saving as draft and reopening has the same effect: only
problem 1) remains. How can these cases be different!?!?

In this and other ways I find that line wrapping is non-deterministic:
in some cases a word stays above, in others it is wrapped down,
depending on where in the line I do the remove+readd space dance.

Doing Ctrl-Z after a line wrap can also be quite entertaining. It
unravels all the single steps of spaces removed and added during the
wrapping process, instead of just undoing the last keystroke & wrap.

(BTW, I just git-cloned and built claws afresh before testing.)

My intuitive hacker's feeling about claws' line wrapping is that it must
be riddled with special cases and unplugged holes -- without having
looked at the code though :P

I hope I can find some time to look into it; in the meantime, would
someone be so kind and provide code pointers to the places that do line
wrapping? That would be very helpful.

Thanks!
~Neels
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20130417/2bc7e99f/attachment.sig>