On 07/24/10 03:58 AM, Stephen J. Turnbull wrote:
XEmacs *does* understand those, via the function url-retrieve.
However, changing the meaning of command-line arguments
program means is a recipe for trouble. Cf. the "Slow startup" thread,
where Apple has gone and broken the DISPLAY variable. Trying to guess
what is intended by these programs is a difficult problem.
> So, I was crafting an email with thunderbird to which I attached a text
> file.
> But, then I wanted to view/edit that file. So, I double-clicked on it and
> it asked me which application that I wanted to open it with. I chose
> /usr/local/bin/xemacs which is 21.4.22. If I had picked OpenOffice,
> then everything works. But, for text files, there is nothing like
> XEmacs:o)
There is probably a way to tell Thunderbird that it's talking to a
traditional Unix program that expects to receive a file, not an URL.
Traditionally in mimecap files that format would be
text/plain /usr/local/bin/xemacs %s
but I wouldn't be surprised if Thunderbird has usurped that format to
mean URL, not file.
I can't think of any quick hacks to make XEmacs do the right thing
with an URL from the command line. I'll try later in the week.
I was trying to avoid URIs since they are such a PITA. I have spent
hours hacking them and they are no fun at all: very tricky to debug and
the syntax from hell. So, I decided to find a quick hack like you
suggest. Since XEmacs doesn't ship with a wrapper, I created one...
ARGS=
for i
do
ARGS="$ARGS \"`expr \"$i\" : \"file://\(.*\)\" \|
\"$i\"`\""
done
if ! eval gnuclient $ARGS 2>/dev/null
then eval xemacs-21.4.21 $ARGS
fi
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/mailman/listinfo/xemacs-beta