Re: stuff_all_quoted
On 2006-08-16, William Yardley <mutt-dev@xxxxxxxxxxxxxxxxx> wrote:
> On Wed, Aug 16, 2006 at 05:52:10PM -0400, Derek Martin wrote:
> > On Wed, Aug 16, 2006 at 01:43:24PM -0700, William Yardley wrote:
>
> > > so to put it differently, does anyone have any reason why Gary Johnson's
> > > "stuff_all_quoted" patch should *not* be included (and, possibly even
> > > made the default)?
>
> > I don't, but I do think the name of the variable is awful. It doesn't
> > seem to convey any idea of what it does, and sounds kind of, er,
> > juvenile. As in, "I got stuff all quoted," or something of the sort.
> > Maybe we can call it all_your_quoted_stuff_are_belong_to_us? ;-)
>
> Sure - the name doesn't matter at all to me (and I doubt it does to Gary
> either).
You'll get no argument here. I have no problem at all with anyone
changing that name to something better. I couldn't think of
anything very good when I was writing the patch, so I just took the
description of what it does, using the terminology of RFC 2646,
which is to
space-stuff all lines of format=flowed, quoted text
and removed all but the most important words.
> On Wed, Aug 16, 2006 at 06:15:25PM -0400, Kyle Wheeler wrote:
> > On Wednesday, August 16 at 01:43 PM, quoth William Yardley:
>
> > > Since almost all editors used by mutt users do *not* support
> > > generation of flowed text, I think it makes sense to (by default)
> > > display and quote flowed messages in a way that is consistent with
> > > other messages received by mutt.
>
> > Almost all? What, is vim the only one that can?
>
> I'm honestly not convinced that vim can *properly* generate flowed text.
> I've only messed around with it a very little, but I think there is some
> stuff that really should happen when the message is sent, and not
> before. I'm wondering if it would be possible / desirable to let mutt
> handle some of this, though I'm not sure if there's a reasonable way to
> do that since mutt isn't its own editor.
>
> I'm not an expert, but I think this kind of thing is harder to
> accomplish when the editor and MUA are two different things, since
> there's certain stuff that's a lot easier to verify / set correctly
> right before the message is sent.
>
> Without going through all of rfc2646....
> (http://www.faqs.org/rfcs/rfc2646.html)
>
> A generating agent SHOULD:
>
> 1. Ensure all lines (fixed and flowed) are 79 characters or
> fewer in length, counting the trailing space but not
> counting the CRLF, unless a word by itself exceeds 79
> characters.
> 2. Trim spaces before user-inserted hard line breaks.
> 3. Space-stuff lines which start with a space, "From ", or
> ">".
>
> Can Vim handle all of these requirements reliably? I can think of a lot
> of scenarios where the user could pretty easily accidentally cause vim
> to generate bogus flowed text, causing a lot of problems. Honestly, I
> have given a quick try to "fo+=w" in vim, and it doesn't really seem to
> do anything special.
I use "fo+=aw" whenever "filetype=mail" and for the most part, it
seems to work pretty well. That is, it puts a space before every
"soft" break and keeps all lines to 'textwidth' or less (I use
"textwidth=72" rather than 79). It does not "[t]rim spaces before
user-inserted hard line breaks"--if there was a space in front of
the cursor when the user hit Enter, Vim leaves it there--but I think
that could be "fixed" with a mapping. Vim does not space-stuff any
lines on its own, although that could be handled by a BufWritePre
autocommand along with a BufWritePost autocommand to undo the
stuffing in case the user is not done editing. That last
requirement (or suggestion) might be better handled by mutt, though.
I never send "format=flowed" messages. The only reason I use
"fo+=aw" is so that Vim will automatically reformat my paragraphs as
I type.
You're right about it being easy for a Vim user to generate bogus
flowed text: there's no way for Vim to know whether a line should
or should not end in a space unless Vim inserted the line break
itself; and even with "fo+=a", Vim doesn't always automatically
reflow every line it could. So the user has to pay attention.
> I'm not aware of any way to generate flowed text with emacs, jed, pico,
> nano, or other common editors people use with mutt, though someone
> please let me know if I'm wrong.
>
> FWIW, Pine does support flowed text (in the 4.6x versions), though I
> don't think there's a way to use Pico to generate flowed text when not
> using Pine.
I wonder how the formatting task is partitioned between Pico and
Pine.
> On Wed, Aug 16, 2006 at 06:25:01PM -0400, Kyle Wheeler wrote:
> > On Wednesday, August 16 at 06:15 PM, quoth Kyle Wheeler:
> > > On Wednesday, August 16 at 01:43 PM, quoth William Yardley:
>
> > > My only objection is that it doesn't work for me. When I reply to
> > > format-flowed emails, I get >text regardless of the setting of
> > > $stuff_all_quoted. Then again, I get that regardless of whether the
> > > message I'm replying to is format-flowed or not.
>
> > Ehrm, I spoke too soon. Here's what really happens:
> >
> > Setting text_flowed causes $indent_string to be ignored. Because
> > $indent_string is ignored, replying to NON format=flowed messages
> > causes them to be quoted like so: >text. But because of this patch,
> > replying to the rare emails that ARE format=flowed does work properly.
> >
> > So really, my objection is that this patch introduces a behavior
> > inconsistency when used by someone who has $text_flowed set. Without
> > this patch, *all* replies are of the form >text when $text_flowed is
> > set, but with it, normal emails are "broken" and only format=flowed
> > messages are handled properly.
>
> I can reproduce this. So yeah - text should be quoted as:
>
> >> foo
> rather than
> >>foo
> in *either* case when $text_flowed is set.
>
> FWIW, >> foo and > foo are equivalent, but > > foo means a quote of
> depth one with a content of "> foo".
> (from section 4.5).
>
> In any event, the behavior you're describing isn't broken - just
> inconsistent -- and should be easy to fix (if Gary's not on the list, I
> can ping him and see if he's willing to take a look at it).
I haven't given this a lot of thought, nor have I read the RFC in a
while, but I'm not sure what it means to "fix" this. As I recall,
RFC 2646 (now RFC 3676) makes a clear distinction between quoted
text and just text, and what may look like quoted text to you may be
considered by the RFC to be just text that happens to have leading
>'s.
> I *personally* am most interested in the following two scenarios:
>
> 1) Display of flowed text within mutt's pager. I think this is a
> no-brainer, since one of the big points of having flowed text is that
> you can display the quoted material differently from how it's actually
> encoded in the raw message.
>
> In fact, it might be cool to even have an option to display (but not
> quote) flowed text with a solid bar like in Thunderbird / Mozilla,
> something like:
>
> | | Foo Bar adsfwejasdfasdfasdf asdfk erdafd some text here and this is
> | | quoted
> |
> | this is a second level quote here.... blah blah blah and now I'm going
> | to the next line
>
> and maybe even have an option to have it actually reformat itself to fit
> the terminal width. But I'm getting carried away....
>
> 2) Quoting messages that are format=flowed when $text_flowed is unset.
>
> But I think it would be good to fix the behavior described above as
> well.
If you want to extend the scope of this patch, then we need to
consider what we want to have happen and what is allowed to happen
to the line ">>foo" in a received message that is then replied to in
the following seven cases:
1. Received as format=fixed, replied to as format=fixed.
2. Received as format=fixed, replied to as format=flowed.
3. Received as format=flowed, replied to as format=fixed.
4. Received as format=flowed, replied to as format=flowed.
where in cases 2 - 4, space-suffing may be either "on" or "off".
When I wrote this patch, all I was interested in was making ">foo"
received in a format=flowed message look like "> foo" while not
violating any RFCs.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx | Wireless Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA