unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Kenichi Handa <handa@m17n.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Compositions and bidi display
Date: Fri, 30 Apr 2010 15:06:11 +0900	[thread overview]
Message-ID: <tl76339h3u4.fsf@m17n.org> (raw)
In-Reply-To: <83d3xjxys1.fsf@gnu.org> (message from Eli Zaretskii on Wed, 28 Apr 2010 20:38:54 +0300)

In article <83d3xjxys1.fsf@gnu.org>, Eli Zaretskii <eliz@gnu.org> writes:

> > The condition should be "until it reaches a character that
> > should never be composed with the currently looking
> > character".

> That is the condition I'm looking for.  But how to code it?  Is the
> code in find_automatic_composition a good starting point?

No.  The checking of possibility of composing characters at
a specific position is done within
composition_compute_stop_pos.  What we need now is where we
should stop searching in composition_compute_stop_pos.

In the case of "english HEBREW TEXT text" (lowercases are
l2r characters, upppercases are r2l characters),
get_next_display_element starts from the first "e" and
proceeds to the first " " (stage 1), then jumps to the last
"T" and proceeds back to the first "H" (stage 2), then jumps
to the last " " and proceeds to the last "t" (stage 3).

When composition_compute_stop_pos is called in stage 1,
ENDPOS should be the first " " because searching far is
useless (we may have to compose some of "TEXT" before
composing some of "HEBREW").  When
composition_compute_stop_pos is called in stage 2, ENDPOS
should be the first "H" because searching far back is
useless, and so on.

Note that composition_compute_stop_pos just finds a stop
position to check, and the actual checking and composing is
done by composition_reseat_it which is called by
CHAR_COMPOSED_P.  But composition_reseat_it also needs
ENDPOS because when that funciton finds that there's no need
of composition at the stop position, it calls
composition_compute_stop_pos to update the next stop
position.

> > We may be able to simplify that condition to
> > "until it reaches a character in the different bidi level
> > (or chunk)".

> But that could be very far back.

Isn't it possible to record where the current bidi-run
started while you scan a buffer in
bidi_get_next_char_visually?

> I would really like to avoid going too far back, just to
> find out whether we reached a composition sequence,

We don't have to re-calculate ENDPOS each time.  It must be
updated only when we pass over bidi boundary.  Consider the
above example case ("english ...").

> because (again AFAIU) the length of most such sequences is
> just a few characters.  Is it correct that searching back
> MAX_AUTO_COMPOSITION_LOOKBACK characters is enough?

No.

> If MAX_AUTO_COMPOSITION_LOOKBACK is not the right number, then how
> long can a composition sequence be?

It is MAX_COMPOSITION_COMPONENTS (16), but here it's not
relevant.  What we need is to find where in a buffer (before
the scan reaches ENDPOS) next composition will happen.  And,
to perform it efficiently, giving a proper ENDPOS is
necessary.

> Another idea would be to call composition_compute_stop_pos repeatedly,
> starting from the last cmp_it->stop_pos, until we find the last
> stop_pos before the current iterator position, then compute the
> beginning and end of the composable sequence at that position, and
> record it in the iterator.  Then we handle the composition when we
> enter the sequence from either end.

To move from one composition position to the next, we must
actually call autocmp_chars and find where the current
composition ends, then start searching for the next
composition.  As autocmp_chars calls Lisp and all functions
to compose characters, it's so inefficient to call it
repeatedly just to find the last one.

---
Kenichi Handa
handa@m17n.org




  parent reply	other threads:[~2010-04-30  6:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3A521851-F7CC-45DB-A2ED-8348EF96D5CF@Freenet.DE>
     [not found] ` <83fx2q5w86.fsf@gnu.org>
     [not found]   ` <tl739yppmat.fsf@m17n.org>
2010-04-23 18:52     ` Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Eli Zaretskii
2010-04-23 20:34       ` Andreas Schwab
2010-04-23 20:43         ` Eli Zaretskii
2010-04-24 11:27           ` Eli Zaretskii
2010-04-26  2:09       ` Kenichi Handa
2010-04-26  2:38         ` Kenichi Handa
2010-04-26 11:29       ` Kenichi Handa
2010-04-26 18:40         ` Compositions and bidi display Eli Zaretskii
2010-04-27 12:15           ` Kenichi Handa
2010-04-28  3:18             ` Eli Zaretskii
2010-04-28  4:01               ` Kenichi Handa
2010-04-28 17:38                 ` Eli Zaretskii
2010-04-28 22:49                   ` Stefan Monnier
2010-04-29  3:12                     ` Eli Zaretskii
2010-04-30  2:28                       ` Kenichi Handa
2010-04-30  6:41                         ` Eli Zaretskii
2010-04-30  6:06                   ` Kenichi Handa [this message]
2010-04-30  7:08                     ` Eli Zaretskii
2010-05-03  2:39                       ` Kenichi Handa
2010-05-03  7:31                         ` Eli Zaretskii
2010-05-04  9:19                           ` Kenichi Handa
2010-05-04 17:47                             ` Eli Zaretskii
2010-04-30 10:07                     ` Eli Zaretskii
2010-04-30 12:12                       ` Kenichi Handa
2010-04-30 13:15                         ` Eli Zaretskii
2010-04-27  3:13         ` Compositions and bidi display (was: bug#5977: 24.0.50; Lao HELLO is incorrectly displayed) Eli Zaretskii
2010-04-27 12:26           ` Kenichi Handa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=tl76339h3u4.fsf@m17n.org \
    --to=handa@m17n.org \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).