Re: Compatibility with mailx aliases

[Walter Alejandro Iglesias]

On Sun, Jun 23, 2024 at 03:43:50PM +0800, Kevin J. McCarthy wrote:
> On Sun, Jun 23, 2024 at 08:44:44AM +0200, Rene Kita wrote:
> >On Sun, Jun 23, 2024 at 01:53:21PM +0800, Kevin J. McCarthy wrote:
> >> On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote:
> >> > MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
> >> > the header:
> >> > #define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */
> >> >
> >> > AFAIU, this should not have undesired side effects. But I have never
> >> > read this part of the code before, I might be wrong.
> >>
> >> This will break aliases such as
> >>  alias kmtest "McCarthy, Kevin" 
> >>
> >> The double quotes are stripped out of the returned token without
> >> MUTT_TOKEN_QUOTE.
> >
> >Yes, that's the whole idea, isn't it? As said somewhere up thread,
> >you'll need to use single quotes in such a case.
> >
> > alias kmtest '"McCarthy, Kevin" '
> >
> >This is the same behavior as mailx shows and breaks current mutt
> >behavior. That's why it should be an option.
> 
> Okay.  I saw that but thought you had later concluded there were no side 
> effects.  My mistake :).

If the code was designed to work that way (too clever may be?), it's not
worth complicating it even more with this option.  I will continue to
use two aliases files. :-)

Thank you all!


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

-- 
Walter

Re: Compatibility with mailx aliases

[Rene Kita]

On Sun, Jun 23, 2024 at 03:43:50PM +0800, Kevin J. McCarthy wrote:
> On Sun, Jun 23, 2024 at 08:44:44AM +0200, Rene Kita wrote:
> > On Sun, Jun 23, 2024 at 01:53:21PM +0800, Kevin J. McCarthy wrote:
> > > On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote:
> > > > MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
> > > > the header:
> > > > #define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */
> > > >
> > > > AFAIU, this should not have undesired side effects. But I have never
> > > > read this part of the code before, I might be wrong.
> > > 
> > > This will break aliases such as
> > >  alias kmtest "McCarthy, Kevin" 
> > > 
> > > The double quotes are stripped out of the returned token without
> > > MUTT_TOKEN_QUOTE.
> > 
> > Yes, that's the whole idea, isn't it? As said somewhere up thread,
> > you'll need to use single quotes in such a case.
> > 
> > alias kmtest '"McCarthy, Kevin" '
> > 
> > This is the same behavior as mailx shows and breaks current mutt
> > behavior. That's why it should be an option.
> 
> Okay.  I saw that but thought you had later concluded there were no side
> effects.  My mistake :).

I should have said: no _further_ side effects, like special treatment of
other characters.

Re: Compatibility with mailx aliases

[Kevin J. McCarthy]

On Sun, Jun 23, 2024 at 08:44:44AM +0200, Rene Kita wrote:

On Sun, Jun 23, 2024 at 01:53:21PM +0800, Kevin J. McCarthy wrote:

On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote:
> MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
> the header:
> #define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */
>
> AFAIU, this should not have undesired side effects. But I have never
> read this part of the code before, I might be wrong.

This will break aliases such as
 alias kmtest "McCarthy, Kevin" 

The double quotes are stripped out of the returned token without
MUTT_TOKEN_QUOTE.


Yes, that's the whole idea, isn't it? As said somewhere up thread,
you'll need to use single quotes in such a case.

alias kmtest '"McCarthy, Kevin" '

This is the same behavior as mailx shows and breaks current mutt
behavior. That's why it should be an option.


Okay.  I saw that but thought you had later concluded there were no side 
effects.  My mistake :).


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


signature.asc
Description: PGP signature

Re: Compatibility with mailx aliases

[Rene Kita]

On Sun, Jun 23, 2024 at 01:53:21PM +0800, Kevin J. McCarthy wrote:
> On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote:
> > MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
> > the header:
> > #define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */
> > 
> > AFAIU, this should not have undesired side effects. But I have never
> > read this part of the code before, I might be wrong.
> 
> This will break aliases such as
>  alias kmtest "McCarthy, Kevin" 
> 
> The double quotes are stripped out of the returned token without
> MUTT_TOKEN_QUOTE.

Yes, that's the whole idea, isn't it? As said somewhere up thread,
you'll need to use single quotes in such a case.

 alias kmtest '"McCarthy, Kevin" '

This is the same behavior as mailx shows and breaks current mutt
behavior. That's why it should be an option.

Something like (untested):
---
diff --git a/init.c b/init.c
index c84815c2..a398ec90 100644
--- a/init.c
+++ b/init.c
@@ -1661,7 +1661,7 @@ static int parse_alias (BUFFER *buf, BUFFER *s, union 
pointer_long_t udata, BUFF
   mutt_set_current_menu_redraw_full ();
   }
 
-  mutt_extract_token (buf, s, MUTT_TOKEN_QUOTE | MUTT_TOKEN_SPACE | 
MUTT_TOKEN_SEMICOLON);
+  mutt_extract_token (buf, s, (MUTT_TOKEN_QUOTE & !MailXAliasComp) | 
MUTT_TOKEN_SPACE | MUTT_TOKEN_SEMICOLON);
   dprint (3, (debugfile, "parse_alias: Second token is '%s'.\n",
  buf->data));
 

Re: Compatibility with mailx aliases

[Walter Alejandro Iglesias]

On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote:
> On Sat, Jun 22, 2024 at 11:23:40AM +0200, Walter Alejandro Iglesias wrote:
> > I was lazy, I didn't take a look at the code before sending this
> > suggestion.  Now I tested your patch and it works, but I don't
> > understand what your diff does exactly, does it tells mutt to just
> > ignore the quotes?  Because if this is the case it shouldn't breake the
> > old behavior.
> 
> MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
> the header:
> #define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */

I saw that definition yesterday.  So, it's the opposite to what I
intuitively thought.  Confusing.

> 
> AFAIU, this should not have undesired side effects. But I have never
> read this part of the code before, I might be wrong.
> 

Let's take this alias:

 alias walter '"Walter A. Iglesias" '

Without your patch:

 $ /usr/local/bin/mutt -d3 walter

 The header results:
   To: "' Walter A. Iglesias" , '@localhost.localdomain

 The debug level 3 message:
   parse_alias: Second token is ''"Walter A. Iglesias" ''.


With your patch:

 $ ~/bin/mutt -d3 walter

 The header results:
   To: "Walter A. Iglesias" 

 The debug level 3 message:
   parse_alias: Second token is '"Walter A. Iglesias" '.



Now this second example:

 alias walter "Walter Alejandro Iglesias "

Without your patch:

 $ /usr/local/bin/mutt -d3 walter

 The header results:
   To: walter@localhost.localdomain

 The debug level 3 message:
   parse_alias: Second token is '"Walter Alejandro Iglesias 
"'

With your patch:

 $ ~/bin/mutt -d3 walter

 The header results:
   To: Walter Alejandro Iglesias 

 The debug level 3 message:
   parse_alias: Second token is 'Walter Alejandro Iglesias 
'.




-- 
Walter

Re: Compatibility with mailx aliases

[Kevin J. McCarthy]

On Sun, Jun 23, 2024 at 06:29:45AM +0200, Rene Kita wrote:

MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
the header:
#define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */

AFAIU, this should not have undesired side effects. But I have never
read this part of the code before, I might be wrong.


This will break aliases such as
 alias kmtest "McCarthy, Kevin" 

The double quotes are stripped out of the returned token without 
MUTT_TOKEN_QUOTE.


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


signature.asc
Description: PGP signature

Re: Compatibility with mailx aliases

[Rene Kita]

On Sat, Jun 22, 2024 at 11:23:40AM +0200, Walter Alejandro Iglesias wrote:
> Hi Rene,

Hi Walter!

> On Sat, Jun 22, 2024 at 10:36:52AM +0200, Rene Kita wrote:
> > On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> > > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> > > aliases:
> > > 
> > >   alias john  "John Dou "
> > > 
> > > With full addresses, since they contain spaces, you need to enclose them
> > > in quotes.  Any unix user would tend to add those quotes since there are
> > > three fields there, not five.
> > > 
> > > If you add those quotes in a mutt aliases file, mutt doesn't recognize
> > > that alias.  This is an inconsistency.  And an inconvenience, since it
> > > forces you to use two aliases files, one for mail(1) and another one for
> > > mutt.
> > > 
> > > It would be logical to add mutt compatibility for this case and even
> > > more convenient if mutt added those quotes when generating aliases.
> > 
> > Sounds reasonable. Allowing to read quoted aliases seems pretty straight
> > forward, see the patch below. Of course we might break some ones
> > existing aliases, so this might be better enabled via a new option.
> > 
> > If it is a new option, should this also determine how we write it? Then
> > the option should probably make one style mandatory. I'm not sure if
> > this is worth the trouble.
> 
> I was lazy, I didn't take a look at the code before sending this
> suggestion.  Now I tested your patch and it works, but I don't
> understand what your diff does exactly, does it tells mutt to just
> ignore the quotes?  Because if this is the case it shouldn't breake the
> old behavior.

MUTT_TOKEN_QUOTE tells mutt to tread quotes as parts of the string, from
the header:
#define MUTT_TOKEN_QUOTE  (1<<3)  /* don't interpret quotes */

AFAIU, this should not have undesired side effects. But I have never
read this part of the code before, I might be wrong.

> > 
> > ---
> > diff --git a/init.c b/init.c
> > index c84815c2..a398ec90 100644
> > --- a/init.c
> > +++ b/init.c
> > @@ -1661,7 +1661,7 @@ static int parse_alias (BUFFER *buf, BUFFER *s, union 
> > pointer_long_t udata, BUFF
> >mutt_set_current_menu_redraw_full ();
> >}
> >  
> > -  mutt_extract_token (buf, s, MUTT_TOKEN_QUOTE | MUTT_TOKEN_SPACE | 
> > MUTT_TOKEN_SEMICOLON);
> > +  mutt_extract_token (buf, s, MUTT_TOKEN_SPACE | MUTT_TOKEN_SEMICOLON);
> >dprint (3, (debugfile, "parse_alias: Second token is '%s'.\n",
> >   buf->data));
> >  
> > 
> 

Re: Compatibility with mailx aliases

[Walter Alejandro Iglesias]

On Sat, Jun 22, 2024 at 11:36:47AM +0200, Walter Alejandro Iglesias wrote:
> > > A lot of existing software requires quoting the name when it contains
> > > '.'.  What does BSD or GNU mailutils with those?  Does it use single
> > > quotes or what?  Such as
> > > 
> > >   '"John R. Doe" '
> > 
> > I now tried this syntax in OpenBSD mail and it works.
> > It needs the single quotes, without them it fails.
> 
> And Now I see that the single quotes confuses mutt. :-)

To be clear.  What I said here is about mutt without Rene's patch.  With
Rene's patch the syntax above (pointed by Alejandro) works.  So what
Rene did solves also this case.


-- 
Walter

Re: Compatibility with mailx aliases

[Walter Alejandro Iglesias]

On Sat, Jun 22, 2024 at 11:32:06AM +0200, Walter Alejandro Iglesias wrote:
> Hi Alejandro,
> 
> On Sat, Jun 22, 2024 at 11:02:28AM +0200, Alejandro Colomar wrote:
> > Hi Walter,
> > 
> > On Sat, Jun 22, 2024 at 10:36:52AM GMT, Rene Kita wrote:
> > > On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> > > > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> > > > aliases:
> > > > 
> > > >   alias john"John Dou "
> > 
> > How about addresses that themselves contain quotes, such as
> > "John R. Doe" ?
> > 
> > A lot of existing software requires quoting the name when it contains
> > '.'.  What does BSD or GNU mailutils with those?  Does it use single
> > quotes or what?  Such as
> > 
> > '"John R. Doe" '
> 
> I now tried this syntax in OpenBSD mail and it works.
> It needs the single quotes, without them it fails.

And Now I see that the single quotes confuses mutt. :-)


> 
> 
> > 
> > ?
> > 
> > Have a lovely day!
> > Alex
> > 
> 
> 
> -- 
> Walter

-- 
Walter

Re: Compatibility with mailx aliases

[Walter Alejandro Iglesias]

Hi Alejandro,

On Sat, Jun 22, 2024 at 11:02:28AM +0200, Alejandro Colomar wrote:
> Hi Walter,
> 
> On Sat, Jun 22, 2024 at 10:36:52AM GMT, Rene Kita wrote:
> > On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> > > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> > > aliases:
> > > 
> > >   alias john  "John Dou "
> 
> How about addresses that themselves contain quotes, such as
> "John R. Doe" ?
> 
> A lot of existing software requires quoting the name when it contains
> '.'.  What does BSD or GNU mailutils with those?  Does it use single
> quotes or what?  Such as
> 
>   '"John R. Doe" '

I now tried this syntax in OpenBSD mail and it works.
It needs the single quotes, without them it fails.


> 
> ?
> 
> Have a lovely day!
> Alex
> 


-- 
Walter

Re: Compatibility with mailx aliases

[Walter Alejandro Iglesias]

Hi Rene,

On Sat, Jun 22, 2024 at 10:36:52AM +0200, Rene Kita wrote:
> On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> > aliases:
> > 
> >   alias john"John Dou "
> > 
> > With full addresses, since they contain spaces, you need to enclose them
> > in quotes.  Any unix user would tend to add those quotes since there are
> > three fields there, not five.
> > 
> > If you add those quotes in a mutt aliases file, mutt doesn't recognize
> > that alias.  This is an inconsistency.  And an inconvenience, since it
> > forces you to use two aliases files, one for mail(1) and another one for
> > mutt.
> > 
> > It would be logical to add mutt compatibility for this case and even
> > more convenient if mutt added those quotes when generating aliases.
> 
> Sounds reasonable. Allowing to read quoted aliases seems pretty straight
> forward, see the patch below. Of course we might break some ones
> existing aliases, so this might be better enabled via a new option.
> 
> If it is a new option, should this also determine how we write it? Then
> the option should probably make one style mandatory. I'm not sure if
> this is worth the trouble.

I was lazy, I didn't take a look at the code before sending this
suggestion.  Now I tested your patch and it works, but I don't
understand what your diff does exactly, does it tells mutt to just
ignore the quotes?  Because if this is the case it shouldn't breake the
old behavior.


> 
> ---
> diff --git a/init.c b/init.c
> index c84815c2..a398ec90 100644
> --- a/init.c
> +++ b/init.c
> @@ -1661,7 +1661,7 @@ static int parse_alias (BUFFER *buf, BUFFER *s, union 
> pointer_long_t udata, BUFF
>mutt_set_current_menu_redraw_full ();
>}
>  
> -  mutt_extract_token (buf, s, MUTT_TOKEN_QUOTE | MUTT_TOKEN_SPACE | 
> MUTT_TOKEN_SEMICOLON);
> +  mutt_extract_token (buf, s, MUTT_TOKEN_SPACE | MUTT_TOKEN_SEMICOLON);
>dprint (3, (debugfile, "parse_alias: Second token is '%s'.\n",
> buf->data));
>  
> 

-- 
Walter

Re: Compatibility with mailx aliases

[Alejandro Colomar]

Hi Walter,

On Sat, Jun 22, 2024 at 10:36:52AM GMT, Rene Kita wrote:
> On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> > Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> > aliases:
> > 
> >   alias john"John Dou "

How about addresses that themselves contain quotes, such as
"John R. Doe" ?

A lot of existing software requires quoting the name when it contains
'.'.  What does BSD or GNU mailutils with those?  Does it use single
quotes or what?  Such as

'"John R. Doe" '

?

Have a lovely day!
Alex

> > 
> > With full addresses, since they contain spaces, you need to enclose them
> > in quotes.  Any unix user would tend to add those quotes since there are
> > three fields there, not five.
> > 
> > If you add those quotes in a mutt aliases file, mutt doesn't recognize
> > that alias.  This is an inconsistency.  And an inconvenience, since it
> > forces you to use two aliases files, one for mail(1) and another one for
> > mutt.
> > 
> > It would be logical to add mutt compatibility for this case and even
> > more convenient if mutt added those quotes when generating aliases.
> 
> Sounds reasonable. Allowing to read quoted aliases seems pretty straight
> forward, see the patch below. Of course we might break some ones
> existing aliases, so this might be better enabled via a new option.
> 
> If it is a new option, should this also determine how we write it? Then
> the option should probably make one style mandatory. I'm not sure if
> this is worth the trouble.
> 
> ---
> diff --git a/init.c b/init.c
> index c84815c2..a398ec90 100644
> --- a/init.c
> +++ b/init.c
> @@ -1661,7 +1661,7 @@ static int parse_alias (BUFFER *buf, BUFFER *s, union 
> pointer_long_t udata, BUFF
>mutt_set_current_menu_redraw_full ();
>}
>  
> -  mutt_extract_token (buf, s, MUTT_TOKEN_QUOTE | MUTT_TOKEN_SPACE | 
> MUTT_TOKEN_SEMICOLON);
> +  mutt_extract_token (buf, s, MUTT_TOKEN_SPACE | MUTT_TOKEN_SEMICOLON);
>dprint (3, (debugfile, "parse_alias: Second token is '%s'.\n",
> buf->data));
>  

-- 



signature.asc
Description: PGP signature

Re: Compatibility with mailx aliases

[Rene Kita]

On Sat, Jun 22, 2024 at 07:13:16AM +0200, Walter Alejandro Iglesias wrote:
> Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
> aliases:
> 
>   alias john  "John Dou "
> 
> With full addresses, since they contain spaces, you need to enclose them
> in quotes.  Any unix user would tend to add those quotes since there are
> three fields there, not five.
> 
> If you add those quotes in a mutt aliases file, mutt doesn't recognize
> that alias.  This is an inconsistency.  And an inconvenience, since it
> forces you to use two aliases files, one for mail(1) and another one for
> mutt.
> 
> It would be logical to add mutt compatibility for this case and even
> more convenient if mutt added those quotes when generating aliases.

Sounds reasonable. Allowing to read quoted aliases seems pretty straight
forward, see the patch below. Of course we might break some ones
existing aliases, so this might be better enabled via a new option.

If it is a new option, should this also determine how we write it? Then
the option should probably make one style mandatory. I'm not sure if
this is worth the trouble.

---
diff --git a/init.c b/init.c
index c84815c2..a398ec90 100644
--- a/init.c
+++ b/init.c
@@ -1661,7 +1661,7 @@ static int parse_alias (BUFFER *buf, BUFFER *s, union 
pointer_long_t udata, BUFF
   mutt_set_current_menu_redraw_full ();
   }
 
-  mutt_extract_token (buf, s, MUTT_TOKEN_QUOTE | MUTT_TOKEN_SPACE | 
MUTT_TOKEN_SEMICOLON);
+  mutt_extract_token (buf, s, MUTT_TOKEN_SPACE | MUTT_TOKEN_SEMICOLON);
   dprint (3, (debugfile, "parse_alias: Second token is '%s'.\n",
  buf->data));
 

Compatibility with mailx aliases

[Walter Alejandro Iglesias]

Traditional mailx (bsd versions and GNU mailutils) needs this syntax for
aliases:

  alias john"John Dou "

With full addresses, since they contain spaces, you need to enclose them
in quotes.  Any unix user would tend to add those quotes since there are
three fields there, not five.

If you add those quotes in a mutt aliases file, mutt doesn't recognize
that alias.  This is an inconsistency.  And an inconvenience, since it
forces you to use two aliases files, one for mail(1) and another one for
mutt.

It would be logical to add mutt compatibility for this case and even
more convenient if mutt added those quotes when generating aliases.


-- 
Walter