On 12 Jun 2000, Sergei Pokrovsky wrote:
> >>>>> "Klaus" == Klaus Weide <[EMAIL PROTECTED]> 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">абв</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 [EMAIL PROTECTED]
