(Replying to Mihai, but keeping Bastian's subject-line change...an operation
which Mutt is not great at, but better than most...I dunno what to do with
In-Reply-To/References: here, tho.)
Mihai Lazarescu wrote on Mon, 12 Sep 2022
at 15:07:37 EDT in :
> It took some work to set it up, but
On Mon, 12 Sep 2022 15:15:55 +
Nacho via Mutt-users wrote:
>> What you describe is becoming more and more history, which I regret.
>> Let me give you the link of an article that should interest you.
>>
>>
> What you describe is becoming more and more history, which I regret.
> Let me give you the link of an article that should interest you.
>
> https://cfenollosa.com/blog/after-self-hosting-my-email-for-twenty-three-years-i-have-thrown-in-the-towel-the-oligopoly-has-won.html
I don't agree with
On Sun, 4 Sep 2022 12:34:11 +
Nacho via Mutt-users wrote:
[...]
>
>Apart from that, the big difference between using whatsapp or email is
>that with email you get independence: I have my own email servers
>using my own domains that just a court can take away from me, use the
>OS and MTA of
On 22-09-07 01:00, raf via Mutt-users wrote:
On Mon, Sep 05, 2022 at 10:45:09PM -0400, Kurt Hackenberg > wrote:
> > > I expect it is done in mutt because it
must be done (for transport), > and it would be a mistake to assume that
it will be done by the > editor, whatever editor it is. I
On Mon, Sep 05, 2022 at 10:45:09PM -0400, Kurt Hackenberg
wrote:
> On Tue, Sep 06, 2022 at 08:54:58AM +1000, Cameron Simpson wrote:
>
> > I'm not sure we're disagreeing here, except for the conceptual
> > separation of the space-stuffing step.
>
> I agree that it's a separate step, or layer.
On Mon, Sep 05, 2022 at 10:53:15PM -0400, Kurt Hackenberg wrote:
Here's an updated version of my Emacs mode for Mutt flowed text...
Here's a picture of it in use, with long lines being word-wrapped by
Emacs's visual-line-mode.
Here's an updated version of my Emacs mode for Mutt flowed text, with
tweaks: displays quoted text in a different color, handles signature
separator lines correctly, has a little more documentation.
(defvar mutt-flowed-text-mode-map
(let ((map (make-sparse-keymap)))
(set-keymap-parent map
On Tue, Sep 06, 2022 at 08:54:58AM +1000, Cameron Simpson wrote:
I'm not sure we're disagreeing here, except for the conceptual
separation of the space-stuffing step.
I agree that it's a separate step, or layer. I just think it might
better be done within the editor -- or special-purpose
On 05Sep2022 12:56, Kurt Hackenberg wrote:
On Mon, Sep 05, 2022 at 07:40:54PM +1000, Cameron Simpson wrote:
It seems a little conceptually cleaner to have the editor do the
whole job, rather than divide it between the editor and Mutt. But
another complication is that you can edit a message
On Mon, Sep 05, 2022 at 07:40:54PM +1000, Cameron Simpson wrote:
It seems a little conceptually cleaner to have the editor do the
whole job, rather than divide it between the editor and Mutt. But
another complication is that you can edit a message more than once...
I think space stuffing is
On 05Sep2022 01:52, Kurt Hackenberg wrote:
On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote:
But not space-stuffing, right?
Aye. I avoid lines commencing with a ">" just because they look quoted
to my eye anyway, so that aside "live" space stuffing in authoring is
something
On 2022/09/04 18:45, raf via Mutt-users wrote:
Hmm. I do "From-munging" on arrival.
I should probably read rfc3676 properly. :-)
Format=flowed includes a thing to protect the message from being damaged
in the future by being written into an mbox file.
On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson wrote:
But not space-stuffing, right?
I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to
refresh my brain. Yeah, I don't think I'd want that when writing a message.
Which I guess is why Mutt space-stuffs the
On 05Sep2022 08:37, raf via Mutt-users wrote:
> I like your indenting of code blocks, but it seems to
> put an additional blank line after each code block.
> That might not be intentional.
Not intentional. I just wanted to keep the 4 space indent used to trigger a
code block for the same
On Sun, Sep 04, 2022 at 05:39:05PM +0200, Jan Eden via Mutt-users
wrote:
> On 2022-09-04 20:37, Cameron Simpson wrote:
> > On 04Sep2022 15:34, raf via Mutt-users wrote:
> > > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
> > > wrote:
>
> > > > The `md2html` script is my personal
On Mon, Sep 05, 2022 at 08:36:54AM +1000, Cameron Simpson
wrote:
> On 05Sep2022 08:24, Cameron Simpson wrote:
> > On 04Sep2022 11:33, Kurt Hackenberg wrote:
> > > But not space-stuffing, right?
>
> I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to refresh
> my brain. Yeah,
On Sun, Sep 04, 2022 at 08:37:21PM +1000, Cameron Simpson
wrote:
> On 04Sep2022 15:34, raf via Mutt-users wrote:
> > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
> > wrote:
> [...]
> > > So I've revisited the manual and found the
> > > `$send_multipart_alternative`
> > > option
On 05Sep2022 08:24, Cameron Simpson wrote:
On 04Sep2022 11:33, Kurt Hackenberg wrote:
But not space-stuffing, right?
I just reread https://www.rfc-editor.org/rfc/rfc3676#section-4.4 to
refresh my brain. Yeah, I don't think I'd want that when writing a
message.
Which I guess is why Mutt
On 04Sep2022 11:33, Kurt Hackenberg wrote:
On 2022/09/04 06:37, Cameron Simpson wrote:
Vim can do 99% of it for you on the fly :-)
But not space-stuffing, right? Which I guess is why Mutt space-stuffs
the format=flowed that it gets back from the editor.
I imagine it could be told to space
On 2022-09-04 20:37, Cameron Simpson wrote:
> On 04Sep2022 15:34, raf via Mutt-users wrote:
> > On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
> > wrote:
> > > The `md2html` script is my personal script, which wraps `pandoc`
> > > and post munges the HTML to indent the code blocks,
On 2022/09/04 06:37, Cameron Simpson wrote:
Do you have any advice for automating spaces at the end
of non-final paragraph lines for format=flowed in vim?
I use these settings:
https://github.com/cameron-simpson/css/blob/main/bin/vim-flowed
which autowraps and leaves trailing spaces
> I smile, that was me. I agree with your point: email use is getting
> relegated to corporate settings, dealing with banks/utilities, some
> services (newsletters).
It's worse than that: what is being relegated by most people is reading and
writing "complex texts" (i.e. more than a few lines),
On 04Sep2022 15:34, raf via Mutt-users wrote:
On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
wrote:
[...]
So I've revisited the manual and found the
`$send_multipart_alternative`
option and its friend `$send_multipart_alternative_filter`. They work well!
So now I have a
On Sun, Sep 04, 2022 at 01:51:25PM +1000, Cameron Simpson
wrote:
> Well, this has been quite the read.
>
> As a plain text person (aren't we all?) I find poor quality mail clients
> annoying, as shown by the motivating screenshot of a plain text hard folder
> message presenting on a narrow
Well, this has been quite the read.
As a plain text person (aren't we all?) I find poor quality mail clients
annoying, as shown by the motivating screenshot of a plain text hard
folder message presenting on a narrow portrait mode mail reader.
There seem to two approaches available:
Il 03 settembre 2022 alle 12:33 Jan Eden via Mutt-users ha scritto:
> While I find this thread quite entertaining, we should accept that we
> are an increasingly small group of people who care not just about plain
> text email (and its formatting), but about email in general.
>
> Over at
On 2022-09-03 00:46, Derek Martin wrote:
> On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote:
> > Derek Martin wrote on Wed, 31 Aug 2022
> > at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>:
> >
> > Evaluating the strength of a SHOULD requires looking at pragmatic
> >
On Wed, Aug 31, 2022 at 07:45:05PM -0400, John Hawkinson wrote:
> Derek Martin wrote on Wed, 31 Aug 2022
> at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>:
>
> Evaluating the strength of a SHOULD requires looking at pragmatic
> realities. And that reality is that lots of messages are
It not worked as expected
https://pasteboard.co/ZP492mei7cBc.jpg
Marcelo
Enviado a partir de dispositivo móvel
Em qui., 1 de set. de 2022 16:42, Marcelo Laia
escreveu:
> Hi José Maria,
>
> I am doing a test.
>
> In this message, I seted in vimrc this lines:
>
>
> set wrap
> set linebreak
>
>
Hi José Maria,
I am doing a test.
In this message, I seted in vimrc this lines:
set wrap
set linebreak
Here, I will post a lot off words to test.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim
On 2022/09/01 09:31, Mark H. Wood wrote:
From my POV, when someone uses one of those MUAs that think a
paragraph and a line are the same thing, that person's emails make
more work for me, and I find the person annoying.
"More work" means, for example, that if I try to quote such a
On Wed, Aug 31, 2022 at 06:35:15PM -0500, Derek Martin wrote:
> On Wed, Aug 31, 2022 at 04:38:11PM -0400, John Hawkinson wrote:
> > (b) Even if recipients *do* rotate, they will still have the
> > subconscious/psychological result that "Dealing with Derek's emails
> > takes more work, he is
On Wed, Aug 31, 2022 at 02:48:55PM -0500, Derek Martin wrote:
> On Wed, Aug 31, 2022 at 01:46:49PM -0400, John Hawkinson wrote:
> > As for standards-compliance, that's a red herring. Long lines are
> > not going to trip up any modern client, they're just not.
>
> It may be less relevant today,
On Thu, Sep 01, 2022 at 08:20:21AM +0200, Angel M Alganza wrote:
> On Wed, Aug 31, 2022 at 05:22:48PM -0400, Kurt Hackenberg wrote:
>
> > Very long lines -- one line per paragraph -- changes the meaning of
>
> After top posting that is probably the most annoying thing on email.
> And from what
First, I'd like to thank Tavis for starting this discussion. I am very
pleased to see I am not the only one struggling with this.
On 29Aug22 13:28-0400, Logan Rathbone wrote:
> FWIW, the solution/compromise I ended up using was to compose
> multipart/alternative mails with mutt, sending a very
On Wed, Aug 31, 2022 at 05:22:48PM -0400, Kurt Hackenberg wrote:
Very long lines -- one line per paragraph -- changes the meaning of
After top posting that is probably the most annoying thing on email.
And from what I can tell reading this thread, there will always be some
nasty software and
On Wed, Aug 31, 2022 at 02:48:55PM -0500, Derek Martin
wrote:
> The bottom line is there is absolutely no reason why hard-wrapped
> lines of plain text at 72 characters should ever need to display
> unreadably for any desktop user, or even anyone on any reasonable
> mobile device which can
On 2022-08-31, Tavis Ormandy wrote:
> If it was up to me I'd continue using
> tw=72, but sometimes a compromise
> is necessary.
Perhaps tw=40 would be sufficient to
make everybody happy. Reminds me a bit
of my old Apple, ][+ days with 40-column
upper-case only.
;-)
-tkc
Derek Martin wrote on Wed, 31 Aug 2022
at 19:35:15 EDT in <20220831233515.gf13...@bladeshadow.org>:
> > I don't really think we're flouting the standards.
>
...
> So it IS only a recommendation, not a requirement--but it's a pretty
> strong recommendation, and either way you're still flouting
On Wed, Aug 31, 2022 at 04:38:11PM -0400, John Hawkinson wrote:
> I don't mean to monopolize the conversation, but:
>
> Derek Martin wrote on Wed, 31 Aug 2022
> at 15:48:55 EDT in <20220831194855.gc13...@bladeshadow.org>:
>
> > I don't see why this matters, because as I already pointed out, any
On Wed, Aug 31, 2022 at 05:43:41PM -0400, John Hawkinson wrote:
> John Hawkinson wrote on Wed, 31 Aug 2022
> at 16:38:11 EDT in :
>
> > I suppose I should send some 2,000-character paragraph emails as
> > tests to see what happens, but I very much doubt there will be
> > problems as a result.
>
On Wed, Aug 31, 2022 at 05:43:41PM -0400, John Hawkinson wrote:
Very long lines -- one line per paragraph -- changes the meaning of
ASCII/Unicode.
err, what? I am confused what we are discussing.
ASCII was not designed to be automatically word-wrapped. The idea was
that a line keeps going
Kurt Hackenberg wrote on Wed, 31 Aug 2022
at 17:22:48 EDT in <2d716370-8c96-adcf-11d4-939a3f808...@panix.com>:
> > I don't really think we're flouting the standards.
>
> Very long lines -- one line per paragraph -- changes the meaning of
> ASCII/Unicode.
err, what? I am confused what we are
On 2022/08/31 16:38, John Hawkinson wrote:
I don't really think we're flouting the standards.
Very long lines -- one line per paragraph -- changes the meaning of
ASCII/Unicode.
I could live with that if it were labelled, with a new MIME subtype, but
I agree that a new subtype probably
I don't mean to monopolize the conversation, but:
Derek Martin wrote on Wed, 31 Aug 2022
at 15:48:55 EDT in <20220831194855.gc13...@bladeshadow.org>:
> I don't see why this matters, because as I already pointed out, any
> desktop GUI MUA will have no trouble displaying 72 character lines
>
On 2022-08-31, Derek Martin wrote:
>> That'd be true if we were sending emails to ourselves
>> but a lot of us send email to people who read their mail primarily
>> or exclusively on phones and in desktop GUIs that don't approximate
>> 72-chars.
>
> I don't see why this matters, because as I
On Wed, Aug 31, 2022 at 07:57:43PM +0200, Francesco Ariis wrote:
> > The problem is popular modern mobile and web-based MUAs don't handle
> > this and can make unexpected linewrap decisions. It's no issue when
> > emailing UNIX nerds, but non-nerds think I'm doing something wrong.
>
> I do not
On Wed, Aug 31, 2022 at 01:46:49PM -0400, John Hawkinson wrote:
> Derek Martin wrote on Wed, 31 Aug 2022
> at 13:39:42 EDT in <20220831173942.gb13...@bladeshadow.org>:
>
> > It's been my experience that if you read your mail on anything other
> > than a phone, the 72-character line width is
On 2022-08-30, Jan Eden via Mutt-users wrote:
> Apart from the known drawbacks of HTML mail, the markdown2html script
> has a couple of requirements to further complicate my (already overly
> complex) mailstack.
Yep, I can understand that. I think the best option might be piping your
mail through
John,
Il 31 agosto 2022 alle 14:05 John Hawkinson ha scritto:
> Here's an inlined PNG showing how your email displayed for me in the
> Android Gmail app.
> Note the short lines like "clients my emails" and "provide a .png on". It
> could certainly be worse (and it often is), but it's not great:
Francesco Ariis wrote on Wed, 31 Aug 2022
at 13:57:43 EDT in :
> I do not have a smartphone, can I ask someone to provide a .png on
> how this or other similar messages look on a smartphone client? I am
> very curious and hopefully a definite guideline will pop up from this
I sent a previous
On Wed, Aug 31, 2022 at 12:39:42PM -0500, Derek Martin wrote:
I can't say I know how various MTAs handle lines longer than 998
characters, but I would expect at least a subset would either
truncate them or reject your message... or at least that it would be
wise to assume so.
Mail readers
Hello everyone,
Il 29 agosto 2022 alle 00:28 Tavis Ormandy ha scritto:
> The problem is popular modern mobile and web-based MUAs don't handle
> this and can make unexpected linewrap decisions. It's no issue when
> emailing UNIX nerds, but non-nerds think I'm doing something wrong.
I am quite
Derek Martin wrote on Wed, 31 Aug 2022
at 13:39:42 EDT in <20220831173942.gb13...@bladeshadow.org>:
> It's been my experience that if you read your mail on anything other
> than a phone, the 72-character line width is fine, and even on a phone
> if you turn it sideways it's still fine. My
On Mon, Aug 29, 2022 at 07:10:14AM -0400, John Hawkinson wrote:
> Kurt Hackenberg wrote on Mon, 29 Aug 2022 at 02:58:32 EDT in
> :
>
> > If you put a newline only at the end of a paragraph, it won't be
> > displayed correctly by software that doesn't expect that. Such
> > software will
On 2022-08-30 14:58, Kurt Hackenberg wrote:
On Tue, Aug 30, 2022 at 09:09:34AM +0200, Jan Eden via Mutt-users wrote:
I would consider f=f an acceptable compromise, because while it looks
nicer on (some) mail clients, it breaks automatic list indentation
created in vim (fo-n). The following is
On Tue, Aug 30, 2022 at 02:58:38PM -0400, Kurt Hackenberg wrote:
Also, does vim have some option to make whitespace at end of line
visible, or some other way to show that text is marked as flowed? That
would be a big help.
I have:
setl list
set listchars=trail:•
This uses a nice fat dot to
On Tue, Aug 30, 2022 at 09:09:34AM +0200, Jan Eden via Mutt-users wrote:
I would consider f=f an acceptable compromise, because while it looks
nicer on (some) mail clients, it breaks automatic list indentation
created in vim (fo-n). The following is displayed properly in mutt with
linebreaks,
On 2022-08-29 19:07, Tavis Ormandy wrote:
> On 2022-08-29, Logan Rathbone wrote:
> > On Mon, Aug 29, 2022 at 10:43:45AM EDT, Tavis Ormandy wrote:
> >> No, format=flowed sounds like the perfect solution but I've tested and
> >> as far as I can tell it's ignored by gmail on Android, for example.
> >
On 2022/08/29 13:28, Logan Rathbone wrote:
Do phone mail readers understand text/plain format=flowed?
No, format=flowed sounds like the perfect solution but I've tested and
as far as I can tell it's ignored by gmail on Android, for example.
So now we know about Gmail. What about other
On Sun, Aug 28, 2022 at 08:49:50PM -0400, John Hawkinson wrote:
I have not shaken the feeling that maybe I should learn how to
compose format=flowed messages, but I guess it's not worth the
trouble -- or at least I never managed to get it to work right.
And yes, I toggle M-x visual-line-mode
On 2022-08-29, Logan Rathbone wrote:
> On Mon, Aug 29, 2022 at 10:43:45AM EDT, Tavis Ormandy wrote:
>> No, format=flowed sounds like the perfect solution but I've tested and
>> as far as I can tell it's ignored by gmail on Android, for example.
>
> FWIW, the solution/compromise I ended up using
On Mon, Aug 29, 2022 at 10:43:45AM EDT, Tavis Ormandy wrote:
> On 2022-08-29, Kurt Hackenberg wrote:
> > Maybe text/plain format=flowed is a solution. It's displayed
> > correctly by software that assumes format=fixed (on a screen that's
> > wide enough), and at any width by software that
On 2022-08-29, Kurt Hackenberg wrote:
> Maybe text/plain format=flowed is a solution. It's displayed
> correctly by software that assumes format=fixed (on a screen that's
> wide enough), and at any width by software that understands
> format=flowed. Mutt can display format=flowed correctly at
On Mon, Aug 29, 2022 at 03:43:37PM +0200, Angel M Alganza wrote:
Perhaps if there was a way to configure Mutt to wrap long lines while
reading mail with them and Vim to do the same (visually but not actually
including the new lines) while editing they would be bearable for us who
preffer wrapped
On Mon, Aug 29, 2022 at 07:10:14AM -0400, John Hawkinson wrote:
omitting newlines from internal line breaks in paragraphs has proved
to be a much better compromise than including them. It displays much
better in a wide array of clients, especially modern ones (webmail
clients, mobile clients),
Kurt Hackenberg wrote on Mon, 29 Aug 2022 at 02:58:32 EDT in
:
> If you put a newline only at the end of a paragraph, it won't be displayed
> correctly by software that doesn't expect that. Such software will probably
> either break each line exactly at the right margin, maybe in the middle of
On Mon, Aug 29, 2022 at 12:28:29AM -, Tavis Ormandy wrote:
Hello, long time mutt user here - I've always hard wrapped my lines at
72 columns for as long as I can remember.
The problem is popular modern mobile and web-based MUAs don't handle
this and can make unexpected linewrap decisions.
I gave up on linewrapping emails I transmit several years ago for the reasons
you describe, and it has been the right decision.
I have not shaken the feeling that maybe I should learn how to compose
format=flowed messages, but I guess it's not worth the trouble -- or at least I
never managed
70 matches
Mail list logo
