PATCH: Unbreak `mailcap-mailcap-entry-passes-test'

[Michael Sperber]

I had to apply to attached patch to make mailcap work on XEmacs. I'm
puzzled by this, as I think it should break mailcap for just about
everyone. On the other hand, I don't see how the code (without) the
patch could work as advertised.

So if somebody could review (and maybe apply) it, that - again - would
be much appreciated.

[Katsumi Yamaoka]

Post by Michael Sperber
I had to apply to attached patch to make mailcap work on XEmacs. I'm
puzzled by this, as I think it should break mailcap for just about
everyone. On the other hand, I don't see how the code (without) the
patch could work as advertised.
So if somebody could review (and maybe apply) it, that - again - would
be much appreciated.

This is what I grasped of how mailcap.el does:

What is passed to mailcap-mailcap-entry-passes-test is an entry
of a mailcap file (user's or system's) like this:

image/*; xv %s; test=test -n "$DISPLAY"

This entry is parsed by mailcap-parse-mailcap into:

((viewer . "xv %s") (type . "image/*") (test . "test -n \"$DISPLAY\""))

It is passed to mailcap-mailcap-entry-passes-test as an argument,
and the result is added to mailcap-mime-data. Where the result is

((viewer . "xv %s") (type . "image/*") (test . t))

if $DISPLAY is not empty, otherwise:

((viewer . "xv %s") (type . "image/*") (test))

If your patch is applied, the `test' token will not be updated
whatever $DISPLAY is.

Regards,

[Michael Sperber]

Thanks for the quick action!

Post by Katsumi Yamaoka
What is passed to mailcap-mailcap-entry-passes-test is an entry
image/*; xv %s; test=test -n "$DISPLAY"
((viewer . "xv %s") (type . "image/*") (test . "test -n \"$DISPLAY\""))
It is passed to mailcap-mailcap-entry-passes-test as an argument,
and the result is added to mailcap-mime-data. Where the result is
((viewer . "xv %s") (type . "image/*") (test . t))
((viewer . "xv %s") (type . "image/*") (test))

Right. However, many typical mailcap entries will not have a test
clause.

Post by Katsumi Yamaoka
If your patch is applied, the `test' token will not be updated
whatever $DISPLAY is.

I don't think so:

If there's a test clause present, the same code as before runs -
mutating the cdr as before.

If not, the function simply returns t, as documented. (In that case,
there's nothing to mutate.)

[Katsumi Yamaoka]

Post by Michael Sperber
Right. However, many typical mailcap entries will not have a test
clause.

Yes. Moreover mailcap-mailcap-entry-passes-test seems to
support only `test -n $DISPLAY' and `test -z $DISPLAY'.

Post by Michael Sperber

Post by Katsumi Yamaoka
If your patch is applied, the `test' token will not be updated
whatever $DISPLAY is.

If there's a test clause present, the same code as before runs -
mutating the cdr as before.
If not, the function simply returns t, as documented. (In that case,
there's nothing to mutate.)

I did misread the patched code, sorry.

Post by Michael Sperber
+ (or (not test)
+ (progn
...))

In the case `test' is nil, there is no `test' to be updated.
So, the patch is harmless, but it isn't necessarily worthwhile
except that it makes it a bit fast, I think. In addition,

Post by Michael Sperber
* mailcap.el (mailcap-mailcap-entry-passes-test): Actually return
non-nil if no test clause is present, as documented.

Actually the return value of the function is not used in at least
Gnus Lisp modules.

Regards,

[Michael Sperber]

I appreciate your looking at this again!

Post by Katsumi Yamaoka
In the case `test' is nil, there is no `test' to be updated.
So, the patch is harmless, but it isn't necessarily worthwhile
except that it makes it a bit fast, I think.

You're right. Somehow I convinced myself that my mailcap entries didn't
get added. Sorry for the false alarm!