bug#52038: Completion for user mailcap entries

bug#52038: Completion for user mailcap entries

[Arash Esbati]

[-- Attachment #1: Type: text/plain, Size: 518 bytes --]

Hi all,

I added some entries to my ~/.mailcap like this (where the action part
is not relevant for this report):

  application/vnd.ms-excel; foo
  application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; bar
  application/vnd.openxmlformats-officedocument.wordprocessingml.document; baz

In Gnus, I take a mail with an attachment (application/octet-stream) and
hit 'e' to view the MIME part externally.  When asked for 'View as MIME
type', I enter 'application/vnd<TAB>' and get the following completions:

[-- Attachment #2: mime.png --]
[-- Type: image/png, Size: 15852 bytes --]

[-- Attachment #3: Type: text/plain, Size: 190 bytes --]


Note the \ before the dots and I have to insert a backslash before I can
proceed with completion.  Is this the expected behavior?

This is Emacs 29.0.50 (c7699b9702) on Win10.

Best, Arash

bug#52038: Completion for user mailcap entries

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

> I added some entries to my ~/.mailcap like this (where the action part
> is not relevant for this report):
>
>   application/vnd.ms-excel; foo
>   application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; bar
>   application/vnd.openxmlformats-officedocument.wordprocessingml.document; baz
>
> In Gnus, I take a mail with an attachment (application/octet-stream) and
> hit 'e' to view the MIME part externally.  When asked for 'View as MIME
> type', I enter 'application/vnd<TAB>' and get the following completions:
>
>  
>
> Note the \ before the dots and I have to insert a backslash before I can
> proceed with completion.  Is this the expected behavior?

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

The entries you are seeing as vnd\.ms-excel etc come from here:

(defvar mailcap-mime-data
  `(("application"
     ("vnd\\.ms-excel"
      (viewer . "gnumeric %s")

These are regexps, and we want to specify that we're matching the "."
character, and not the [.] character class, so we don't match
"vndxms-excel".  That's probably overly pedantic, but...

But I think this is working as designed, and I'm therefore closing this
bug report.

bug#52038: Completion for user mailcap entries

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The entries you are seeing as vnd\.ms-excel etc come from here:
>
> (defvar mailcap-mime-data
>   `(("application"
>      ("vnd\\.ms-excel"
>       (viewer . "gnumeric %s")
>
> These are regexps, and we want to specify that we're matching the "."
> character, and not the [.] character class, so we don't match
> "vndxms-excel".  That's probably overly pedantic, but...
>
> But I think this is working as designed, and I'm therefore closing this
> bug report.

Thanks for looking at this.  My impression back then was that the entry
"application/vnd.ms-excel" is coming from `mailcap-mime-data' and
"application/vnd\.ms-excel" is generated by the function
`mailcap-parse-mailcap' which is called inside `mailcap-parse-mailcaps'
where the former pushes the entries in ~/.mailcap through
`regexp-quote'.  So I think the bug is that 2 different entries are
generated for the same mime-type.  Or am I missing something?

Best, Arash

bug#52038: Completion for user mailcap entries

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

> Thanks for looking at this.  My impression back then was that the entry
> "application/vnd.ms-excel" is coming from `mailcap-mime-data' and
> "application/vnd\.ms-excel" is generated by the function
> `mailcap-parse-mailcap' which is called inside `mailcap-parse-mailcaps'
> where the former pushes the entries in ~/.mailcap through
> `regexp-quote'.  So I think the bug is that 2 different entries are
> generated for the same mime-type.  Or am I missing something?

Hm, yes -- I had this backwards.  Reopening.

bug#52038: Completion for user mailcap entries

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

>> Thanks for looking at this.  My impression back then was that the entry
>> "application/vnd.ms-excel" is coming from `mailcap-mime-data' and
>> "application/vnd\.ms-excel" is generated by the function
>> `mailcap-parse-mailcap' which is called inside `mailcap-parse-mailcaps'
>> where the former pushes the entries in ~/.mailcap through
>> `regexp-quote'.  So I think the bug is that 2 different entries are
>> generated for the same mime-type.  Or am I missing something?
>
> Hm, yes -- I had this backwards.  Reopening.

I've now fixed this in Emacs 29 -- there were several instances of
confusion between regexp-quoted minor parts and not, but I think I've
got them all.  (If you see more, please say so.)

bug#52038: Completion for user mailcap entries

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I've now fixed this in Emacs 29 -- there were several instances of
> confusion between regexp-quoted minor parts and not, but I think I've
> got them all.  (If you see more, please say so.)

Thanks.  I also had a look and I think you have them all.  While we're
at it, I think the docstring of `mailcap-mime-data' could also be
touched:

--8<---------------cut here---------------start------------->8---
diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
index aa0c172655..a0355f876b 100644
--- a/lisp/net/mailcap.el
+++ b/lisp/net/mailcap.el
@@ -303,9 +303,9 @@ mailcap-mime-data
 Which looks like:
 -----------------
  ((\"application\"
-   (\"postscript\" . <info>))
+   (\"postscript\" <info>))
   (\"text\"
-   (\"plain\" . <info>)))
+   (\"plain\" <info>)))

 Where <info> is another assoc list of the various information
 related to the mailcap RFC 1524.  This is keyed on the lowercase
--8<---------------cut here---------------end--------------->8---

The way I understand it the 2nd assoc list isn't a dotted pair where
<info> contains dotted pairs.

A description for FLAG is also missing, but I'm not familiar enough with
the code to make a suggestion.

Best, Arash

bug#52038: Completion for user mailcap entries

[Andreas Schwab]

On Okt 02 2022, Arash Esbati wrote:

> diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
> index aa0c172655..a0355f876b 100644
> --- a/lisp/net/mailcap.el
> +++ b/lisp/net/mailcap.el
> @@ -303,9 +303,9 @@ mailcap-mime-data
>  Which looks like:
>  -----------------
>   ((\"application\"
> -   (\"postscript\" . <info>))
> +   (\"postscript\" <info>))
>    (\"text\"
> -   (\"plain\" . <info>)))
> +   (\"plain\" <info>)))
>
>  Where <info> is another assoc list of the various information
>  related to the mailcap RFC 1524.  This is keyed on the lowercase
>
> The way I understand it the 2nd assoc list isn't a dotted pair where
> <info> contains dotted pairs.

This is wrong.  <info> is a list that is the cdr of the containing list.
In the definition of mailcap-mime-data the <info> list is spliced into
its parent, since you can always write '(a . (b c)) as '(a b c).

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#52038: Completion for user mailcap entries

[Arash Esbati]

Andreas Schwab <schwab@linux-m68k.org> writes:

> On Okt 02 2022, Arash Esbati wrote:
>
>> diff --git a/lisp/net/mailcap.el b/lisp/net/mailcap.el
>> index aa0c172655..a0355f876b 100644
>> --- a/lisp/net/mailcap.el
>> +++ b/lisp/net/mailcap.el
>> @@ -303,9 +303,9 @@ mailcap-mime-data
>>  Which looks like:
>>  -----------------
>>   ((\"application\"
>> -   (\"postscript\" . <info>))
>> +   (\"postscript\" <info>))
>>    (\"text\"
>> -   (\"plain\" . <info>)))
>> +   (\"plain\" <info>)))
>>
>>  Where <info> is another assoc list of the various information
>>  related to the mailcap RFC 1524.  This is keyed on the lowercase
>>
>> The way I understand it the 2nd assoc list isn't a dotted pair where
>> <info> contains dotted pairs.
>
> This is wrong.  <info> is a list that is the cdr of the containing list.
> In the definition of mailcap-mime-data the <info> list is spliced into
> its parent, since you can always write '(a . (b c)) as '(a b c).

Thanks for your response.  Unless I'm totally confused, I think there is
mismatch between the implementation of `mailcap-mime-data' and its
docstring.  This is an excerpt of the long defvar:

--8<---------------cut here---------------start------------->8---
(defvar mailcap-mime-data
  `(("application"
     ("postscript"
      (viewer . "gv -safer %s")
      (type . "application/postscript")
      (test   . window-system)
      ("print" . ,(concat mailcap-print-command " %s"))
      ("needsx11"))
     ("pgp-keys"
      (viewer . "gpg --import --interactive --verbose")
      (type   . "application/pgp-keys")
      ("needsterminal")))
    ("text"
     ("plain"
      (viewer  . view-mode)
      (type    . "text/plain"))
     ("plain"
      (viewer  . fundamental-mode)
      (type    . "text/plain"))
     ("enriched"
      (viewer . enriched-decode)
      (type   . "text/enriched"))
     ("dns"
      (viewer . dns-mode)
      (type   . "text/dns")))
    ("archive"
     ("tar"
      (viewer . tar-mode)
      (type . "archive/tar"))))
  "The mailcap structure is an assoc list of assoc lists.
1st assoc list is keyed on the major content-type
2nd assoc list is keyed on the minor content-type (which can be a regexp)

Which looks like:
-----------------
 ((\"application\"
   (\"postscript\" . <info>))
  (\"text\"
   (\"plain\" . <info>)))

Where <info> is another assoc list of the various information
related to the mailcap RFC 1524.  This is keyed on the lowercase
attribute name (viewer, test, etc).  This looks like:
 ((viewer . VIEWERINFO)
  (test   . TESTINFO)
  (xxxx   . \"STRING\")
  FLAG)

[...]")
--8<---------------cut here---------------end--------------->8---

So the outcome is correct, it is just confusing when you read the
docstring and see that is done differently.

Best, Arash

bug#52038: Completion for user mailcap entries

[Andreas Schwab]

On Okt 02 2022, Arash Esbati wrote:

> Thanks for your response.  Unless I'm totally confused, I think there is
> mismatch between the implementation of `mailcap-mime-data' and its
> docstring.

There is no mismatch. '(a . (b c)) and '(a b c) are the same lists.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#52038: Completion for user mailcap entries

[Arash Esbati]

Andreas Schwab <schwab@linux-m68k.org> writes:

> There is no mismatch. '(a . (b c)) and '(a b c) are the same lists.

Agreed.  My point was the sentence at the end of my other message:

  ..., it is just confusing when you read the docstring and see that is
  done differently.

But maybe that's only me :)

Best, Arash

bug#52038: Completion for user mailcap entries

[Andreas Schwab]

On Okt 02 2022, Arash Esbati wrote:

>   ..., it is just confusing when you read the docstring and see that is
>   done differently.

But the docstring is accurate, and your change is wrong.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#52038: Completion for user mailcap entries

[Lars Ingebrigtsen]

Arash Esbati <arash@gnu.org> writes:

> Agreed.  My point was the sentence at the end of my other message:
>
>   ..., it is just confusing when you read the docstring and see that is
>   done differently.
>
> But maybe that's only me :)

It's not optimal, but it makes it easier to talk about <info> as an
entity, instead of "the bits that end up at the end of the list"...

bug#52038: Completion for user mailcap entries

[Arash Esbati]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Arash Esbati <arash@gnu.org> writes:
>
>> Agreed.  My point was the sentence at the end of my other message:
>>
>>   ..., it is just confusing when you read the docstring and see that is
>>   done differently.
>>
>> But maybe that's only me :)
>
> It's not optimal, but it makes it easier to talk about <info> as an
> entity, instead of "the bits that end up at the end of the list"...

You're probably right, and my proposal wasn't correct anyway.  So let's
move on to other things we have on our plates.

Best, Arash