Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: Yuri D'Elia <wavexx@users.sf.net>
To: info-gnus-english@gnu.org
Subject: Re: More on format=flowed
Date: Mon, 03 Jan 2011 01:55:56 +0100	[thread overview]
Message-ID: <87k4imyfdv.fsf@savara.sat.thregr.org> (raw)
In-Reply-To: <m3y673qey8.fsf@quimbies.gnus.org>

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.

  reply	other threads:[~2011-01-03  0:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.0.1293983977.14417.info-gnus-english@gnu.org>
2011-01-02 19:32 ` Lars Magne Ingebrigtsen
2011-01-03  0:55   ` Yuri D'Elia [this message]
2011-01-02 15:59 Yuri D'Elia

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k4imyfdv.fsf@savara.sat.thregr.org \
    --to=wavexx@users.sf.net \
    --cc=info-gnus-english@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).