User interface confusion; p0.30 invokes VM?

User interface confusion; p0.30 invokes VM?

[Karl Kleinpaste]

I just started using Pterodactyl; I disabled TM in .gnus this morning,
to try out things with p0.30.

I got this message:

   [  56: Francine Raley      ] [Fwd: The "other" munch] 

Its displayed content is:
________________

From: Francine Raley <francine@charcoal.com> 
Subject: [Fwd: The "other" munch] 
To: karl@jprc.com 
X-Sent: 1 day, 11 hours, 40 minutes, 19 seconds ago 
 
[text/plain] 
 
Let me know what you think. 
 
[message/rfc822] 
________________

XEmacs is in an xterm; I have no buttons to mouse-push directly.  I
have to cross a *Tree* buffer on the way to *Article*, that is, I have
to do `C-x o' twice just to get a weapon near the victim.

Once I get there, hitting RET on "[message/rfc822]" invokes VM.

Huh?

Sure, I see the content of the message.  Wondering what keybindings
are available to me, I hit `C-h m'.  I got a *Help* buffer which says
"This is VM 6.43."  I don't even have `<' and `>' keys for top and
bottom of the message -- they're bound to vm-{top,bottom}-of-message,
but hitting them gives me complaints, "Unknown folder type."

Trying to `q' out of this nightmare causes me to lose every displayed
buffer except the message itself (still in VM mode), with a minibuf
query about what folder in which to save the message.  Huh?  I don't
want to save it at all, I just want to get back to *Article* or
*Summary*.  I hit `C-g', leaving me still with just the VM-mode
subarticle.  I had to kill the buffer, which somehow left me in
*Original Article*, so I had to select *Summary* the hard way.

I tried the `C-d' thing on the same message.  Selecting the 1st
subarticle did the obvious thing.  Selecting the 2nd gave me another
"clickable" message/rfc822 again, rather than showing me the enclosed
message itself as the total content of that piece, as I expected
intuitively.  "Fool me once" etc, so I didn't hit RET on it again.
Not that time, anyway.

Though it's painful over a phone line, I invoked XEmacs under X and
tried again.  The VM invocation induces a left-margin graphic toolbar,
for which it extended my XEmacs out to the right by an inch or so, to
preserve the visible text space for me, I guess.  But considering that
I already use a 204x89 XEmacs on this 1280x1024 screen in a 10pt font,
that newly-extended right side of XEmacs went right off the right edge
of my screen entirely.  Huh?  Finding a way to quit out of VM mode,
the extra space taken by VM's graphic toolbar was not reclaimed, so
now I'm stuck with a too-large XEmacs.  If I go back into Gnus and
screw up my courage to face off against an unwanted VM invocation
again, will it extend XEmacs to the right *again*?  I don't know, and
I'm not going to find out.

This is all so incredibly non-intuitive at this point.  How did a VM
invocation get into Gnus?  There are reasons why I *don't* use VM.
I'll be the first to admit if I simply don't know what's going on, if
I've missed some announcement about the necessary .gnus requirements
to start Pterodactyl, or if there are other selections available for
how to view enclosed subarticles, but right now, I'm strongly inclined
to say that there's a very large violation of the Principle of Least
Astonishment: All I did was to disable TM in .gnus and start Gnus.

RH5.1 Linux, XEmacs 20.4 [MULEless, from RH contrib rpm], p0.30.

Late observation: RET on "[message/rfc822]" alternates between
invoking VM and apparently being a NOP.

--karl

Re: User interface confusion; p0.30 invokes VM?

[William M. Perry]

Karl Kleinpaste <karl@jprc.com> writes:

> I just started using Pterodactyl; I disabled TM in .gnus this morning,
> to try out things with p0.30.
> 
> I got this message:
> 
>    [  56: Francine Raley      ] [Fwd: The "other" munch] 
> 
> Its displayed content is:
> ________________
> 
> From: Francine Raley <francine@charcoal.com> 
> Subject: [Fwd: The "other" munch] 
> To: karl@jprc.com 
> X-Sent: 1 day, 11 hours, 40 minutes, 19 seconds ago 
> 
> [text/plain] 
> 
> Let me know what you think. 
> 
> [message/rfc822] 
> ________________
> 
> XEmacs is in an xterm; I have no buttons to mouse-push directly.  I
> have to cross a *Tree* buffer on the way to *Article*, that is, I have
> to do `C-x o' twice just to get a weapon near the victim.
> 
> Once I get there, hitting RET on "[message/rfc822]" invokes VM.

  This is mm.el's fault.  In the defaults mm-mime-data, if vm-mode is
fboundp, it will use that to view message/rfc822 messages.  This should be
changed. :)

-Bill P.

Re: User interface confusion; p0.30 invokes VM?

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@jprc.com> writes:

> [message/rfc822] 

[...]

> Once I get there, hitting RET on "[message/rfc822]" invokes VM.

[Tale of woe elided.]  :-)

The defaults for many of the parts are, perhaps, less than optimal.
Below is the current default; new, improved and spiffy defaults are
welcome, as are defaults for new and spiffy things.  (Hey!  No mp3 or
realadio viewer!)

I think the format should be self-explanitory, but here's the
explanation: `viewer' can be a string (shell process) or a function
and `test' is a form that can be executed to see if that viewer can be
run.

Hm.  Wouldn't the following be nice to use?  Then you could use
`(mailcap-command-p "mpeg_play")' to check for that command,
and stuff.

(defun mailcap-command-p (command)
  "Say whether COMMAND is in the exec path."
  (let ((path exec-path)
	file)
    (catch 'found
      (while path
	(when (and (file-exists-p
		    (setq file (expand-file-name command (pop path))))
		   (file-executable-p file))
	  (throw 'found file))))))

(Ok, so I've rediscovered `goto', and it makes me feel warm an fuzzy.) 

Feel free to write new and wonderful functions to display weird
formats and stuff.  Mail your things to this mailing list as you
develop it.

Here's the current value:

  '(("application"
     ("x-x509-ca-cert"
      (viewer . ssl-view-site-cert)
      (test . (fboundp 'ssl-view-site-cert))
      (type . "application/x-x509-ca-cert"))
     ("x-x509-user-cert"
      (viewer . ssl-view-user-cert)
      (test . (fboundp 'ssl-view-user-cert))
      (type . "application/x-x509-user-cert"))
     ("octet-stream"
      (viewer . mailcap-save-binary-file)
      (type ."application/octet-stream"))
     ("dvi"
      (viewer . "open %s")
      (type   . "application/dvi")
      (test   . (eq (mm-device-type) 'ns)))
     ("dvi"
      (viewer . "xdvi %s")
      (test   . (eq (mm-device-type) 'x))
      ("needsx11")
      (type   . "application/dvi"))
     ("dvi"
      (viewer . "dvitty %s")
      (test   . (not (getenv "DISPLAY")))
      (type   . "application/dvi"))
     ("emacs-lisp"
      (viewer . mailcap-maybe-eval)
      (type   . "application/emacs-lisp"))
     ("x-tar"
      (viewer . mailcap-save-binary-file)
      (type   . "application/x-tar"))
     ("x-latex"
      (viewer . tex-mode)
      (test   . (fboundp 'tex-mode))
      (type   . "application/x-latex"))
     ("x-tex"
      (viewer . tex-mode)
      (test   . (fboundp 'tex-mode))
      (type   . "application/x-tex"))
     ("latex"
      (viewer . tex-mode)
      (test   . (fboundp 'tex-mode))
      (type   . "application/latex"))
     ("tex"
      (viewer . tex-mode)
      (test   . (fboundp 'tex-mode))
      (type   . "application/tex"))
     ("texinfo"
      (viewer . texinfo-mode)
      (test   . (fboundp 'texinfo-mode))
      (type   . "application/tex"))
     ("zip"
      (viewer . mailcap-save-binary-file)
      (type   . "application/zip")
      ("copiousoutput"))
     ("pdf"
      (viewer . "acroread %s")
      (type   . "application/pdf"))
     ("postscript"
      (viewer . "open %s")
      (type   . "application/postscript")
      (test   . (eq (mm-device-type) 'ns)))
     ("postscript" 
      (viewer . "ghostview %s")
      (type . "application/postscript")
      (test   . (eq (mm-device-type) 'x))
      ("needsx11"))
     ("postscript"
      (viewer . "ps2ascii %s")
      (type . "application/postscript")
      (test . (not (getenv "DISPLAY")))
      ("copiousoutput")))
    ("audio"
     ("x-mpeg"
      (viewer . "maplay %s")
      (type   . "audio/x-mpeg"))
     (".*"
      (viewer . mm-view-sound-file)
      (test   . (or (featurep 'nas-sound)
		      (featurep 'native-sound)))
      (type   . "audio/*"))
     (".*"
      (viewer . "showaudio")
      (type   . "audio/*")))
    ("message"
     ("rfc-*822"
      (viewer . vm-mode)
      (test   . (fboundp 'vm-mode))
      (type   . "message/rfc-822"))
     ("rfc-*822"
      (viewer . w3-mode)
      (test   . (fboundp 'w3-mode))
      (type   . "message/rfc-822"))
     ("rfc-*822"
      (viewer . view-mode)
      (test   . (fboundp 'view-mode))
      (type   . "message/rfc-822"))
     ("rfc-*822" 
      (viewer . fundamental-mode)
      (type   . "message/rfc-822")))
    ("image"
     ("x-xwd"
      (viewer  . "xwud -in %s")
      (type    . "image/x-xwd")
      ("compose" . "xwd -frame > %s")
      (test    . (eq (mm-device-type) 'x))
      ("needsx11"))
     ("x11-dump"
      (viewer . "xwud -in %s")
      (type . "image/x-xwd")
      ("compose" . "xwd -frame > %s")
      (test   . (eq (mm-device-type) 'x))
      ("needsx11"))
     ("windowdump"
      (viewer . "xwud -in %s")
      (type . "image/x-xwd")
      ("compose" . "xwd -frame > %s")
      (test   . (eq (mm-device-type) 'x))
      ("needsx11"))
     (".*"
      (viewer . "aopen %s")
      (type   . "image/*")
      (test   . (eq (mm-device-type) 'ns)))
     (".*"
      (viewer . "xv -perfect %s")
      (type . "image/*")
      (test   . (eq (mm-device-type) 'x))
      ("needsx11")))
    ("text"
     ("plain"
      (viewer  . w3-mode)
      (test    . (fboundp 'w3-mode))
      (type    . "text/plain"))
     ("plain"
      (viewer  . view-mode)
      (test    . (fboundp 'view-mode))
      (type    . "text/plain"))
     ("plain"
      (viewer  . fundamental-mode)
      (type    . "text/plain"))
     ("enriched"
      (viewer . enriched-decode-region)
      (test   . (fboundp 'enriched-decode-region))
      (type   . "text/enriched"))
     ("html"
      (viewer . mm-w3-prepare-buffer)
      (test   . (fboundp 'w3-prepare-buffer))
      (type   . "text/html")))
    ("video"
     ("mpeg"
      (viewer . "mpeg_play %s")
      (type   . "video/mpeg")
      (test   . (eq (mm-device-type) 'x))
      ("needsx11")))
    ("x-world"
     ("x-vrml"
      (viewer  . "webspace -remote %s -URL %u")
      (type    . "x-world/x-vrml")
      ("description"
       "VRML document")))
    ("archive"
     ("tar"
      (viewer . tar-mode)
      (type . "archive/tar")
      (test . (fboundp 'tar-mode)))))


-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: User interface confusion; p0.30 invokes VM?

[Hallvard B Furuseth]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> 	(when (and (file-exists-p
> 		    (setq file (expand-file-name command (pop path))))
> 		   (file-executable-p file))

Why file-exists-p?  Can a file be executable but not exist?

Also, don't search the path for absolute file names.

(defun mailcap-command-p (command)
  "Say whether COMMAND is in the exec path."
  (let ((path (if (file-name-absolute-p command) '(nil) exec-path))
 	file)
    (catch 'found
      (while path
 	(when (and (file-executable-p
		    (setq file (expand-file-name command (pop path))))
		   (not (file-directory-p file)))
 	  (throw 'found file))))))

However, neither version works on operating systems that append a file
type to command file names (.COM, .BAT, .EXE, whatever).  You can do it
in C, though.  Maybe you can get RMS to make lread.c:openp() available
to emacs-lisp commands.  Something like this (untested, a slight fix to
something I wrote a long time ago):


extern Lisp_Object Qidentity;

DEFUN ("locate-file", Flocate_file, Slocate_file, 0, 2, 0,
  "Find first FILE in PATH with one of SUFFIXES, checking EXEC-ONLY.
EXEC_ONLY is nil to find all files, t to only find executables.
PATH and SUFFIXES are lists or colon-separated strings.
SUFFIXES may also be t, then the system's suffixes for executables are used.")
  (file, path, suffixes, exec_only)
     Lisp_Object file, path, suffixes, exec_only;
{
  char *suff;

  if (STRINGP (path))
    path = decode_env_path (NULL, XSTRING (path)->data);

  if (EQ (suffixes, Qt))
    suff = EXEC_SUFFIXES;
  else if (NILP (suffixes))
    suff = "";
  else
    {
      if (!STRINGP (suffixes))
	{
	  struct gcpro gcpro1, gcpro2, gcpro3;
	  GCPRO3 (path, file, exec_only);	/* Is this necessary? */
	  suffixes = Fmapconcat (Qidentity, suffixes, build_string (":"));
	  UNGCPRO;
	}
      suff = XSTRING(suffixes)->data;
    }

  (void) openp (path, file, suff, &file, !NILP(exec_only));
  return file;
}

-- 
Hallvard

Re: User interface confusion; p0.30 invokes VM?

[Lars Magne Ingebrigtsen]

Hallvard B Furuseth <h.b.furuseth@usit.uio.no> writes:

> Why file-exists-p?  Can a file be executable but not exist?
> 
> Also, don't search the path for absolute file names.

I've installed your version of the function now.

> However, neither version works on operating systems that append a file
> type to command file names (.COM, .BAT, .EXE, whatever).  You can do it
> in C, though.  Maybe you can get RMS to make lread.c:openp() available
> to emacs-lisp commands.  Something like this (untested, a slight fix to
> something I wrote a long time ago):

Well, I didn't write it, so perhaps you could send it to RMS?  (Or, if 
the paperwork on the code is OK, I could forward it to him...)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: User interface confusion; p0.30 invokes VM?

[Hrvoje Niksic]

Hallvard, note that XEmacs has a `locate-file', with slightly
different arguments (I think the last one accepts more spiff).  It
would be nice if you submitted the compatible function to Stallman.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
The meta-Turing test counts a thing as intelligent if it seeks to
devise and apply Turing tests to objects of its own creation.

Re: User interface confusion; p0.30 invokes VM?

[Edward J. Sabol]

Excerpts from mail: (16-Sep-98) Re: User interface confusion; p0.30 invokes VM? by Hrvoje Niksic
> Hallvard, note that XEmacs has a `locate-file', with slightly
> different arguments (I think the last one accepts more spiff).  It
> would be nice if you submitted the compatible function to Stallman.

A similar function is already in Emacs' executable.el. See the function
`executable-find'. I don't think it's autoloaded though.

Later,
Ed

Re: User interface confusion; p0.30 invokes VM?

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> A similar function is already in Emacs' executable.el. See the function
> `executable-find'. I don't think it's autoloaded though.

I've now modified `mailcap-command-p' to use suffixes under crippled
pseudo-OSs.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: User interface confusion; p0.30 invokes VM?

[Karl Kleinpaste]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> The defaults for many of the parts are, perhaps, less than optimal.
...
> Feel free to write new and wonderful functions to display weird
> formats and stuff.  Mail your things to this mailing list as you
> develop it.

What is the semantic of more than 1 entry for a given type?  That is,
there are already 4 elements for message/rfc822.  Is it simply a
matter of looping through them in sequence, until the per-element
usability test returns non-nil?  If so, isn't vm-mode always
autoloaded, and thus isn't vm-mode always the choice made?  To phrase
the question without the negative voice, how would one stipulate a
different personal choice?

What is the relationship between the list from mailcap.el and the
similar list in mm.el?

Since I'm using Gnus to read mail, I would like to continue to use
Gnus to read enclosd articles which are still essentially mail.  The
idea seems very odd, to invoke an entirely different mail-reading
package to do what I already want using Gnus.  Something like:

      ("rfc-*822"
       (viewer . gnus-article-prepare)
       (type   . "message/rfc-822"))

(I haven't actually looked to see if there is any other preparatory
work to be done, before blindly invoking gnus-article-prepare.)

I don't see why one would invoke any other possibility, from within
Gnus -- if one wants the VM interface, one should be using VM in the
1st place.  No?

--karl

Re: User interface confusion; p0.30 invokes VM?

[William M. Perry]

Karl Kleinpaste <karl@jprc.com> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> > The defaults for many of the parts are, perhaps, less than optimal.
> ...
> > Feel free to write new and wonderful functions to display weird
> > formats and stuff.  Mail your things to this mailing list as you
> > develop it.
> 
> What is the semantic of more than 1 entry for a given type?  That is,
> there are already 4 elements for message/rfc822.  Is it simply a
> matter of looping through them in sequence, until the per-element
> usability test returns non-nil?  If so, isn't vm-mode always
> autoloaded, and thus isn't vm-mode always the choice made?  To phrase
> the question without the negative voice, how would one stipulate a
> different personal choice?
> 
> What is the relationship between the list from mailcap.el and the
> similar list in mm.el?
> 
> Since I'm using Gnus to read mail, I would like to continue to use
> Gnus to read enclosd articles which are still essentially mail.  The
> idea seems very odd, to invoke an entirely different mail-reading
> package to do what I already want using Gnus.  Something like:
> 
>       ("rfc-*822"
>        (viewer . gnus-article-prepare)
>        (type   . "message/rfc-822"))
> 
> (I haven't actually looked to see if there is any other preparatory
> work to be done, before blindly invoking gnus-article-prepare.)
> 
> I don't see why one would invoke any other possibility, from within
> Gnus -- if one wants the VM interface, one should be using VM in the
> 1st place.  No?

  The stuff lars is using is general purpose.  mm.el was meant to be used
by lots of programs, I just haven't cleaned it up enough yet. :)  At the
time I wrote mm.el, VM was about the only choice.

  And VM is not always autoloaded.  Especially in Emacs and XEmacs 21.x

-Bill P.

Re: User interface confusion; p0.30 invokes VM?

[Karl Kleinpaste]

wmperry@aventail.com (William M. Perry) writes:
> And VM is not always autoloaded.  Especially in Emacs and XEmacs 21.x

Unless PGnus autoloads VM on its own, I don't understand how I
inadvertently got it, because I have surely never asked for it.

Re: User interface confusion; p0.30 invokes VM?

[Chris Halverson]

Karl Kleinpaste <karl@jprc.com> writes:

> Unless PGnus autoloads VM on its own, I don't understand how I
> inadvertently got it, because I have surely never asked for it.

I got the same thing when I uncommented my TM setup. I dug deep
through my .emacs to make sure I wasn't autoloading VM or anything (I
used to use VM, so I figured it was entirely possible it was still
autoloading). So you're not alone :)

Chris

-- 
Chris D. Halverson                         Complete Internet Solutions
PGP mail accepted, finger for public key   http://www.CompleteIS.com/~cdh/

Re: User interface confusion; p0.30 invokes VM?

[SL Baur]

Karl Kleinpaste <karl@jprc.com> writes in ding@gnus.org:

> wmperry@aventail.com (William M. Perry) writes:
>> And VM is not always autoloaded.  Especially in Emacs and XEmacs 21.x

> Unless PGnus autoloads VM on its own, I don't understand how I
> inadvertently got it, because I have surely never asked for it.

In XEmacs 20.4 and previous, the VM autoloads are hardcoded into
loaddefs.el (a file dumped with XEmacs), so they're present whether
you've deleted lisp/vm or not and regardless of whatever you have in
your .emacs.

In XEmacs 21.x, you have the option to not install vm at all.  In my
copy of XEmacs 21:

(fboundp 'vm-mode)
=> nil

Re: User interface confusion; p0.30 invokes VM?

[Lars Magne Ingebrigtsen]

Karl Kleinpaste <karl@jprc.com> writes:

> What is the semantic of more than 1 entry for a given type?  That is,
> there are already 4 elements for message/rfc822.  Is it simply a
> matter of looping through them in sequence, until the per-element
> usability test returns non-nil?

Yes.

> If so, isn't vm-mode always
> autoloaded, and thus isn't vm-mode always the choice made?  To phrase
> the question without the negative voice, how would one stipulate a
> different personal choice?

Well, I think the default sequence should be different, but this
structure isn't for specifying personal choice.  The user is supposed
to either put things in the .mailcap file or say things like

(add-mime-display-method "image/gif" "xv -perfect %s")

in .emacs.

(The name of the function may change, though.)

The biiig mailcap alist is for specifying defaults that may or may not 
be useful for the user.

> Since I'm using Gnus to read mail, I would like to continue to use
> Gnus to read enclosd articles which are still essentially mail.  The
> idea seems very odd, to invoke an entirely different mail-reading
> package to do what I already want using Gnus.  Something like:
> 
>       ("rfc-*822"
>        (viewer . gnus-article-prepare)
>        (type   . "message/rfc-822"))
> 
> (I haven't actually looked to see if there is any other preparatory
> work to be done, before blindly invoking gnus-article-prepare.)
> 
> I don't see why one would invoke any other possibility, from within
> Gnus -- if one wants the VM interface, one should be using VM in the
> 1st place.  No?

Yes, but mailcap.el has nothing to do with Gnus.

So there should be a `test' clause like

(and (featurep 'gnus)
     (gnus-alive-p))

for that element, and something similar for VM.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen