Re: less & composing characters - fix

["Mark Nudelman" <markn at greenwoodsoftware dot com>]

Hi Nadim,

> This version (385) is solid.  I tried a number of things
> and all worked without issue.

Glad to hear it.

> One minor annoyance.  When I search for LAA via '/'
> (LAA is a combined character made up of LAM + AlEF), the
> LAM disappears on me (as it should), but instead of seeing
> the LAA glyph, I see the ALEF.

Hm, this isn't quite what I would have expected.  Less actually has a
rather strange way of outputting characters in the command line.  When
you type a character X, what actually gets output is "ESC[K X \b X",
where "ESC[K" is the line-clear escape sequence for your terminal.  So
in your LAM+ALEF case, what's getting output is
    ESC[K 0xD9 0x84 \b 0xD9 0x84
    ESC[K 0xD8 0xA7 \b 0xD8 0xA7
(D9,84 is of course the UTF-8 encoding of 0x644 and D8,A7 is the
encoding of 627.)  I don't know if it's reasonable to expect the
terminal to do the right thing (ie. replace the LAM with LAA) given that
sequence.  But you say it does work for composing characters, which have
the same kind of sequence, so I'm not sure what's going on.

So I'm guessing it is an
> encoding issue or similar.  In terms of encodings,
>
>   ALEF - 0x0627 -> 0xfe8d or 0xfe8e
>   LAM  - 0x0644 -> 0xfedd or 0xfede or 0xfedf or 0xfee0
>   LAA  -           0xfefb or 0xfefc

I don't quite understand this -- what are the hex values to the right of
the arrow?

> BTW: I did see instances where mlterm should not show 2-3
>      lines in a file esp. when doing a search and the only
>      way to illuminate the highlighted text is to scroll-up
>      say 10-12 lines and CTRL-L (redraw).

Could you give me an example of this?

--Mark