Re: lynx-dev UTF-8 display questions (was: Superscripts)

[Klaus Weide]

On 12 Jun 2000, Sergei Pokrovsky wrote:

> >>>>> "Klaus" == Klaus Weide <address@hidden> writes:
>   Klaus> ----------------------------------------------------
>   Klaus> <TITLE>UTF-8 test</TITLE> before1<A
>   Klaus> HREF="file:///dev/null">abc</A>after1<BR> before2<A
>   Klaus> HREF="file:///dev/null">&#x430&#x431&#x432;</A>after2
>   Klaus> ----------------------------------------------------
> 
>   Klaus> If not, what must happen to create the effect?  E.g. more
>   Klaus> than one link per line, long lines...
> 
> Not in this example.  It used to happen to a link _after_ a multibyte
> character; but even permutation of your example lines (in order to put
> ÁÂ× before abc) produces now the earlier effect.

Earlier effect == everything ok?  Or now == not?

> OTOH, the place where I did observe it last time, shows another
> irregularity: a preceding <em></em> is extended to the anchor
> situated next to it while passing through that anchor.  Actually that
> is not related to UTF or SLANG_MBCS_HACK; you can look at
> http://www.esperanto.mv.ru/KompLeks/UTF8/AL.html#ALINESIGNO
> and pass through the links downwards, observing the emphasis (in my
> case, underlining) expand to the anchors.  Or just pass through this:
> 
> ------
> <TITLE>EM test</TITLE>
> <em>before1</em><A HREF="file:///dev/null">abc</A>after1<BR>
> <em>before3</em><A HREF="file:///dev/null">def</A>after3<BR>
> ------
> 
> (pass from abc to def; abc becomes underlined; press ^R and see abc
> loose the emphasis).

Yes, that's an embarrassing glitch I already found a few days ago,
caused by changes from me (around 2.8.3dev.13).  I am working on
a fix.

Note that this only happens when links are not numbered (which is
why I didn't see it earlier), and when the <A> follows an </em>
(or similar) directly, without a space.


>   Klaus> Lynx with SLANG_MBCS_HACK works for me in most "normal"
>   Klaus> terminals (xterm, linux console), without the problem you
>   Klaus> describe.  With some terminal descriptions there are screen
>   Klaus> corruption problems, however; for example, with
>   Klaus> TERM=xterm-r6, which differs from the TERM type I normally
>   Klaus> use for xterms.
> 
> Now I am not sure that my failed attempt to install ncurses didn't
> spoil things; I believe it improbable, because that seems to be done
> later, after the failure point; OTOH the misbehavior was very similar
> to the situation when I had no UTF-capable xterm.

If the problem reappears as mysteriously as it has disappears, let us
know. :)

>   Klaus> You are still talking about running lynx under emacs term
>   Klaus> emulation, right?  [...]
> 
> No, now I use lynx in an xterm window:

You had me confused...
But you are still using lynx compiled with slang, not ncurses, yes?

> unfortunately the Emacs mouse
> binding is incompatible with Lynx's (could Lynx be more flexible in
> this respect?  I'd prefer very much to see its treatment of mouse-1 be
> moved to mouse-2, mouse-1 is like Emacs' mouse-2, and it would be nice
> if mouse-1 would simply position the cursor at the anchor ... and also
> to have backspace behaving like b ...)

My previous opinion on why mouse buttons are as they are: somewhere in
        URL: http://www.flora.org/lynx-dev/html/month091999/msg00217.html
(thanks to Google).

I can see why, as a user accustomed to emacs in X, you'd want mouse-1
-> mouse-2, but for everyone else mouse-1 is more natural.  IMHO.
Personally, I'd find mouse-3 == popup more natural than the current
mouse-2 == popup; but that's only available with ncurses, anyway.
Of course, it "would be nice" if this were configurable.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden