bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Teemu Likonen]

This is a wish list issue.

Emacs has mailcap-mime-data variable which is used to decide how various
contents are displayed. The variable is (or seems to be) bootstrapped
from operating system's mailcap configuration but Emacs overrides some
parts of it with (viewer . doc-view-mode) or (viewer . pdf-view-mode).

Not all users want to use doc-view-mode for displaying mime contents. I
wish there was an easy way to not use doc-view-mode or to move its
priority to the bottom of the viewer list. Currently I use this hack to
get completely rid of doc-view-mode:


(with-eval-after-load 'mailcap
  (require 'cl-lib)
  (setq mailcap-mime-data
        (mapcar (lambda (major)
                  (cons (car major)
                        (cl-remove-if
                         (lambda (minor)
                           (cl-some
                            (lambda (x)
                              (and (eq 'viewer (car x))
                                   (cl-member (cdr x) '(doc-view-mode
                                                        pdf-view-mode))))
                            (cdr minor)))
                         (cdr major))))
                mailcap-mime-data)))


In GNU Emacs 25.0.92.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.14.5)
 of 2016-03-29 built on mithlond
Repository revision: 06495c96ae0f5a0fa1d56f47750624138f80cb94
Windowing system distributor 'The X.Org Foundation', version 11.0.11604000
System Description:	Debian GNU/Linux 8.3 (jessie)

Configured using:
 'configure --prefix=/home/dtw/local --with-x-toolkit=gtk3
 --with-xwidgets --with-wide-int'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XWIDGETS

Important settings:
  value of $LC_MESSAGES: C
  value of $LANG: fi_FI.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  diff-auto-refine-mode: t
  gnus-topic-mode: t
  gnus-undo-mode: t
  ido-everywhere: t
  global-undo-tree-mode: t
  show-paren-mode: t
  winner-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t


Load-path shadows:
~/.emacs.d/omat/elisp/loaddefs hides /home/dtw/local/share/emacs/25.0.92/lisp/loaddefs

Features:
(shadow nnir emacsbug sendmail ielm vc vc-dispatcher paredit misearch
multi-isearch dired-aux bookmark qp flow-fill mm-archive vc-git
diff-mode sort gnus-cite mail-extr gnus-async gnus-bcklg gnus-ml
disp-table gnus-topic nndraft nnmh imap utf-7 epa-file epa
network-stream nsm auth-source starttls nnml nnmbox nnnil gnus-agent
gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu
mml2015 mm-view mml-smime smime dig mailcap nntp gnus-cache
gnus-bogofilter gnus-sum gnus-group gnus-undo gnus-start gnus-cloud
nnimap nnmail mail-source tls gnutls utf7 netrc nnoo parse-time
gnus-spec gnus-int gnus-range message dired format-spec rfc822 mml
mml-sec password-cache epg mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems nnheader gnus-util mail-utils mm-util help-fns
mail-prsvr wid-edit ido seq undo-tree diff paren winner rx slime-fancy
slime-trace-dialog slime-fontifying-fu slime-package-fu slime-references
slime-compiler-notes-tree slime-scratch slime-presentations advice
bridge slime-mdot-fu slime-enclosing-context slime-fuzzy
slime-fancy-trace slime-fancy-inspector slime-c-p-c
slime-editing-commands slime-autodoc slime-repl elp slime-parse slime
derived gud apropos compile etags xref cl-seq project eieio byte-opt
bytecomp byte-compile cl-extra help-mode cconv eieio-core arc-mode
archive-mode noutline outline easy-mmode pp comint ansi-color ring
hyperspec cl-macs thingatpt browse-url cl gv slime-autoloads edmacro
kmacro cl-loaddefs pcase cl-lib finder-inf tex-site info package
easymenu epg-config server time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
dbusbind inotify dynamic-setting system-font-setting font-render-setting
xwidget-internal move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 365872 33679)
 (symbols 48 42316 0)
 (miscs 40 409 620)
 (strings 32 86104 6555)
 (string-bytes 1 2641019)
 (vectors 16 41398)
 (vector-slots 8 1502103 214153)
 (floats 8 544 688)
 (intervals 56 837 207)
 (buffers 976 52)
 (heap 1024 91844 26157))
<#secure method=pgpmime mode=sign>

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Tassilo Horn]

Teemu Likonen <tlikonen@iki.fi> writes:

Hi Teemu,

> Emacs has mailcap-mime-data variable which is used to decide how
> various contents are displayed. The variable is (or seems to be)
> bootstrapped from operating system's mailcap configuration but Emacs
> overrides some parts of it with (viewer . doc-view-mode) or (viewer
> . pdf-view-mode).

`pdf-view-mode' and `doc-view-mode' are standard entries in
`mailcap-mime-data', and entries from mailcap files are prepended to the
list.

> Not all users want to use doc-view-mode for displaying mime contents. I
> wish there was an easy way to not use doc-view-mode or to move its
> priority to the bottom of the viewer list.

Hm, for me, evince (from my ~/.mailcap) is before `pdf-view-mode' which
is in turn before `doc-view-mode' in mailcap-mime-data' but still
clicking on a PDF attachment in Gnus opens the file with PDF Tools
(`pdf-view-mode', which I like very much).  So it seems its (at least
not only) the order in `mailcap-mime-data' which defines which tool is
used.

Ok, `mailcap-mime-info' computes the viewer to be used.  It first
selects all whose test passes (which would include doc-view, pdf-view,
"evince", "okular" and what not), and then sorts them according to
`mailcap-viewer-lessp' returning the first viewer after sorting.

`mailcap-viewer-lessp' prefers viewers whose declared type contains no
wildcard, and it prefers Emacs viewers over external apps.

So, yes, if you don't like PDF Tools or DocView, it's pretty hard to get
rid of them.

(1) We could add a function `mailcap-remove-viewer' which essentially
    does what you do already.

(2) Or maybe we could add a customizable list `mailcap-user-mime-data'
    (better name welcome) which would override `mailcap-mime-data',
    i.e., if a viewer is specified there, then `mailcap-mime-data' with
    the heuristics around it won't even be consulted.

I guess the second approach is better as it lets users specify
preferences instead of disabling alternatives until the heuristics
select the preferred viewer.

Any better suggestions?  If not, I can do that.  (In case I'd implement
that, should that go only into master or emacs-25?)

Bye,
Tassilo

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Eli Zaretskii]

> From: Tassilo Horn <tsdh@gnu.org>
> Date: Fri, 08 Apr 2016 22:46:49 +0200
> Cc: 23184@debbugs.gnu.org
> 
> (In case I'd implement that, should that go only into master or
> emacs-25?)

It should go to master.  Thanks.

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Tassilo Horn]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Tassilo Horn <tsdh@gnu.org>
>> Date: Fri, 08 Apr 2016 22:46:49 +0200
>> Cc: 23184@debbugs.gnu.org
>> 
>> (In case I'd implement that, should that go only into master or
>> emacs-25?)
>
> It should go to master.  Thanks.

Ok.  Does that approach look sensible?

--8<---------------cut here---------------start------------->8---
1 file changed, 102 insertions(+), 29 deletions(-)
lisp/net/mailcap.el | 131 ++++++++++++++++++++++++++++++++++++++++------------

modified   lisp/net/mailcap.el
@@ -58,6 +58,59 @@ mailcap-print-command
 	     " ")
   "Shell command (including switches) used to print PostScript files.")
 
+(defun mailcap--get-user-mime-data (sym)
+  (let ((val (default-value sym))
+	res)
+    (dolist (entry val)
+      (setq res (cons (list (cdr (assq 'viewer entry))
+			    (cdr (assq 'type entry))
+			    (cdr (assq 'test entry)))
+		      res)))
+    (nreverse res)))
+
+(defun mailcap--set-user-mime-data (sym val)
+  (let (res)
+    (dolist (entry val)
+      (setq res (cons `((viewer . ,(car entry))
+			(type . ,(cadr entry))
+			,@(when (caddr entry)
+			    `((test . ,(caddr entry)))))
+		      res)))
+    (set-default sym (nreverse res))))
+
+(defcustom mailcap-user-mime-data nil
+  "A list of viewers preferred for different MIME types.
+The elements of the list are alists of the following structure
+
+  ((viewer . VIEWER)
+   (type   . MIME-TYPE)
+   (test   . TEST))
+
+where VIEWER is either a lisp command, e.g., a major-mode, or a
+string containing a shell command for viewing files of the
+defined MIME-TYPE.  In case of a shell command, %s will be
+replaced with the file.
+
+MIME-TYPE is a regular expression being matched against the
+actual MIME type.  It is implicitly surrounded with ^ and $.
+
+TEST is an lisp form which is evaluated in order to test if the
+entry should be chosen.  The `test' entry is optional.
+
+When selecting a viewer for a given MIME type, the first viewer
+in this list with a matching MIME-TYPE and successful TEST is
+selected.  Only if none matches, the standard `mailcap-mime-data'
+is consulted."
+  :type '(repeat
+	  (list
+	   (choice (function :tag "Function or mode")
+		   (string :tag "Shell command"))
+	   (regexp :tag "MIME Type")
+	   (sexp :tag "Test (optional)")))
+  :get #'mailcap--get-user-mime-data
+  :set #'mailcap--set-user-mime-data
+  :group 'mailcap)
+
 ;; Postpone using defcustom for this as it's so big and we essentially
 ;; have to have two copies of the data around then.  Perhaps just
 ;; customize the Lisp viewers and rely on the normal configuration
@@ -700,6 +753,20 @@ mailcap-viewer-lessp
       t)
      (t nil))))
 
+(defun mailcap-select-preferred-viewer (type-info)
+  "Return an applicable viewer entry from `mailcap-user-mime-data'."
+  (let ((info (mapcar (lambda (a) (cons (symbol-name (car a))
+                                   (cdr a)))
+                      (cdr type-info)))
+        viewer)
+    (dolist (entry mailcap-user-mime-data)
+      (when (and (null viewer)
+                 (string-match (concat "^" (cdr (assq 'type entry)) "$")
+                               (car type-info))
+                 (mailcap-viewer-passes-test entry info))
+        (setq viewer entry)))
+    viewer))
+
 (defun mailcap-mime-info (string &optional request no-decode)
   "Get the MIME viewer command for STRING, return nil if none found.
 Expects a complete content-type header line as its argument.
@@ -732,41 +799,47 @@ mailcap-mime-info
 	    (if no-decode
 		(list (or string "text/plain"))
 	      (mail-header-parse-content-type (or string "text/plain"))))
-      (setq major (split-string (car ctl) "/"))
-      (setq minor (cadr major)
-	    major (car major))
-      (when (setq major-info (cdr (assoc major mailcap-mime-data)))
-	(when (setq viewers (mailcap-possible-viewers major-info minor))
-	  (setq info (mapcar (lambda (a) (cons (symbol-name (car a))
-					       (cdr a)))
-			     (cdr ctl)))
-	  (while viewers
-	    (if (mailcap-viewer-passes-test (car viewers) info)
-		(setq passed (cons (car viewers) passed)))
-	    (setq viewers (cdr viewers)))
-	  (setq passed (sort passed 'mailcap-viewer-lessp))
-	  (setq viewer (car passed))))
-      (when (and (stringp (cdr (assq 'viewer viewer)))
-		 passed)
-	(setq viewer (car passed)))
+      ;; Check if there's a user-defined viewer from `mailcap-user-mime-data'.
+      (setq viewer (mailcap-select-preferred-viewer ctl))
+      (if viewer
+          (setq passed (list viewer))
+        ;; None found, so heuristically select some applicable viewer
+        ;; from `mailcap-mime-data'.
+        (setq major (split-string (car ctl) "/"))
+        (setq minor (cadr major)
+              major (car major))
+        (when (setq major-info (cdr (assoc major mailcap-mime-data)))
+          (when (setq viewers (mailcap-possible-viewers major-info minor))
+            (setq info (mapcar (lambda (a) (cons (symbol-name (car a))
+                                            (cdr a)))
+                               (cdr ctl)))
+            (while viewers
+              (if (mailcap-viewer-passes-test (car viewers) info)
+                  (setq passed (cons (car viewers) passed)))
+              (setq viewers (cdr viewers)))
+            (setq passed (sort passed 'mailcap-viewer-lessp))
+            (setq viewer (car passed))))
+        (when (and (stringp (cdr (assq 'viewer viewer)))
+                   passed)
+          (setq viewer (car passed))))
       (cond
        ((and (null viewer) (not (equal major "default")) request)
-	(mailcap-mime-info "default" request no-decode))
+        (mailcap-mime-info "default" request no-decode))
        ((or (null request) (equal request ""))
-	(mailcap-unescape-mime-test (cdr (assq 'viewer viewer)) info))
+        (mailcap-unescape-mime-test (cdr (assq 'viewer viewer)) info))
        ((stringp request)
-	(mailcap-unescape-mime-test
-	 (cdr-safe (assoc request viewer)) info))
+        (mailcap-unescape-mime-test
+         (cdr-safe (assoc request viewer)) info))
        ((eq request 'all)
-	passed)
+        passed)
        (t
-	;; MUST make a copy *sigh*, else we modify mailcap-mime-data
-	(setq viewer (copy-sequence viewer))
-	(let ((view (assq 'viewer viewer))
-	      (test (assq 'test viewer)))
-	  (if view (setcdr view (mailcap-unescape-mime-test (cdr view) info)))
-	  (if test (setcdr test (mailcap-unescape-mime-test (cdr test) info))))
-	viewer)))))
+        ;; MUST make a copy *sigh*, else we modify mailcap-mime-data
+        (setq viewer (copy-sequence viewer))
+        (let ((view (assq 'viewer viewer))
+              (test (assq 'test viewer)))
+          (if view (setcdr view (mailcap-unescape-mime-test (cdr view) info)))
+          (if test (setcdr test (mailcap-unescape-mime-test (cdr test) info))))
+        viewer)))))
 
 ;;;
 ;;; Experimental MIME-types parsing
--8<---------------cut here---------------end--------------->8---

Bye,
Tassilo

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Teemu Likonen]

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

Tassilo Horn [2016-04-08 22:46:49+02] wrote:

> (2) Or maybe we could add a customizable list `mailcap-user-mime-data'
>     (better name welcome) which would override `mailcap-mime-data',
>     i.e., if a viewer is specified there, then `mailcap-mime-data' with
>     the heuristics around it won't even be consulted.

> Any better suggestions?  If not, I can do that.  (In case I'd implement
> that, should that go only into master or emacs-25?)

I don't oppose mailcap-user-mime-data but I think user shouldn't be
forced to duplicate his mailcap configuration inside Emacs. User already
has his system's mailcap settings and many programs respect that. Why
doesn't Emacs? (Ok, it does but with its own preferences of
doc-view-mode etc.)

How about a variable like mailcap-prefer-system-mailcap with a non-nil
value would put the priority of doc-view-mode (and every viewer Emacs
offers) below system's mailcap configuration?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Eli Zaretskii]

> From: Teemu Likonen <tlikonen@iki.fi>
> Date: Sat, 09 Apr 2016 12:27:38 +0300
> Cc: 23184@debbugs.gnu.org
> 
> > (2) Or maybe we could add a customizable list `mailcap-user-mime-data'
> >     (better name welcome) which would override `mailcap-mime-data',
> >     i.e., if a viewer is specified there, then `mailcap-mime-data' with
> >     the heuristics around it won't even be consulted.
> 
> > Any better suggestions?  If not, I can do that.  (In case I'd implement
> > that, should that go only into master or emacs-25?)
> 
> I don't oppose mailcap-user-mime-data but I think user shouldn't be
> forced to duplicate his mailcap configuration inside Emacs.

Does that suggestion really require duplication, or does it require to
have only those (hopefully few) entries that override the default?

> User already has his system's mailcap settings and many programs
> respect that. Why doesn't Emacs? (Ok, it does but with its own
> preferences of doc-view-mode etc.)

Because doc-view-mode is specific to Emacs?

> How about a variable like mailcap-prefer-system-mailcap with a non-nil
> value would put the priority of doc-view-mode (and every viewer Emacs
> offers) below system's mailcap configuration?

That'd still require a separate customization in Emacs, so I wonder
how it is better than what Tassilo proposed.

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Tassilo Horn]

Hi Teemu and Eli,

that's exactly my intention: have a simple way to override emacs heuristic 
choices in case where they don't match the user's expectations. So in your 
case, you'd be fine with just a single entry for application/pdf and your 
preferred viewer.

The problem with an option to simply use ~/.mailcap is that in there, you 
cannot use emacs viewers at all.

Bye,
Tassilo


Am 9. April 2016 11:47:50 schrieb Eli Zaretskii <eliz@gnu.org>:

>> From: Teemu Likonen <tlikonen@iki.fi>
>> Date: Sat, 09 Apr 2016 12:27:38 +0300
>> Cc: 23184@debbugs.gnu.org
>>
>> > (2) Or maybe we could add a customizable list `mailcap-user-mime-data'
>> >     (better name welcome) which would override `mailcap-mime-data',
>> >     i.e., if a viewer is specified there, then `mailcap-mime-data' with
>> >     the heuristics around it won't even be consulted.
>>
>> > Any better suggestions?  If not, I can do that.  (In case I'd implement
>> > that, should that go only into master or emacs-25?)
>>
>> I don't oppose mailcap-user-mime-data but I think user shouldn't be
>> forced to duplicate his mailcap configuration inside Emacs.
>
> Does that suggestion really require duplication, or does it require to
> have only those (hopefully few) entries that override the default?
>
>> User already has his system's mailcap settings and many programs
>> respect that. Why doesn't Emacs? (Ok, it does but with its own
>> preferences of doc-view-mode etc.)
>
> Because doc-view-mode is specific to Emacs?
>
>> How about a variable like mailcap-prefer-system-mailcap with a non-nil
>> value would put the priority of doc-view-mode (and every viewer Emacs
>> offers) below system's mailcap configuration?
>
> That'd still require a separate customization in Emacs, so I wonder
> how it is better than what Tassilo proposed.
>

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Tassilo Horn]

Hi Teemu and Eli,

I've just pushed the proposed change plus an addition to the Emacs MIME
manual.  I'm closing this bug now.

Bye,
Tassilo

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Michael Heerdegen]

Tassilo Horn <tsdh@gnu.org> writes:

> I've just pushed the proposed change plus an addition to the Emacs
> MIME manual.  I'm closing this bug now.

Thanks.  Works well for me, and the doc also looks good.

I think what Teemu means is that this solution doesn't allow to say:
"for pdf, don't use docview, use the viewer as defined in the user's
mailcap file".  One has to speak out the viewer's name, so there are two
places to change when the user changes his mind about which is his
preferred viewer (mailcap file and emacs customization).

We could allow something like (viewer . system) in
`mailcap-user-mime-data' which would mean, more or less: consult
`mailcap-mime-data' but skip any internal viewers.  Does that make
sense?

Anyway, this change is already a big win; hard to believe that until now
there has not been any defcustom for mime types.


Regards,

Michael.

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Teemu Likonen]

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

Michael Heerdegen [2016-04-11 18:05:41+02] wrote:

> I think what Teemu means is that this solution doesn't allow to say:
> "for pdf, don't use docview, use the viewer as defined in the user's
> mailcap file".  One has to speak out the viewer's name, so there are two
> places to change when the user changes his mind about which is his
> preferred viewer (mailcap file and emacs customization).

Yes, I meant that. I have ~/.mailcap file. With that new Emacs change I
need to duplicate ~/.mailcap in Emacs. It's not a big issue but it kind
of makes Emacs a bad citizen in the system. Many programs respect
~/.mailcap but Emacs quite doesn't.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Tassilo Horn]

Michael Heerdegen <michael_heerdegen@web.de> writes:

Hi Michael and Teemu,

>> I've just pushed the proposed change plus an addition to the Emacs
>> MIME manual.  I'm closing this bug now.
>
> Thanks.  Works well for me, and the doc also looks good.
>
> I think what Teemu means is that this solution doesn't allow to say:
> "for pdf, don't use docview, use the viewer as defined in the user's
> mailcap file".  One has to speak out the viewer's name, so there are
> two places to change when the user changes his mind about which is his
> preferred viewer (mailcap file and emacs customization).

The problems with some variable "use my ~/.mailcap for these MIME types"
are the following (when seen as an exclusive alternative to my
`mailcap-user-mime-data'):

  - I'm not sure if mailcaps are common on non-GNU/unixy systems
    (Windows, Mac OSX, ...), so that could possibly rule out users of
    such systems.

  - What would happen if a user's mailcap doesn't contain an entry for a
    given type?  Obviously, she'd need to add it there or add it to
    `mailcap-mime-data' which is not customizable and thus not very
    user-friendly.

  - What if a user want's to override a default entry with another Lisp
    alternative?  That couldn't be added to ~/.mailcap (other than with
    some emacsclient call), so it would have to be added into
    `mailcap-mime-data' _before the standard alternatives_ which is
    quite hard.

> We could allow something like (viewer . system) in
> `mailcap-user-mime-data' which would mean, more or less: consult
> `mailcap-mime-data' but skip any internal viewers.  Does that make
> sense?

Yes, that would be doable.  But wouldn't that essentially be the same as
(viewer . "xdg-open") on GNU or (viewer . "open") on Mac OSX?

Bye,
Tassilo

bug#23184: 25.0.92; User-friendly way to override doc-view-mode as MIME viewer

[Michael Heerdegen]

Tassilo Horn <tsdh@gnu.org> writes:

> Yes, that would be doable.  But wouldn't that essentially be the same
> as (viewer . "xdg-open") on GNU or (viewer . "open") on Mac OSX?

I don't know.  I'm not using a desktop environment.  I think in this
case it's not essentially the same.  Dunno about the average use case on
Gnu.


Michael.