Re: LYNX-DEV Various things (Was Re: Displaying graphics)

[Foteos Macrides]

Drazen Kacar <address@hidden> wrote:
>Foteos Macrides wrote:
>
>> And then, unfortunately, 
>> Drazen Kacar <address@hidden> wrote to lynx-dev with
>>      CC to Richard Stallman:
>> 
>> >Let's take a look at hill.gnu.ai.mit.edu...
>> >[... followed by the wrong section of lynx.cfg, and misinformation that,
>>   as a regular on lynx-dev, he should know better than to post.  Sigh...]
>
>It's been a long time since I compiled Lynx. Sigh... I suppose I've
>become a Netscape luser...
>
>> 
>>      Nobody should be compiling Lynx without first going through
>> userdefs.h and setting the definitions appropriately for the system.
>> If you are including a binary in the GNU CD-ROM, feel free to define
>> XLOADIMAGE_COMMAND to whatever GNU-endorsed viewer for image/* you
>> like.
>
>BTW, I can't find xview executable anywhere. The only xview I can find is a
>library, not a command. My man page (Solaris 2.5) says:

        Far, far more systems have xv than xview, so that's still the
best string for the "illustration", but the point is that the viewer
is a symbolized option for the installer, not anything hard wired in
the Lynx code that could, never mind "should", be changed.

        The other important point, is that you can NOT change it, nor
any other mappings that have defaults in src/HTInit.c, via VIEWER
mappings in lynx.cfg.  For those, you MUST use the mailcap file.

        How could that possibly be stated more clearly than it already
is in the "self documentation" of lynx.cfg?!?!?   It's not even a case
where INN is being used too generically.

        This keeps happening, and I just can't understand it.  As
another example, IMMEDIATELY above the INFOSECS, MESSAGESECS and
ALERTSECS definitions in lynx.cfg it says:

# whenever they appear (typically unexpectedly).  The default values
# are defined in userdefs.h, and can be modified here should longer
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
# pauses be desired for braille-based access to Lynx.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
#
#INFOSECS:1
#MESSAGESECS:2
#ALERTSECS:3

        Ok, so it says "braille" and not also "speech synthesizer".
I fondly recall the spare time I spent editing at least 30 C modules
with over 300 sleep() calls to use symbols added to userdefs.h and
lynx.cfg so blind users could increase them as necessary.


>>      Dave (i.e., Drazen with some 8-bit character replaces, but
>> Dave in LANG=en_US 8-) did correctly inform you that users can
>
>This 'en_US' thing could be somewhat misleading on this list. It is an
>environment variable on Unix and all is good in that context.
>
>However, HTTP has a similar construct. If you put a preference like that
>in Accept-Language header, servers with language negotiation ability will
>try to select 'en-US' variant. There are bugs in some of them (I'm not
>sure which, could be Apache) and those won't select 'en' version if 'en-US'
>is not available. Suppose you have:
>
>   Accept-Language: en-us, de; q=0.2
>
>If the server has variants in English (as 'en') and German (as 'de') and
>the above mentioned bug, you'll get a German variant. With:
>
>   Accept-Language: en, de; q=0.2
>
>you'll get an English variant.

        The HTTP and HTML specs are totally contradictory about that,
and servers vary in whether they do what's specified for HTTP, as they
should, or for HTML.  What Apache is doing is not a bug, because that
is what's specified for HTTP and it's an HTTP server.  You could include
*; q=0.001  in your  preferred document lan(G)uage  string to increase
the chances of getting something if the preferences you specifed are
handled in a way that yields no hits, but the algorithm in the current
conneg draft allows preferences to fall below that, i.e., there's no
way to say reliably "Here are my preferences, but if you can't give me
what I'd like, do still send me something."  In the FM code set I added
Negotiate: trans  to our request headers, to increase the chances of
getting back a reply body with a menu of what is available, instead of
a nothing available error.  But I suspect it will be a while before
servers actually return such bodies.

        And so...  There's nothing that can be put in any Lynx menus,
documentation, FAQ, or whatever, to explain for the utterly naive,
first time ever, Lynx users how this works and what they should do,
and what will happen if they do this versus that.  Who knows??? :) :)


>I'll try not to vaste bandwidth completely. Here are some corrections for
>userdefs.h (now, why did I look at it at all? :) for Lynx 2-6FM with
>29. 1. 1997. as the last modification date. (That's 01/29/1997 in LANG=en_US :)

        Do bear in mind that the FM code set was frozen and bequethed to
to the Lynx User Community on 29-Jan-97, and I don't have any spare time
left in me.  I don't see that there's actually any mechanism in place
to deal with the reports and suggestions that are being posted, and to
actually put out a v2.7 release.   Hopefully, someone actually qualified
to do it will step forward and do it, but for now, it seems like they
might just as well be posted to ListElves, for the North Pole elves for
Santa Claus. :) :)

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;