Re: Mutt on ubuntu 20

[Vincent Lefevre]

On 2022-01-14 14:30:40 -0600, Derek Martin wrote:
> On Fri, Jan 14, 2022 at 03:19:39AM +0100, Vincent Lefevre wrote:
> > 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 not be possible to change the default
> > header color from a running Mutt.
> 
> No it doesn't; use uncolor, then enter the rules in the correct order.

This is really stupid: if one has a dozen on rules, one would have
to reenter them. A waste of time, with possible errors. Or put them
in their own file, sourced with "source", but this would mean that
header color settings would have to be put in 2 different config
files, which is ugly for maintenance.

> I'm well aware doing that would be dumb, but it IS possible.

Well, it is not possible *without size effects*. If I want to change
the default header color (e.g. temporarily), I want just that, not
to do other things that would need me to enter other commands.

> It would be far more sensible to just restart Mutt with the updated
> config, which is what any reasonable person would do, and which is
> necessary in any case to make the change permanent.

Again, this is a very silly suggestion. This means:
1. Modify Mutt's config.
2. Restart Mutt.
3. Modify Mutt's config again (so that the other instances still
   get the usual config).
4. Possibly find the way to get back the status before Mutt was
   restarted.

> > Currently, my header color settings do not depend on any order as they
> > are mutually exclusive
> 
> That's possible, if your rules are very carefully crafted;

I didn't have to be particularly careful. These are rules only
based on the header names.

> > > just as you must already do with send-hook and every other
> > 
> > I don't use send-hook (and other hooks) on "color header".
> 
> That's not what I'm saying.
> 
> # apply a default folder hook
> folder-hook . set x=foo
> # other folders
> folder-hook work set x=bar
> folder-hook ice-cream set x=baz
> ...
> 
> The . rule must come first.  There is no default folder-hook.  The
> necessity of ordering has precedence in Mutt and is inherent in any
> case.

OK, I now understand what you mean. However, one could argue whether
there could be a "default" hook. The case of default (with ".") is
very common and needing to have it first is probably error prone with
long muttrc files, possibly with inclusions ("source" command).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mutt on ubuntu 20

[Derek Martin]

On Fri, Jan 14, 2022 at 03:19:39AM +0100, Vincent Lefevre wrote:
> 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 not be possible to change the default
> header color from a running Mutt.

No it doesn't; use uncolor, then enter the rules in the correct order.

I'm well aware doing that would be dumb, but it IS possible.  It would
be far more sensible to just restart Mutt with the updated config,
which is what any reasonable person would do, and which is necessary
in any case to make the change permanent.  This is such an uncommon
case that considering it seems silly, but regardless, it's false.

> Currently, my header color settings do not depend on any order as they
> are mutually exclusive

That's possible, if your rules are very carefully crafted; but it's
not generally true as Mutt's regex rules are inherently ordered, and
if it is true in your case it is specific to your rules, not Mutt's
functionality generally.  But it's irrelevant; the config language not
having the precise semantics you personally prefer does not change the
fact that you STILL CAN achieve the same result without the default
keyword.

Redundant.

> > just as you must already do with send-hook and every other
> 
> I don't use send-hook (and other hooks) on "color header".

That's not what I'm saying.

# apply a default folder hook
folder-hook . set x=foo
# other folders
folder-hook work set x=bar
folder-hook ice-cream set x=baz
...

The . rule must come first.  There is no default folder-hook.  The
necessity of ordering has precedence in Mutt and is inherent in any
case.

And yes, ice cream definitely deserves its own mail folder. =8^)

I've had my fill of this pointless argument.  Especially pointless
since I'm not actually advocating removing it.

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[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 not be possible to change the default
header color from a running Mutt.

Currently, my header color settings do not depend on any order as they
are mutually exclusive (which is a good thing for maintenance). But if
hdrdefault is removed, this would no longer be the case.

> just as you must already do with send-hook and every other

I don't use send-hook (and other hooks) on "color header".

> thing mutt provides with similar semantics, which don't have explicit
> default keywords.  Users familiar with other similar Mutt features
> should and would expect that, and in any case it should be likewise
> documented.
> 
> Thus hdrdefault can be omitted by ensuring that a "." rule appear
> first in the list of rules, without loss of function (assuming of
> course that this were fixed, as I previously said): Therefore it is
> redundant, by definition.  If you want to argue that redundant means
> something different, please feel free to contact the fine folks at
> Oxford.  In any case this is precisely the meaning I intended when I
> wrote it.

It is not redundant when considering one can run commands from Mutt
(with ).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mutt on ubuntu 20

[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 header ... .", it would override
> other rules earlier in the list.

I'll first point out that this is entirely a semantic argument, not a
technical one. I've already said I don't think this should have any
bearing on whether this get fixed, for whatever that's worth.

"Redundant" has a number of meanings, the relevant one here being "(of
words or data) able to be omitted without loss of meaning or
function."[1]

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, just as you must already do with send-hook and every other
thing mutt provides with similar semantics, which don't have explicit
default keywords.  Users familiar with other similar Mutt features
should and would expect that, and in any case it should be likewise
documented.

Thus hdrdefault can be omitted by ensuring that a "." rule appear
first in the list of rules, without loss of function (assuming of
course that this were fixed, as I previously said): Therefore it is
redundant, by definition.  If you want to argue that redundant means
something different, please feel free to contact the fine folks at
Oxford.  In any case this is precisely the meaning I intended when I
wrote it.

-=-=-

[1] Google's dictionary, provided by Oxford Languages.
https://www.google.com/search?q=redundant=3ZfgYceaNIOC-QaBnZfQCw=0ahUKEwiH_bOq1K_1AhUDQd4KHYHOBboQ4dUDCA4=5=redundant_lcp=Cgdnd3Mtd2l6EAMyBwgAELEDEEMyBwgAELEDEEMyCAgAEIAEELEDMggIABCABBCxAzIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDoHCAAQRxCwAzoHCAAQsAMQQzoICAAQ5AIQsAM6EAguEMcBENEDEMgDELADEEM6CgguEMgDELADEEM6CAguELEDEIMBOgUILhCABDoICC4QgAQQsQM6EQguEIAEELEDEIMBEMcBENEDOg4ILhCABBCxAxDHARCjAjoFCC4QsQM6BQgAEJECOgQIABBDOgUILhCRAjoECC4QQzoRCC4QsQMQgwEQxwEQ0QMQkQI6CAguELEDEJECOgoILhDHARCvARBDOgcIABDJAxBDSgQIQRgASgQIRhgBUPQFWPYSYP8TaAFwAngAgAFTiAHbBJIBATmYAQCgAQHIARLAAQE=gws-wiz

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Mutt on ubuntu 20

[Derek Martin]

On Tue, Jan 11, 2022 at 05:53:45PM -0800, Kevin J. McCarthy wrote:
> On Tue, Jan 11, 2022 at 03:32:09PM -0600, Derek Martin wrote:
> > OK but do you agree that behavior is wrong? :) It's one header,
> > regardless of the wrapping...
> 
> I'll have to think more closely about it.  I do agree that the matching on
> the folded line overriding the previous 'color header' match is confusing.
> I don't believe the fix is hard, either.

FWIW/TLDR, I think as a matter of principle it should be fixed, and I
doubt there can be any compelling arguments (beyond not being willing
to volunteer the time to do it, which is a good one) that it
shouldn't.  I won't be heartbroken if it doesn't get fixed since I
have config that works, but I do think not fixing the inconsistency
makes Mutt suck just a little bit more...

Now, the details:

> However, it's not just about wrong vs. right

I do agree--wrong is wrong, but there are two other questions to
answer. There's the question of, "Does this provide useful
functionality for some real-world use case?"  I think the answer is
that it does not. As you yourself said, the behavior is confusing,
which does not lend itself to real-world use.  As such the
behavior is, I think, clearly broken.  

>  but also about precedence of the behavior, and I believe this one
>  goes back to 1.5.21.  If I make the change, I may then have
>  long-time users reporting a "genuine" regression.

To me this argument is a much weaker one--wrong is wrong, and
depending on a bug is a bug. :)  I don't think this is one of the two
questions... not precisely anyway (see below).

Also, this DID work correctly (i.e. as I believe it should work), in
for example 1.4.2.3 (I did actually check).  So this IS a genuine
regression... just one that no one has apparently noticed (or rather,
reported) for a very, very long time.  I didn't do the binary search
to see where it stopped, I'll trust your suggestion that it was
1.5.21. :)

[FWIW this IS something I have noticed on occasion that has been
bugging me for a long while... but it didn't happen enough to distract
me enough from what I was doing to actually look into it.  Lately it
has though, and I understand exactly why:  As my professional role and
responsibilities have expanded, so too have the number of mail threads
I've been on with larger recipient lists.  Otherwise, the messages I
send and receive very typically have at most one or two people, and/or
a mailing list.  Not enough to warrant wrapping of the recipient
headers, and therefore triggering this bug.]

The second question is the matter of consequences:  If you correct the
(I think) clearly broken behavior, what is the impact on anyone
affected?  Well, in the worst case scenario, where someone actually is
depending on this behavior (which I think is pretty unlikely, given
much of the above), they'll just have to fix probably one or two color
commands in their muttrc, or else some headers may be the wrong color.
Admittedly a minor annoyance--not enough, I think, to offset the
behavior being correct.   In probably the vast majority of cases, it
will require no action, either because the user isn't using this
feature at all, or because they actually intended it to work as it did
in the 1.4 era, and just never noticed or cared enough to bother to
report that it didn't, like me.

Now, for the bonus round:

FWIW (particularly with this fixed) I think hdrdefault is redundant, and
could actually be removed, though that would force some users to
change their muttrc (so I'm not suggesting that, just pointing it
out).  However, assuming it's implemented as I imagine (I still
haven't looked at the code, FWIW) it does reduce the regex comparisons
required by 1, providing a slight optimization.  Although, arguably,
it would have exactly the same effect if the regex evaluation was
optimized according to this python-like pseudo code:

rule_applied = None
foreach rule in rules:
# Optimize the "match all" rule...
# Prolly document that "." is shorthand for "match everything
# by default" and don't try to be too clever about what other
# regexes to optimize...
if rule.regex == ".":
# everything matches "." -- don't bother checking
rule_applied = rule
else:
if rule.regex matches text:
rule_applied = rule

# all rules checked--apply the last match.
if rule_applied:
apply rule_applied

In practice, I doubt this matters enough for anyone to notice the
optimization, but possibly with lots of rules on slow hardware...
Nah, still probably not. :)

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[Kevin J. McCarthy]

On Tue, Jan 11, 2022 at 03:32:09PM -0600, Derek Martin wrote:
OK but do you agree that behavior is wrong? :) It's one header, 
regardless of the wrapping...


I'll have to think more closely about it.  I do agree that the matching 
on the folded line overriding the previous 'color header' match is 
confusing.  I don't believe the fix is hard, either.


However, it's not just about wrong vs. right, but also about precedence 
of the behavior, and I believe this one goes back to 1.5.21.  If I make 
the change, I may then have long-time users reporting a "genuine" 
regression.


But that's not a "no".

I'm winding down the 2.2.0 development cycle now, so I'll put this at 
the top of the list to consider in the next cycle.


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[Derek Martin]

On Tue, Jan 11, 2022 at 11:48:38AM -0800, Kevin J. McCarthy wrote:
> On Tue, Jan 11, 2022 at 12:48:03PM -0600, Derek Martin wrote:
> > On Mon, Jan 10, 2022 at 05:27:32PM -0800, Kevin J. McCarthy wrote:
> > > Can you provide a minimal reproduce of the problem?
> > 
> > I sure can:
> > 
> > set spoolfile = Path/to/coninued/header/message/folder
> > color normal default default
> > color header brightgreen default .
> > color header brightmagenta default ^(subject|from|to|cc|date)
> > 
> > With these, the specified headers will all be magenta.  That is,
> > unless they are continued--then they will be green.
> 
> I can reproduce this with versions 1.10.1 and 1.11.4, and so I don't believe
> this is a regression.

Turns out I have 1.9.4 lying around and I can repro it there as well.

> When the header wraps, the second color line above will match the wrapped
> line, and will then override the third color lines' match of the
> first header line.

OK but do you agree that behavior is wrong? :)  It's one header,
regardless of the wrapping...

> I think instead you probably want:
> 
> color normal default default
> color hdrdefault brightgreen default
> color header brightmagenta default ^(subject|from|to|cc|date)

That does seem to work... I wasn't familiar with that keyword.  Even
after 25 years, I don't know all the keywords.  Just supports my
theory that Mutt has too many, IMO. =8^)

At any rate, given my way has parity with configuring hooks and such,
and is (IMO) the intuitive behavior, I think the two versions of
config ought to work identically.  YMMV.

> > On a separate note, I tried to compile 2.1.5 with the sidebar enabled,
> > and I got this mess (which I made no effort to investigate, but I can
> > later, theoretically, if you like), just FYI:
> 
> I can't reproduce this from a fresh unpacked tarball.
[...]
> Try a make clean; make and see if that fixes the problem?

It did!  I should have tried that outright, but... too many pots on
the stove.


-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[Kevin J. McCarthy]

On Tue, Jan 11, 2022 at 12:48:03PM -0600, Derek Martin wrote:

On Mon, Jan 10, 2022 at 05:27:32PM -0800, Kevin J. McCarthy wrote:

Can you provide a minimal reproduce of the problem?


I sure can:

set spoolfile = Path/to/coninued/header/message/folder
color normal default default
color header brightgreen default .
color header brightmagenta default ^(subject|from|to|cc|date)

With these, the specified headers will all be magenta.  That is,
unless they are continued--then they will be green.


I can reproduce this with versions 1.10.1 and 1.11.4, and so I don't 
believe this is a regression.


When the header wraps, the second color line above will match the 
wrapped line, and will then override the third color lines' match of the

first header line.

I think instead you probably want:

color normal default default
color hdrdefault brightgreen default
color header brightmagenta default ^(subject|from|to|cc|date)


On a separate note, I tried to compile 2.1.5 with the sidebar enabled,
and I got this mess (which I made no effort to investigate, but I can
later, theoretically, if you like), just FYI:


I can't reproduce this from a fresh unpacked tarball.

The first line you should see when you type make is:
./gen_defs ./OPS ./OPS.SIDEBAR ./OPS.PGP ./OPS.SMIME ./OPS.CRYPT  > 
keymap_defs.h
Which should generate the OP_SIDEBAR_* declarations in keymap_defs.h.

Try a make clean; make and see if that fixes the problem?

--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[Derek Martin]

On Mon, Jan 10, 2022 at 04:45:04PM -0800, Dan Fandrich wrote:
> On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote:
> > 1. Does anyone have any idea why ubuntu is shipping such an ancient
> >version of Mutt? ;-)
> 
> 1.13.2 was the most recent release of mutt at the beginning of 2020 when 
> Ubuntu
> 20.04 went into testing

So it was... I imagined that version was considerably older.  A
testament to Kevin's progress. :)


On Mon, Jan 10, 2022 at 05:27:32PM -0800, Kevin J. McCarthy wrote:
> On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote:
> > 2. It appears that this version of Mutt does not properly honor color
> >   commands in headers that are continued in multiple lines.  Is this
> >   a bug that was found and fixed in a future version?
> 
> Derek, I can't recall a recent fix pertaining to that, but perhaps I've
> forgotten.

I went back after I finished what I was working on, and compiled the
latest mutt.  I can confirm the bug is still present.

> Can you provide a minimal reproduce of the problem?

I sure can:

set spoolfile = Path/to/coninued/header/message/folder
color normal default default
color header brightgreen default .
color header brightmagenta default ^(subject|from|to|cc|date)

With these, the specified headers will all be magenta.  That is,
unless they are continued--then they will be green.

Possibly useful to know:  I'm using gnome-terminal, with TERM forced
to xterm (because I don't actually have a use for the 256-color
behavior), and the option to use bright colors for bold (so you can
actually use the top 8 colors) is checked.  Although, I just tried it
with my ancient xterm (actual xterm) config and it behaves the same
way there as well.  Point is, I'm not using a 256-color config.

> You don't have $header_color_partial set, do you?

No.

-=-=-=-

On a separate note, I tried to compile 2.1.5 with the sidebar enabled,
and I got this mess (which I made no effort to investigate, but I can
later, theoretically, if you like), just FYI:

cc -DPKGDATADIR=\"/usr/local/share/mutt\" -DSYSCONFDIR=\"/usr/local/etc\" 
-DBINDIR=\"/usr/local/bin\" -DMUTTLOCALEDIR=\"/usr/local/share/locale\" 
-DHAVE_CONFIG_H=1 -I.  -I. -I.  -Wall -pedantic -Wno-long-long -g -O2 -MT 
curs_main.o -MD -MP -MF .deps/curs_main.Tpo -c -o curs_main.o curs_main.c
curs_main.c: In function ‘mutt_index_menu’:
curs_main.c:1293:12: error: ‘OP_SIDEBAR_OPEN’ undeclared (first use in this 
function)
 1293 |   case OP_SIDEBAR_OPEN:
  |^~~
curs_main.c:1293:12: note: each undeclared identifier is reported only once for 
each function it appears in
curs_main.c:2617:12: error: ‘OP_SIDEBAR_FIRST’ undeclared (first use in this 
function)
 2617 |   case OP_SIDEBAR_FIRST:
  |^~~~
curs_main.c:2618:12: error: ‘OP_SIDEBAR_LAST’ undeclared (first use in this 
function)
 2618 |   case OP_SIDEBAR_LAST:
  |^~~
curs_main.c:2619:12: error: ‘OP_SIDEBAR_NEXT’ undeclared (first use in this 
function); did you mean ‘OP_SEARCH_NEXT’?
 2619 |   case OP_SIDEBAR_NEXT:
  |^~~
  |OP_SEARCH_NEXT
curs_main.c:2620:12: error: ‘OP_SIDEBAR_NEXT_NEW’ undeclared (first use in this 
function); did you mean ‘OP_MAIN_NEXT_NEW’?
 2620 |   case OP_SIDEBAR_NEXT_NEW:
  |^~~
  |OP_MAIN_NEXT_NEW
curs_main.c:2621:12: error: ‘OP_SIDEBAR_PAGE_DOWN’ undeclared (first use in 
this function)
 2621 |   case OP_SIDEBAR_PAGE_DOWN:
  |^~~~
curs_main.c:2622:12: error: ‘OP_SIDEBAR_PAGE_UP’ undeclared (first use in this 
function)
 2622 |   case OP_SIDEBAR_PAGE_UP:
  |^~
curs_main.c:2623:12: error: ‘OP_SIDEBAR_PREV’ undeclared (first use in this 
function)
 2623 |   case OP_SIDEBAR_PREV:
  |^~~
curs_main.c:2624:12: error: ‘OP_SIDEBAR_PREV_NEW’ undeclared (first use in this 
function); did you mean ‘OP_MAIN_PREV_NEW’?
 2624 |   case OP_SIDEBAR_PREV_NEW:
  |^~~
  |OP_MAIN_PREV_NEW
curs_main.c:2628:12: error: ‘OP_SIDEBAR_TOGGLE_VISIBLE’ undeclared (first use 
in this function)
 2628 |   case OP_SIDEBAR_TOGGLE_VISIBLE:
  |^
make[2]: *** [Makefile:908: curs_main.o] Error 1
make[2]: Leaving directory '/home/demartin/Downloads/mutt-2.1.5'
make[1]: *** [Makefile:928: all-recursive] Error 1
make[1]: Leaving directory '/home/demartin/Downloads/mutt-2.1.5'
make: *** [Makefile:614: all] Error 2


My configure line:

./configure  --enable-sidebar --disable-external-dotlock --enable-hcache

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[Kevin J. McCarthy]

On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote:

2. It appears that this version of Mutt does not properly honor color
  commands in headers that are continued in multiple lines.  Is this
  a bug that was found and fixed in a future version? (I can
  obviously download the source and try it but that takes some time I
  don't really have right at the moment, so if someone knows the
  answer, all the better).


Derek, I can't recall a recent fix pertaining to that, but perhaps I've 
forgotten.


Can you provide a minimal reproduce of the problem?  You don't have 
$header_color_partial set, do you?


--
Kevin J. McCarthy
GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA


signature.asc
Description: PGP signature

Re: Mutt on ubuntu 20

[Dan Fandrich]

On Mon, Jan 10, 2022 at 06:27:04PM -0600, Derek Martin wrote:
> 1. Does anyone have any idea why ubuntu is shipping such an ancient
>version of Mutt? ;-)

1.13.2 was the most recent release of mutt at the beginning of 2020 when Ubuntu
20.04 went into testing, and the OS was released only a few months later.
Once testing starts, they're not going to want to upgrade versions unless a
serious problem is found. It's such an ancient version because it's such an
ancient OS :-)

Dan

Mutt on ubuntu 20

[Derek Martin]

I recently was given a laptop by my employer, running Ubuntu 20.  I
have some disincentive (which I may ignore, given sufficient reason)
to run what they provide.  It seems to ship with mutt-1.13.2.  So, now
I have TWO questions...

1. Does anyone have any idea why ubuntu is shipping such an ancient
   version of Mutt? ;-)

2. It appears that this version of Mutt does not properly honor color
   commands in headers that are continued in multiple lines.  Is this
   a bug that was found and fixed in a future version? (I can
   obviously download the source and try it but that takes some time I
   don't really have right at the moment, so if someone knows the
   answer, all the better).

-- 
Derek D. Martinhttp://www.pizzashack.org/   GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address.  Replying to it will result in
undeliverable mail due to spam prevention.  Sorry for the inconvenience.



signature.asc
Description: PGP signature