Support for encoding format=flowed (RFC 2646)

Support for encoding format=flowed (RFC 2646)

[Simon Josefsson]

I have checked in preliminary format=flowed support.  The missing
functionality right now is doing the right thing when following up on
an article.

How to use: Enable `use-hard-newlines' (see emacs manual) in the
message buffer, and the code should fill and format=flow encode your
article according to the soft/hard newlines in the buffer.  Hint: I
find `use-hard-newlines' useless without something similar to M-x
longlines-show-hard-newlines RET from longlines.el.

(I also changed the format=flowed decoding code to flow the message to
the width of the window.)

As you can see, the above
paragraphs are filled nicely
while this one sentences isn't.
This is because I hit RET after
each of these lines, without
using M-q on the paragraph.

Re: Support for encoding format=flowed (RFC 2646)

[Simon Josefsson]

Simon Josefsson <jas@extundo.com> writes:

> I have checked in preliminary format=flowed support.  The 
> missing functionality right now is doing the right thing when 
> following up on an article.
>
> How to use: Enable `use-hard-newlines' (see emacs manual) in the 
> message buffer, and the code should fill and format=flow encode 
> your article according to the soft/hard newlines in the buffer. 
> Hint: I find `use-hard-newlines' useless without something 
> similar to M-x longlines-show-hard-newlines RET from 
> longlines.el.

Oops, it only worked when previewing the message, not when 
sending.  Now it should work.  I'm including all of the old 
message for testing purposes..

>
> (I also changed the format=flowed decoding code to flow the 
> message to the width of the window.)
>
> As you can see, the above
> paragraphs are filled nicely
> while this one sentences isn't.
> This is because I hit RET after
> each of these lines, without
> using M-q on the paragraph.

Re: Support for encoding format=flowed (RFC 2646)

[Kai Großjohann]

Simon Josefsson <jas@extundo.com> writes:

> (I also changed the format=flowed decoding code to flow the message to
> the width of the window.)

I think I want to use a different width than the window width.  Can
you make a user option?  (It's okay to use the window width by
default, as long as I can change it.)

Thanks,
kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Support for encoding format=flowed (RFC 2646)

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> (I also changed the format=flowed decoding code to flow the message to
>> the width of the window.)
>
> I think I want to use a different width than the window width.  Can
> you make a user option?  (It's okay to use the window width by
> default, as long as I can change it.)

I added `fill-flowed-display-column' and
`fill-flowed-encode-column'. I also changed back the default for
*-display-* to `fill-column', it was difficult to read long lines.
Maybe the default should be (min fill-column (- (window-width) 5)) or
something?

Another hint, I'm using:

 '(gnus-message-setup-hook (quote ((lambda nil (use-hard-newlines 1 (quote always))) longlines-show-hard-newlines)))

which enables hard newlines and displays them using longlines when I
compose a message, it seems to work.

Re: Support for encoding format=flowed (RFC 2646)

[Simon Josefsson]

I added some documentation as well.  The Emacs MIME manual says it 
is not directed at users, but some things seems to only be 
documented there.  Should things be duplicated elsewhere as well? 
Where?

Flowed text
===========

   The Emacs MIME library will respect the `use-hard-newlines' 
variable (*note Hard and Soft Newlines: (emacs)Hard and Soft 
Newlines.) when encoding a message, and the "format=flowed" 
Content-Type parameter when decoding a message.

   On encoding text, lines terminated by soft newline characters 
are filled together and wrapped after the column decided by 
`fill-flowed-encode-column'.  This variable controls how the text 
will look in a client that does not support flowed text, the 
default is to wrap after 66 characters.  If hard newline 
characters are not present in the buffer, no flow encoding occurs.

   On decoding flowed text, lines with soft newline characters are 
filled together and wrapped after the column decided by 
`fill-flowed-display-column'.  The default is to wrap after 
`fill-column'.

Re: Support for encoding format=flowed (RFC 2646)

[Matt Armstrong]

Simon Josefsson <jas@extundo.com> writes:

> I have checked in preliminary format=flowed support.  The 
> missing

> functionality right now is doing the right thing when following 
> up > 
> > on

> an article.

> > How to use: Enable `use-hard-newlines' (see emacs manual) in 
> > the

> message buffer, and the code should fill and format=flow encode 
> your

> article according to the soft/hard newlines in the buffer. 
> Hint: I

> find `use-hard-newlines' useless without something similar to 
> M-x

> longlines-show-hard-newlines RET from longlines.el.

> > (I also changed the format=flowed decoding code to flow the > 
> > > message > to

> the width of the window.)

> > As you can see, the above

> paragraphs are filled nicely

> while this one sentences isn't.

> This is because I hit RET after

> each of these lines, without

> using M-q on the paragraph.

> > > --

matt

Seems to work, with some problems that probably aren't all Gnus 
related.  I have this in my .gnus:

    (defun my-message-setup-hook ()

      (use-hard-newlines 1 'always)

      (require 'longlines)

      (set (make-local-variable 'longlines-show-hard-newlines) t))

    (add-hook 'gnus-message-setup-hook 'my-message-setup-hook)

First, when I turn on longlines minor mode, my signature gets 
glommed onto the text I am replying to (see above).  This is 
probably a longlines thing.  Hmm...

Second, when Gnus inserts my .signature, they get inserted with 
hard newlines.  So others see a blank line after my '--' signature 
line.

Third, maybe this is a longlines thing, but I can't bear to edit a 
message without a blank line between each paragraph.  Is there a 
way to get longlines to do that for me?

Fourth, is inserting two blank lines for every hard newline the 
right thing to do?  I bet my elisp above is going to look funny.

Re: Support for encoding format=flowed (RFC 2646)

[Matt Armstrong]

Matt Armstrong <matt+dated+200201181334.2d810e@lickey.com> writes:


> Fourth, is inserting two blank lines for every hard newline the 
> right thing to do?  I bet my elisp above is going to look funny.


As is any quoted text.  Hmm...


--

matt

Re: Support for encoding format=flowed (RFC 2646)

[Matt Armstrong]

Matt Armstrong <matt+dated+200201181309.f839e7@lickey.com> writes:

> Matt Armstrong <matt+dated+200201181334.2d810e@lickey.com> writes:
>
>
>> Fourth, is inserting two blank lines for every hard newline the
>> right thing to do?  I bet my elisp above is going to look funny.
>
>
> As is any quoted text.  Hmm...

Another buglet I noticed -- the ContentType: header doesn't contain
any charset information for my posts (perhaps because I post with
us-ascii, and that is a default?)

-- 
matt

Re: Support for encoding format=flowed (RFC 2646)

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> I added some documentation as well.  The Emacs MIME manual says it is
> not directed at users, but some things seems to only be documented
> there.  Should things be duplicated elsewhere as well? Where?

Perhaps the Emacs MIME manual should be split into two parts -- one
for users and one for programmers.  Or just move the non-user bits
into an appendix.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Support for encoding format=flowed (RFC 2646)

[Kai Großjohann]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Perhaps the Emacs MIME manual should be split into two parts -- one
> for users and one for programmers.  Or just move the non-user bits
> into an appendix.

Please don't split manuals.  People are complaining about not being
able to find information, already!  (They don't know to sometimes
look at the Message manual rather than the Gnus manual.)

kai
-- 
Simplification good!  Oversimplification bad!  (Larry Wall)

Re: Support for encoding format=flowed (RFC 2646)

[Simon Josefsson]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>
>> Perhaps the Emacs MIME manual should be split into two parts -- 
>> one for users and one for programmers.  Or just move the 
>> non-user bits into an appendix.
>
> Please don't split manuals.  People are complaining about not 
> being able to find information, already!  (They don't know to 
> sometimes look at the Message manual rather than the Gnus 
> manual.)

Maybe the user side of MIME should go into the Message manual?

Re: Support for encoding format=flowed (RFC 2646)

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@extundo.com> writes:

> Maybe the user side of MIME should go into the Message manual?

Well, if other packages are supposed to use the MIME library, then
that probably won't be the right place to put the information.

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Support for encoding format=flowed (RFC 2646)

[Malcolm Purvis]

>>>>> "Lars" == Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

Lars> Simon Josefsson <jas@extundo.com> writes:
>> Maybe the user side of MIME should go into the Message manual?

Lars> Well, if other packages are supposed to use the MIME library, then that
Lars> probably won't be the right place to put the information.

[De-lurk]

Speaking as a long-time Gnus user, but only a recent Gnus MIME user, I'd
strongly suggest the Message manual.  User's shouldn't have to care that MIME
is handled by a separate library because as far as they're concerned they're
adding an attachment in Gnus.  So why should they want to look in a different
manual for part of the message sending process?

Besides, any manual that starts with "This is not a manual meant for
users..." is a little bit off-putting.

On the topic of MIME, is there a way of editing the parameters of a part that
has error checking and completion (similar to when a part is created)?  Due to
their complexity, a bit of hand holding here would be very useful (for
instance, having completion list for valid values for 'disposition'.  Finding
out what they are is not straightforward).


Malcolm

Re: Support for encoding format=flowed (RFC 2646)

[Niklas Morberg]

Matt Armstrong <matt+dated+200201181309.f839e7@lickey.com> writes:


> Matt Armstrong <matt+dated+200201181334.2d810e@lickey.com> 
> writes:

>

>

>> Fourth, is inserting two blank lines for every hard newline the 
>> right thing to do? I bet my elisp above is going to look funny.

>

>

> As is any quoted text. Hmm...


Matt,

did you find a solution to this? I would like to use hard newlines 
when composing messages, but the extra blank lines inserted is a 
real nuisance...


Niklas

Re: Support for encoding format=flowed (RFC 2646)

[Matt Armstrong]

Niklas Morberg <niklas.morberg@axis.com> writes:

> Matt Armstrong <matt+dated+200201181309.f839e7@lickey.com> writes:
>
>
>> Matt Armstrong <matt+dated+200201181334.2d810e@lickey.com> writes:
>
>>
>
>>
>
>>> Fourth, is inserting two blank lines for every hard newline the
>>> right thing to do? I bet my elisp above is going to look funny.
>
>>
>
>>
>
>> As is any quoted text. Hmm...
>
> Matt,
>
> Did you find a solution to this? I would like to use hard newlines
> when composing messages, but the extra blank lines inserted is a
> real nuisance...

No, I haven't -- it still exists as what Simon originally implemented.
I was playing with it mainly as a toy and not for serious work
(though, if it worked well I might turn it on by default).

-- 
matt

Re: Support for encoding format=flowed (RFC 2646)

[Simon Josefsson]

Matt Armstrong <matt@lickey.com> writes:

>>>> Fourth, is inserting two blank lines for every hard newline 
>>>> the right thing to do? I bet my elisp above is going to look 
>>>> funny.
>>
>>> As is any quoted text. Hmm...
>>
>> Matt,
>>
>> Did you find a solution to this? I would like to use hard 
>> newlines when composing messages, but the extra blank lines 
>> inserted is a real nuisance...
>
> No, I haven't -- it still exists as what Simon originally 
> implemented.  I was playing with it mainly as a toy and not for 
> serious work (though, if it worked well I might turn it on by 
> default).

Do you get two blank hard newlines between each line?  Weird.  Do 
you have some kind of fill related customizations?  The flow-fill 
code uses `fill-region', so if there is some customization that 
affect that function, it will affect format=flowed encoding as 
well.  Ideally, flow-fill.el should inhibit such customizations.

Re: Support for encoding format=flowed (RFC 2646)

[Matt Armstrong]

Simon Josefsson <jas@extundo.com> writes:

> Matt Armstrong <matt@lickey.com> writes:
>
>>>>> Fourth, is inserting two blank lines for every hard newline the
>>>>> right thing to do? I bet my elisp above is going to look funny.
>>>
>>>> As is any quoted text. Hmm...
>>>
>>> Matt,
>>>
>>> Did you find a solution to this? I would like to use hard newlines
>>> when composing messages, but the extra blank lines inserted is a
>>> real nuisance...
>>
>> No, I haven't -- it still exists as what Simon originally
>> implemented.  I was playing with it mainly as a toy and not for
>> serious work (though, if it worked well I might turn it on by
>> default).
>
> Do you get two blank hard newlines between each line?  Weird.  Do you
> have some kind of fill related customizations?  The flow-fill code
> uses `fill-region', so if there is some customization that affect that
> function, it will affect format=flowed encoding as well.  Ideally,
> flow-fill.el should inhibit such customizations.

I do use filladapt.

What I was seeing was that stuff like the quoted text above or the
automatically inserted ~/.signature would have a hard newline at the
end of each line (longlines.el showed them to me).  Then each hard
newline in the message buffer ended up as two newlines in the sent
message.

-- 
matt

Re: Support for encoding format=flowed (RFC 2646)

[Niklas Morberg]

Matt Armstrong <matt@lickey.com> writes:

> I do use filladapt.

Me too. [Turning filladapt off and use-hard-newlines on.
Testing...]. Turning off filladapt (`M-x filladapt-mode')
did not seem to help, though. I still see the same problem.

> What I was seeing was that stuff like the quoted text
> above or the automatically inserted ~/.signature would
> have a hard newline at the end of each line (longlines.el
> showed them to me). Then each hard newline in the message
> buffer ended up as two newlines in the sent message.

Exact same behaviour here (except possibly for the .sig
stuff which I haven't tested). Also, long text strings (such
as URLs) break with a `=' character at the end. The message
contains this information after being received:

 Content-Type: text/plain; charset=iso-8859-1; format=flowed
 Content-Transfer-Encoding: quoted-printable
 
 
 http://tiny-tools.sourceforge.net/emacs-elisp-body.html#longlines.el_aut=
 oma=3D=20
 tically_wrap_long_lines

Which in my article buffer renders like this (hoping that
this formatting stuff will still show after sending):

 http://tiny-tools.sourceforge.net/emacs-elisp-body.html#longlines.el_automa=
 tically_wrap_long_lines

Oh well, I'll just not use hard newlines for the time being.

Niklas