[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unicode support
From: |
Eli Zaretskii |
Subject: |
Re: Unicode support |
Date: |
Wed, 25 Jul 2001 13:38:18 +0300 (IDT) |
On Wed, 25 Jul 2001, Roozbeh Pournader wrote:
> > Changing shape after each typed character will probably have
> > undesirable effects on many optimizations used by the Emacs redisplay
> > engine, specifically those for inserting a single character. That's
> > why I suggested to go about it as we do with just-in-time font-lock,
> > i.e. defer them a bit.
>
> Please note that this is not changing shape after each typed character.
> This is the minimum number of shape changing. This is only changing shape
> after each non-letter that follows a letter. I think this should suit an
> editor like emacs best.
That's true, but it doesn't really matter, from the point of view of the
Emacs display code. It cannot optimize the redisplay for a single
character because it needs to consider the additional complications which
depend on what character was inserted and which character surround the
one which was inserted.
The display engine cannot use the what-was-the-last-typed-character kind
of logic because a character could be inserted not by typing it, but by
something else, such as the `insert' primitive. Also, the redisplay is
not directly triggered by typing a character, it happens later (could be
_much_ later if the user happens to type extremely fast), so the notion
of the ``previous action'' etc. is meaningless.
It's possible that the same layer of display code where I'm now trying to
add the logical-to-visual transformation (and which will have to run for
Arabic anyway) could handle the presentation forms as well, because it
already examines neighbouring characters. Then it could propagate this
information to the glyph matrix, and the code which actually delivers the
font glyphs to the screen could take the appropriate action, by using a
different glyph from the font.
> if (previous_action != INSERTION) {
> last_arabic = compute_last_arabic();
> last_shape = shape(last_arabic);
> join = (last_shape == INITIAL || last_shape == MEDIAL);
> }
>
> if (is_arabic_letter(key)) {
> join = insert_into_buffer(key, join);
> /* join is true if the last letter has been left-joining */
> last_arabic = last_buffer_index();
> }
> else if (is_non_spacing_mark(key)) {
> insert_into_buffer(key);
> }
> else {
> reshape(last_arabic);
> join = FALSE;
> last_arabic = NOTHING;
> }
>
> With the above code, you only need to change the shape in the 'reshape'
> function. When you insert a new character, you insert it with the most
> probable shape, so the need for change minimizes...
Alas, this code is totally incompatible with the structure of the Emacs
display code. In particular, insertion into the buffer and glyph
production are in two different parts of the code, and are not directly
connected (i.e. neither one of them calls the other one).
- Re: Unicode support, (continued)
- Re: Unicode support, Werner LEMBERG, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/24
- Re: Unicode support, Werner LEMBERG, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/24
- Re: Unicode support, Roozbeh Pournader, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/25
- Re: Unicode support, Roozbeh Pournader, 2001/07/24
- Re: Unicode support, Eli Zaretskii, 2001/07/25
- Re: Unicode support, Miles Bader, 2001/07/25
- Re: Unicode support, Roozbeh Pournader, 2001/07/25
- Re: Unicode support,
Eli Zaretskii <=
Re: Unicode support, Dave Love, 2001/07/22
Re: Unicode support, Karl Eichwalder, 2001/07/19
Re: Unicode support (was: null-device), Dave Love, 2001/07/22