Re: $reply_prefix

2022-01-13 Thread Tapani Tarvainen
On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy (ke...@8t8.us) wrote: > I've been told other prefixes are often used in some lists, and the > practice is getting more common. Other prefixes have also long been used by some non-English speakers and lists. While it does have its

Re: $reply_prefix

2022-01-13 Thread Kevin J. McCarthy
On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote: Kevin J. McCarthy wrote on Thu, 13 Jan 2022 at 23:20:55 EST in : I've been told other prefixes are often used in some lists, and the practice is getting more common. Why not give users the option to adjust it, if they deem it

Re: $reply_prefix

2022-01-13 Thread Will Yardley
On Thu, Jan 13, 2022 at 11:57:37PM -0500, John Hawkinson wrote: > I'm not sure the consequences of people using alternative > $indent_strings are as bad as alternative $reply_prefixes, though. One > is confined to the content of a message and the other affects critical > message metadata that is

Re: $reply_prefix

2022-01-13 Thread John Hawkinson
Kevin J. McCarthy wrote on Thu, 13 Jan 2022 at 23:20:55 EST in : > I've been told other prefixes are often used in some lists, and the practice > is getting more common. Why not give users the option to adjust it, if they > deem it appropriate, for some lists? The reason not to is that the

Re: $reply_prefix

2022-01-13 Thread Will Yardley
On Thu, Jan 13, 2022 at 08:20:55PM -0800, Kevin J. McCarthy wrote: > On Fri, Jan 14, 2022 at 03:26:36AM +0100, Vincent Lefevre wrote: > > I strongly disagree with the addition of $reply_prefix (commit > > 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is contrary to > > RFC 5322, and

Re: $reply_prefix

2022-01-13 Thread Kevin J. McCarthy
On Fri, Jan 14, 2022 at 03:26:36AM +0100, Vincent Lefevre wrote: I strongly disagree with the addition of $reply_prefix (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is contrary to RFC 5322, and non-standard prefixes are annoying in practice and not necessarily recognized by other

Re: $reply_prefix

2022-01-13 Thread Will Yardley
On Thu, Jan 13, 2022 at 09:42:27PM -0500, John Hawkinson wrote: > Although my personal preference is that this is not a knob Mutt needs, > I am cognizant that some other popular MUAs use "RE: " rather than > "Re: " and while that looks horrid to my eye, it is not obviously > violative of RFC5322

Re: $reply_prefix

2022-01-13 Thread John Hawkinson
Although my personal preference is that this is not a knob Mutt needs, I am cognizant that some other popular MUAs use "RE: " rather than "Re: " and while that looks horrid to my eye, it is not obviously violative of RFC5322 and some might like Mutt to be configurable to match. Having a check

Re: $reply_prefix

2022-01-13 Thread Vincent Lefevre
On 2022-01-14 03:26:36 +0100, Vincent Lefevre wrote: > I strongly disagree with the addition of $reply_prefix > (commit 9c1ce59874ce1c8e97d0c5bd71847596dafb1d50), as this is > contrary to RFC 5322, and non-standard prefixes are annoying > in practice and not necessarily recognized by other users.

Re: Mutt on ubuntu 20

2022-01-13 Thread Vincent Lefevre
On 2022-01-13 15:36:04 -0600, Derek Martin wrote: > So... The only difference between this and hdrdefault is that > hdrdefault's order does not matter. This is a very minor difference, > and the distinction disappears so long as you provide the "." rule > first, This would mean that it would

Re: Mutt on ubuntu 20

2022-01-13 Thread Derek Martin
On Thu, Jan 13, 2022 at 06:22:26PM +0100, Vincent Lefevre wrote: > On 2022-01-12 14:40:38 -0600, Derek Martin wrote: > > FWIW (particularly with this fixed) I think hdrdefault is redundant, > > I don't think it is. IMHO, hdrdefault means the color when no other > rules match. If you use "color

Re: Mutt on ubuntu 20

2022-01-13 Thread Vincent Lefevre
On 2022-01-12 14:40:38 -0600, Derek Martin wrote: > FWIW (particularly with this fixed) I think hdrdefault is redundant, I don't think it is. IMHO, hdrdefault means the color when no other rules match. If you use "color header ... .", it would override other rules earlier in the list. --