On Wednesday, August 16 at 03:55 PM, quoth William Yardley:
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.
Hmm... maybe. I thought the only restrictions were: 78 columns, plus lines that wrap end in a space. 'course, there may be extra details for multibyte characters...
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.
Yeah, I don't think so. Especially since you don't want to wrap things that, for example, are indented (like ASCII art and pull-quotes).
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.
The real fun begins when you add 'a' to your format options as well. It's a highly convenient way to edit text that you want line-wrapped.
Anyway... let's see: set textwidth=78 takes care of the first requirement. If I'm reading it correctly, 2 takes care of itself... And 3 can be done via a reasonably trivial function. For example:
function! Fixflowed()
" save position
let l = line(".")
let c = col(".")
normal G$
" whiles are used to avoid nasty error messages.
" add spaces to the end of every line
while search('[^]> :]\n>\%(> \?\)*[^> ]','w') > 0
s/\([^]> :]\)\n\(>\%(> \?\)*[^> ]\)/\1 \r\2/g
endwhile
" make sure there's only one space at the end of every line
while search('.* \n','w') > 0
s/\(.* \) \n/\1\r/g
endwhile
" now, fix the wockas spacing from the text
while search('^[> ]*>[^> ]','w') > 0
s/^\([> ]*>\)\([^> ]\)/\1 \2/
endwhile
" restore the original location, such as it is
execute l . " normal " . c . "|"
endfunction
That may mishandle some cases... but I'm not sure. Should be easy to
fix if it does.
FWIW, >> foo and > foo are equivalent, but > > foo means a quote of depth one with a content of "> foo". (from section 4.5).
Yeah... and yet this is probably the first email I've ever dealt with where that's been an issue. Mostly, I just cram all the >'s together because I think it looks cleaner that way. ;)
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).
That would be excellent if you can convince him.
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
That would be very slick.
and maybe even have an option to have it actually reformat itself to fit the terminal width. But I'm getting carried away....
Mutt already re-flows the text if your terminal is narrower than the original text (try it, you'll like it). Reformatting for a *wider* terminal, however, has come up previously on the list, and was firmly rejected by Thomas.
~Kyle
--
It is dangerous to be right when the government is wrong.
-- Voltaire
Attachment:
pgpFSBh6WkYkK.pgp
Description: PGP signature