[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Sergei Pokrovsky
Subject: Re: lynx-dev UTF-8 display questions (was: Superscripts)
Date: 13 Jun 2000 13:45:23 +0700
User-agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6

>>>>> Klaus Weide writes:

  Klaus> 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.

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

Both.  Everything is OK now; and "now" is meant to be "no longer"
(sorry for the typo).


  >>  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.

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

It reappeared earlier than you probably expected.  Actually it's you
who have brought that spawn of evil by advising to apply -nocolor
(actually what I needed and what you probably meant was -nounderline).

Well, if I launch lynx with -nocolor,

xterm -u8 \
-fn -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 \
-g x57 -e lynx -nocolor &

and open a page in UTF-8 or even in Latin-1, say

then moving through the links (press a few Up arrows, then a few
Downs) creates strange phantom anchors at random spots, sometimes
beyond the end of line, sometimes overwriting some innocent plain
prose ...  And these phantoms are not washed away with ^R ... And the
WHEREIS-line spawns are rising trough the screen ...

No such horror without -nocolor.

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

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

Presently, yes.  (As well as of the yesterday's writing.)

  >> 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 ...)

  Klaus> My previous opinion on why mouse buttons are as they are:
  Klaus> somewhere in URL:
  Klaus> (thanks to Google).

  Klaus> I can see why, as a user accustomed to emacs in X, you'd want
  Klaus> mouse-1 -> mouse-2, but for everyone else mouse-1 is more
  Klaus> natural.  IMHO.

Well, that's not obvious.  Those who open a link with m-1 usually do
it with a double-click.  A single m-1 serves to position the cursor at
the link, in order to inspect it (and then, eventually, to follow it
or to copy it to the clipboard etc).  Presently I do not know how to
inspect a link directly, without passing through all the intermediate
links with arrow keys -- which is very dull.

  Klaus> Personally, I'd find mouse-3 == popup more natural than the
  Klaus> current mouse-2 == popup; but that's only available with
  Klaus> ncurses, anyway.  Of course, it "would be nice" if this were
  Klaus> configurable.

Oh yes.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]