Re: [ANNOUNCE] mutt 1.5.16 released
On 2007-06-17 12:22:33 -0400, Derek Martin wrote:
> On Sun, Jun 17, 2007 at 05:23:44PM +0200, Vincent Lefevre wrote:
> > But I assume that you're not able to give a mailcap that works under
> > Mac OS X without a line of code.
>
> I guess I really don't care, since I don't use OS X, and have no plans
> to start any time soon.
And I don't care about the problems with vi under SCO and Solaris,
since I don't use it. :)
> Even if that's true, it's hardly a deficiency of Mutt... it's a
> deficiency of Mac OS X for lacking reasonable software for dealing
> with media types from the command line.
This is not that simple. There are two problems:
1. The fact that some applications don't support that the file is zeroed
and removed by Mutt. Note that some Linux applications have the same
problem. I don't think this is a deficiency, in particular if the file
is large. In fact, Mutt has a similar behavior: if you remove a mailbox
after loading it into Mutt, Mutt will complain when trying to read
messages.
2. The security problem mentioned in my previous message. If fact, one
can explicitly tell "open" which application to use, but this is not
practical (e.g. if one upgrades OpenOffice, one also needs to upgrade
the mailcap file, because the version number is part of the application
name).
> If I ever did use OS X, I doubt I would read my mail there. Then
> again, while there are always exceptions, I tend to save attachments
> before viewing them anyway, so it's (for me) mostly a moot point.
I also do that (mainly when I need to keep the attachment). But this
is less practical than typing [Return] to view the attachment.
> [As a side note, I read my personal mail on a remote server, so
> mailcap is almost completely irrelevant in that case. I transfer
> attachments to my local machine, in the exceptionally rare case when I
> receive something I actually want to look at, since in most cases
> that's much faster than waiting for remote X clients -- and then I
> need to transfer the file anyway to work with it. My work mail I
> do read on my local workstation, and that's where the above applies.]
It would probably be better to have a wrapper script that transfers
the attachment on the local machine and launches a local X client (this
probably needs a daemon on the local side, or a modified terminal to
use a protocol so that the terminal can execute commands from escape
sequences).
I run Mutt in a screen session, which I can use either locally or
remotely via ssh. So, locally I have an X11 access (or the Mac OS X
desktop), and remotely, I don't have an X11 access (I usually do not
forward X11 for the reason you gave).
> > Also your mailcap is simplistic. In practice, you should test that
> > DISPLAY is set before starting an X11 client, so that a fallback can
> > be used.
>
> I think I'm perfectly capable of figuring out whether I'm running in X
> or not...
I also know when I'm running X or not, but the mailcap system also
needs to know that so that...
> If I'm not in X I probably can't view PDF files anyway, at least not
> in any useful capacity.
Some PDF files are perfectly viewable in a text terminal (many of them
just contain text). For those PDF files, I'd like to be able to view
them in the terminal. One could say the same thing for HTML.
> Your assertion that I *need* to write code to support all this is
> false, and completely absurd, like most of your other points. I don't
> need to, and have not ever done so.
And in the same way, most users don't need to write code to use an
editor.
> Given that vi is adhering strictly to (at least one revision of) the
> rather widely accepted and complied-to POSIX standards, that position
> is completely unsupportable.
No, I think that SCO and Solaris just had a buggy interpretation of
POSIX, which says for vi:
EXIT STATUS
The following exit values shall be returned:
0
Successful completion.
>0
An error occurred.
IMHO, when saying "an error occurred", this implicitly means during
the completion (i.e. after the last interactive operation). There
can be an error during the editing, but if the completion is fine,
then this is a successful completion and the editor can return 0.
Of course, this must not be confused with the following:
When any error is encountered and the standard input is not a
terminal device file, vi shall not write the file or return to
command or text input mode, and shall terminate with a non-zero
exit status.
which more or less deals with the case where vi is run in a
non-interactive way.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)