unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#52038: Completion for user mailcap entries
@ 2021-11-22 13:03 Arash Esbati
  2022-09-24 13:39 ` Lars Ingebrigtsen
  0 siblings, 1 reply; 13+ messages in thread
From: Arash Esbati @ 2021-11-22 13:03 UTC (permalink / raw)
  To: 52038

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2021-11-22 13:03 bug#52038: Completion for user mailcap entries Arash Esbati
@ 2022-09-24 13:39 ` Lars Ingebrigtsen
  2022-10-01  7:21   ` Arash Esbati
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-24 13:39 UTC (permalink / raw)
  To: Arash Esbati; +Cc: 52038

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-09-24 13:39 ` Lars Ingebrigtsen
@ 2022-10-01  7:21   ` Arash Esbati
  2022-10-01 10:12     ` Lars Ingebrigtsen
  0 siblings, 1 reply; 13+ messages in thread
From: Arash Esbati @ 2022-10-01  7:21 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-01  7:21   ` Arash Esbati
@ 2022-10-01 10:12     ` Lars Ingebrigtsen
  2022-10-01 13:21       ` Lars Ingebrigtsen
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 10:12 UTC (permalink / raw)
  To: Arash Esbati; +Cc: 52038

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.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-01 10:12     ` Lars Ingebrigtsen
@ 2022-10-01 13:21       ` Lars Ingebrigtsen
  2022-10-02  8:41         ` Arash Esbati
  0 siblings, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-01 13:21 UTC (permalink / raw)
  To: Arash Esbati; +Cc: 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-01 13:21       ` Lars Ingebrigtsen
@ 2022-10-02  8:41         ` Arash Esbati
  2022-10-02  8:59           ` Andreas Schwab
  0 siblings, 1 reply; 13+ messages in thread
From: Arash Esbati @ 2022-10-02  8:41 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: 52038

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





^ permalink raw reply related	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02  8:41         ` Arash Esbati
@ 2022-10-02  8:59           ` Andreas Schwab
  2022-10-02  9:58             ` Arash Esbati
  0 siblings, 1 reply; 13+ messages in thread
From: Andreas Schwab @ 2022-10-02  8:59 UTC (permalink / raw)
  To: Arash Esbati; +Cc: Lars Ingebrigtsen, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02  8:59           ` Andreas Schwab
@ 2022-10-02  9:58             ` Arash Esbati
  2022-10-02 10:05               ` Andreas Schwab
  0 siblings, 1 reply; 13+ messages in thread
From: Arash Esbati @ 2022-10-02  9:58 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Lars Ingebrigtsen, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02  9:58             ` Arash Esbati
@ 2022-10-02 10:05               ` Andreas Schwab
  2022-10-02 11:21                 ` Arash Esbati
  0 siblings, 1 reply; 13+ messages in thread
From: Andreas Schwab @ 2022-10-02 10:05 UTC (permalink / raw)
  To: Arash Esbati; +Cc: Lars Ingebrigtsen, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02 10:05               ` Andreas Schwab
@ 2022-10-02 11:21                 ` Arash Esbati
  2022-10-02 12:08                   ` Andreas Schwab
  2022-10-02 12:13                   ` Lars Ingebrigtsen
  0 siblings, 2 replies; 13+ messages in thread
From: Arash Esbati @ 2022-10-02 11:21 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Lars Ingebrigtsen, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02 11:21                 ` Arash Esbati
@ 2022-10-02 12:08                   ` Andreas Schwab
  2022-10-02 12:13                   ` Lars Ingebrigtsen
  1 sibling, 0 replies; 13+ messages in thread
From: Andreas Schwab @ 2022-10-02 12:08 UTC (permalink / raw)
  To: Arash Esbati; +Cc: Lars Ingebrigtsen, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02 11:21                 ` Arash Esbati
  2022-10-02 12:08                   ` Andreas Schwab
@ 2022-10-02 12:13                   ` Lars Ingebrigtsen
  2022-10-02 13:02                     ` Arash Esbati
  1 sibling, 1 reply; 13+ messages in thread
From: Lars Ingebrigtsen @ 2022-10-02 12:13 UTC (permalink / raw)
  To: Arash Esbati; +Cc: Andreas Schwab, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

* bug#52038: Completion for user mailcap entries
  2022-10-02 12:13                   ` Lars Ingebrigtsen
@ 2022-10-02 13:02                     ` Arash Esbati
  0 siblings, 0 replies; 13+ messages in thread
From: Arash Esbati @ 2022-10-02 13:02 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Andreas Schwab, 52038

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2022-10-02 13:02 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-22 13:03 bug#52038: Completion for user mailcap entries Arash Esbati
2022-09-24 13:39 ` Lars Ingebrigtsen
2022-10-01  7:21   ` Arash Esbati
2022-10-01 10:12     ` Lars Ingebrigtsen
2022-10-01 13:21       ` Lars Ingebrigtsen
2022-10-02  8:41         ` Arash Esbati
2022-10-02  8:59           ` Andreas Schwab
2022-10-02  9:58             ` Arash Esbati
2022-10-02 10:05               ` Andreas Schwab
2022-10-02 11:21                 ` Arash Esbati
2022-10-02 12:08                   ` Andreas Schwab
2022-10-02 12:13                   ` Lars Ingebrigtsen
2022-10-02 13:02                     ` Arash Esbati

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).