How can I get a real automatic line break in with textmate ? ie. a mode where at end of line a line break is REALLY inserted in the text, not just a presentation trick.
On 16. Oct 2006, at 08:47, Erwan David wrote:
How can I get a real automatic line break in with textmate ? ie. a mode where at end of line a line break is REALLY inserted in the text, not just a presentation trick.
You can reformat the current paragraph with ⌃Q — this will insert real line breaks. There is no automatic reflowing of paragraphs available.
Le Mon 16/10/2006, Allan Odgaard disait
On 16. Oct 2006, at 08:47, Erwan David wrote:
How can I get a real automatic line break in with textmate ? ie. a mode where at end of line a line break is REALLY inserted in the text, not just a presentation trick.
You can reformat the current paragraph with 〓Q — this will insert real line breaks. There is no automatic reflowing of paragraphs available.
So Can I put it on wish list ? It would be very handy when writtoiing a mail.
On 16. Oct 2006, at 11:51, Erwan David wrote:
[...] So Can I put it on wish list ? It would be very handy when writtoiing a mail.
It has been requested before, and is on the to-do list. Though I am not sure why you think you need hard wrap for emails. You may want to search for “format flowed” to find our last thread about hard/soft wrap in emails.
Le Mon 16/10/2006, Allan Odgaard disait
On 16. Oct 2006, at 11:51, Erwan David wrote:
[...] So Can I put it on wish list ? It would be very handy when writtoiing a mail.
It has been requested before, and is on the to-do list. Though I am not sure why you think you need hard wrap for emails. You may want to search for “format flowed” to find our last thread about hard/soft wrap in emails.
This does not suits my correspondants MUAs. And it breaks citations in many MUAs or so-called MUAs (beginning with OE which is unable to cite format flowed without revertig to QP and breaking citations formatting).
On 16. Oct 2006, at 13:47, Erwan David wrote:
[...] This does not suits my correspondants MUAs. And it breaks citations in many MUAs or so-called MUAs (beginning with OE which is unable to cite format flowed without revertig to QP and breaking citations formatting).
Are you sure about this? f=f is designed in a way so that clients not aware of f=f will see the letter exactly as had it been hard wrapped.
So the only way this can break is if your receivers MUA has a *broken* implementation of f=f.
Le Mon 16/10/2006, Allan Odgaard disait
On 16. Oct 2006, at 13:47, Erwan David wrote:
[...] This does not suits my correspondants MUAs. And it breaks citations in many MUAs or so-called MUAs (beginning with OE which is unable to cite format flowed without revertig to QP and breaking citations formatting).
Are you sure about this? f=f is designed in a way so that clients not aware of f=f will see the letter exactly as had it been hard wrapped.
So the only way this can break is if your receivers MUA has a *broken* implementation of f=f.
It seems that OE is in this case... (why can it not send in 8bit encoding when answering to a f=f message, if it is not broken ?)
And MUAs not f=f aware will show 1 line per paragraph, which is ugly and may be inconvenient (wrapping in the middle of a word or not showing the whole line).
On 16. Oct 2006, at 14:20, Erwan David wrote:
It seems that OE is in this case... (why can it not send in 8bit encoding when answering to a f=f message, if it is not broken ?)
So if you send a f=f letter to an OE user, and he replies, the reply is encoded with QP, but had you not sent it as f=f, it would be 8 bit? That is a rather peculiar pattern, as whether OE can send the reply as 7 bit or 8 bit would depend on which SMTP it goes through.
That said, sending a 7 bit QP reply is not in anyway broken, it is in fact what most mailers do, since you can’t blindly assume that SMTP’s will support 8 bit.
And MUAs not f=f aware will show 1 line per paragraph, which is ugly and may be inconvenient (wrapping in the middle of a word or not showing the whole line).
No they will not. Take my second reply in this thread, if you view it in Mail it appears first as a quoted paragraph and then a non-quoted paragraph. Both flow to the width of the window.
This is how it looks in a UA not supporting f=f: http:// lists.macromates.com/pipermail/textmate/2006-October/013851.html
The reason is that behind the scenes the UA does send it as hard wrapped, but puts a space after each of the lines which the UA wrapped, signaling to the receiver (that does support f=f) that the line break should be removed.
In addition to having the paragraphs reflow to the width of the *receivers* window size, hard wrapped mails have the disadvantage that each time a line is quoted, it grows by at least two bytes, so it will quickly be too long for the current hard wrap setting, meaning the last word is moved to the next line, either producing unquoted lines among the quoted lines, or quoted text with a very ragged right border. f=f solves this problem as well.
Le Mon 16/10/2006, Allan Odgaard disait
On 16. Oct 2006, at 14:20, Erwan David wrote:
It seems that OE is in this case... (why can it not send in 8bit encoding when answering to a f=f message, if it is not broken ?)
So if you send a f=f letter to an OE user, and he replies, the reply is encoded with QP, but had you not sent it as f=f, it would be 8 bit? That is a rather peculiar pattern, as whether OE can send the reply as 7 bit or 8 bit would depend on which SMTP it goes through.
Yes it is... and yes OE is a very special thing..
That said, sending a 7 bit QP reply is not in anyway broken, it is in fact what most mailers do, since you can’t blindly assume that SMTP’s will support 8 bit.
It makes some burden on the receiving end which is not wanted.
And MUAs not f=f aware will show 1 line per paragraph, which is ugly and may be inconvenient (wrapping in the middle of a word or not showing the whole line).
No they will not. Take my second reply in this thread, if you view it in Mail it appears first as a quoted paragraph and then a non-quoted paragraph. Both flow to the width of the window.
Ok, so it must be that my MUA (mutt) is NOT f=f aware in sending. It is possible, but since I cannot find any other mailer which can correctly handle threading, ML and other prioritary features...
* Erwan David erwan@rail.eu.org [2006-10-16 07:55]:
Ok, so it must be that my MUA (mutt) is NOT f=f aware in sending. It is possible, but since I cannot find any other mailer which can correctly handle threading, ML and other prioritary features...
Mutt can send f=f mail. See text_flowed in muttrc(5).
Le Mon 16/10/2006, Grant Hollingworth disait
- Erwan David erwan@rail.eu.org [2006-10-16 07:55]:
Ok, so it must be that my MUA (mutt) is NOT f=f aware in sending. It is possible, but since I cannot find any other mailer which can correctly handle threading, ML and other prioritary features...
Mutt can send f=f mail. See text_flowed in muttrc(5).
Thanks, but it then does a very ugly indentation (no space between ">" and text, that is not readable), and doc says "To actually make use of this format's features, you'll need support in your editor. "
What support is it ?
(this mail is the first one I try with text_flowed = yes, let's hope it is readable)
* Erwan David erwan@rail.eu.org [2006-10-16 11:03]:
Thanks, but it then does a very ugly indentation (no space between ">" and text, that is not readable), and doc says "To actually make use of this format's features, you'll need support in your editor. " What support is it ?
Mutt ignores $indent_string if $text_flowed is set. I think it's to avoid nested quotation with spaces ("> > blah blah"). f=f says [1] that is has to be ">>blah blah" or ">> blah blah". Most graphical mail clients use a "quotation bar" instead of showing the greater-than symbols.
Your editor needs to handle reflowing the lines. For Vim, I have this in my .muttrc: [2] set editor="vim -c 'set tw=72 fo=tcoqwanl12 et'"
I guess TextMate's mail bundle should do something similar. I'd use it, but my mutt is on a remote machine.
(this mail is the first one I try with text_flowed = yes, let's hope it is readable)
And this is my first. It seems okay.
[1] http://www.ietf.org/rfc/rfc2646.txt [2] http://forum.textdrive.com/viewtopic.php?pid=103329
Erwan David wrote:
Thanks, but it then does a very ugly indentation (no space between ">" and text, that is not readable), and doc says "To actually make use of this format's features, you'll need support in your editor. "
What support is it ?
(this mail is the first one I try with text_flowed = yes, let's hope it is readable)
Could be better… notice the weird gaps there in the quoted documentation.
-Jacob
Le Mon 16/10/2006, Jacob Rus disait
Erwan David wrote:
Thanks, but it then does a very ugly indentation (no space between ">" and text, that is not readable), and doc says "To actually make use of this format's features, you'll need support in your editor. "
What support is it ?
(this mail is the first one I try with text_flowed = yes, let's hope it is readable)
Could be better… notice the weird gaps there in the quoted documentation.
Yes it looks like a OE quotation...
On 16. Oct 2006, at 19:02, Erwan David wrote:
Thanks, but it then does a very ugly indentation (no space between ">" and text, that is not readable), and doc says "To actually make use of this format's features, you'll need support in your editor. "
What support is it ?
Good quesiton… maybe mutt does not perform the preflight “encoding” and expects the script which calls the external editor to do it (I wouldn’t say this was a job for the editor itself).
Judging from your letter, mutt indeed failed to properly encode the message in the f=f style (but did add the header) -- so it would indeed seem that mutt relies on someone else to encode the message.
It is trivial to write a script for this though, if I wasn’t badly needing a break from having replied to emails for more than two hours now, I would write one for you ;)
-
Allan Odgaard -
Erwan David -
Grant Hollingworth -
Jacob Rus