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

[Sergei Pokrovsky]

>>>>> "Klaus" == Klaus Weide <address@hidden> writes:

  Klaus> On 11 Jun 2000, Sergei Pokrovsky wrote:
  >> >>>>> "Klaus" == Klaus Weide <address@hidden> writes:
  >> 
  >> (answering to my complaint about too early word wrap for UTF-8
  >> Cyrillic:)
  Klaus> ./configure --with-screen=slang [...]  make
  Klaus> SITE_DEFS="-DSLANG_MBCS_HACK"
  >>
  Klaus> It works well for me in most $TERMinal types (but not all -
  Klaus> although those aren't UTF-8 capable anyway).
  >>  I've reinstalled slang and got normal lines for the multibyte

  Klaus> Which version are you using now?  Is it a different version
  Klaus> than before?

  Klaus> I'm not sure why you reinstalled slang - iirc, we didn't
  Klaus> discuss anything where slang was suspected to be the problem.

Well, you had asked about the slang I was using; and I was not sure (I
had installed slang many years ago, and since then had purged some
unused programs; so, to be sure, I've installed slang-1.4.1).

  >> characters.  BUT at an unacceptable price: when the cursor passes
  >> through an anchor containing multibyte character(s), the line is
  >> spoiled (it is shifted to the left, so that some text before the
  >> multibyte anchor is lost, while the last characters of the line
  >> are duplicated, as the former tail remains on the screen).

  Klaus> Can you give a minimal example where this is happening?

No, I've rebuilt lynx with the same options as before, but *that*
misbehavior is no longer reproduced.  I do not know why; probably the
environment has has changed on my machine (in particular, now I've
succeeded to reinstall ncurses and that could change terminfo
... actually, the misbehavior was observed after a failure to
reinstall ncurses, though I don't think that its "make -install"
succeeded to spoil anything).

I must confess that rebuilding lynx is an inexhaustible source of
surprise for me.  Of course I contribute to it by modifying some
configuration options, but I can never predict the side effects:

- changing a COLOR may change a face (bright colors become bold; I'd
  rather prefer the opposite, as the boldness make them too bright,
  while some pale colors could be usable only in a bold face);

- emphasis is sometimes rendered with the color only (which I'd
  prefer), or is combined with underline (which I'd rather turn off,
  but don't know how to do it).

  Klaus>  For example, does it happen with the following:

  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.

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

  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.

  Klaus> You are still talking about running lynx under emacs term
  Klaus> emulation, right?  I tried that too now, but using emacs
  Klaus> 19.34 without all that coding-system-... support you have.  I
  Klaus> had display problems even without SLANG_MBCS_HACK.

No, now I use lynx in an xterm window: 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> All this just in case you still have patience left for
  Klaus> playing...

I thank you, Klaus, for your kind patience with me ... I still do
enjoy it.

-- 
Sergei

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