[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More on format=flowed
From: |
Yuri D'Elia |
Subject: |
Re: More on format=flowed |
Date: |
Mon, 03 Jan 2011 01:55:56 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) |
On Sun, 02 Jan 2011 20:32:31 +0100, Lars Magne Ingebrigtsen wrote:
>> (defun harden-newlines ()
>> (save-excursion
>> (goto-char (point-min))
>> (while (search-forward "\n" nil t)
>> (put-text-property (1- (point)) (point) 'hard t))))
>
> So, basically, you make all the newlines hard. Isn't the point of
> `use-hard-newlines' that you can mix and match hard and soft newlines?
I guess the point of `use-hard-newlines' is to preserve the concept of
soft and hard newlines when the text is being automatically manipulated
by auto-fill.
Just as a note, `longlines-mode' is a twist on the concept that performs
word wrapping with soft newlines, but stores hard newlines only
(simulating the effect of word-wrap). Is this mode still needed at all?
The point of format=flowed is to have flowed text however, when reading
*and* writing if the user so desires.
For instance, when a flowed message is decoded in flow-fill.el, hard
newlines aren't restored. This means that you can't actually make *use*
of the distinction (a cheap hack would have been turning on
`longlines-mode' in the article buffer with mixed hard/soft newlines).
At least with `fill-flowed-display-column' I can force the unquoting so
that I can still use word-wrap, but that's sub-optimal. Either fully
support soft newlines, or use word-wrap and be done.
>> word-wrap t
>> use-hard-newlines t))))
>
> You're mixing `use-hard-newlines' with `word-wrap', and the two don't
> really mix that well. I think.
Turning `use-hard-newlines' on is just a hack to force Gnus into
generating a flowed message.
Internally `fill-flowed-encode' unwraps all soft newlines and then
rewraps then using `fill-region'. That's completely unnecessary with
word-wrap (there are no more soft newlines). I simply skip the first
step by marking all lines as hard.
When lines longer than `message-fill-column' are seen, the body should be
encoded automatically with format=flowed, or quoted-printable. But I
can't see any variable that can regulate the final message encoding.