Re: [Lynx-dev] Minor XLOADIMAGE quirk [fixed]

[Patrick]

On Sun, 20 Jul 2008 13:09:54 -0400 (EDT)
Thomas Dickey wrote:

> On Sun, 20 Jul 2008, Patrick wrote:
> 
[...]
> >
> > Just two of many tests, of course.  Those are the first two
> > entries that mention xli, in both files.
> 
> That looks consistent
> 
> > That seems more or less as it should be, except I don't see why
> > it's being so stubborn.  Are these values compiled in, or does it
> > re-read /etc/mailcap whenever it runs?  Changing it between
> > launches didn't seem to have any effect.
> 
> It reads the data from mailcap - mostly.  In lynx.cfg, you can specify
> your own mailcap as well as the location of the global one.
> 
> Again, userdefs.h defines a symbol:
> 
> #define XLOADIMAGE_COMMAND "xli %s &"
> 
> However, you can override this in lynx.cfg:

Sorry, I made a few mistakes.

First, it was launching /usr/bin/xloadimage , not xli [but their
output does look similar].  So when I changed the mailcap entries
for xli, this of course had no effect on xloadimage.  But maybe
it only happened *after* changing the /usr/X11R6/bin/xli entries.

I didn't notice this until trying;
    ps -e | grep xli
while an image was being displayed, and saw no output.

But Lynx still ignores the
XLOADIMAGE_COMMAND:lynx_view
entry in lynx.cfg , favouring the mailcap entry.  Is this
behaviour new?

By the way, here's the lynx_view script I was using;

#!/bin/sh
if [ "$DISPLAY" = "" ]
then
        cacaview $@
        #  Renders images as coloured ASCII art on the terminal.
else
        gqview $@ > /dev/null & exit
fi

#  End.

Gqview is only there for testing, because it doesn't look or act
anything like xli or xloadimage.  Guess I can change it back to
xli now.  :-)

Also removed the `test=test -n "$DISPLAY"' part from
~/.lynx/mailcap , so it will also work on the console, instead of
giving me a `D)ownload or C)ancel' prompt if not in X.



Thanks again,

Patrick.
-- 
Never try to teach a pig to sing.  It wastes your time and annoys
the pig.
                -- Lazarus Long, "Time Enough for Love"