Re: Balsa can't download a mail with a long line, gets stuck in endless dup-creating loop.

Am 27.10.12 19:21 schrieb(en) Rob Landley:
Apparently Format=Flowed is checked by default. I had word wrap checked because the incoming message crash means that if I don't, there's the possibility balsa couldn't download messages I sent to myself. (That was my understanding, anyway. I didn't want to risk hitting any more line length limitations in the send/receive logic.)

I guess you have to distinguish two different line lengths here:

- the /displayed/ line length, which may be unlimited and
- the /transmitted/ line length for which according to RFC 2822, sect. 2.1.1 the following applies:

   There are two limits that this standard places on the number of
   characters in a line. Each line of characters MUST be no more than
   998 characters, and SHOULD be no more than 78 characters, excluding
   the CRLF.

If a broken MUA violates the latter restriction, this might cause trouble.  Of course, Balsa (read: the underlying gmime lib) strictly follows the 78 char rule.

If you look at the message source (Ctrl-U), e.g. of this message, you see the "folding white space" (in qp encoding a "=20<CR><LF>" at the end of each line) as to fulfil the '2822 requirements within long lines.  The quoted part contains the quote mark at the beginning of each folded line so stupid MUA's display it properly.  Balsa (and others, like kmail) glue them together as defined in RFC 3676.

As a test, I'm typing a paragraph I'll go back and insert words (such as these) into the middle of, to see if it can sanely wordwrap them. Hey, it looks like it's now handling it reasonably. (I would have thought that the wordwrap at X characters thing would have been applied to mail _after_ composer was done with it. Live and learn.)

Well, I must admit that the naming of these options is really confusing... :-/

I selected the above two lines and hit ctrl-R and it added a blank line after them but otherwise left things unchanged. In my current view, there are only two > characters and the only clue it's reply text is the color coding. But I guess that's an aesthetic choice. (I'm used to reply text being displayed with > at the start of the line even if the composer is logically treating it as one big paragraph.)

One thing kmail (I have to use it at work as to have access to the Groupware calendars) does better here is that if you insert a new line into a quoted paragraph, *both* split parts have the same quoting depth.  In Balsa, the second parts is unquoted.

Regarding the display, it would be better to have the vertical bar as in the text display.  I implemented the latter ages ago, and I don't recall how difficult it would be in the composer (i.e. why I didn't add it there).

If I find some time, I'll look into both issues!


Attachment: pgpP885m9yog4.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]