[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
From: |
Kenichi Handa |
Subject: |
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM |
Date: |
Wed, 18 Aug 2010 16:53:27 +0900 |
In article <address@hidden>, Eli Zaretskii <address@hidden> writes:
> > For instance, if you have this text:
> > r2l contents is embeded here [RLE] R2L CONTENTS [PDF].
> > the current bidi code generates glyphs in this visual order:
> > ... here [PDF] STNETNOC L2R [RLE].
> Yes, this is intentional: when these formatting characters are
> revealed, they should enclose the text they affect.
There is another way to enclose the text:
... here [RLE] STNETNOC L2R [PDF].
I don't know which is good. Does the current code conform
to "5.2 Retaining Format Codes" of UAX#9?
> > and that means we can't compose [PDF] with the following ".".
> Hmm.. I thought composition works on the buffer text level, i.e. it
> examines characters in logical order (even if it sometimes does it
> backwards). So you should be able to compose PDF with the period that
> follows it, no?
The current code never composes characters striding over
bidi boundary.
In the above example, when bidi_move_to_visually_next sets
IT's position at [PDF], scan direction is changed, and thus
composition_compute_stop_pos is called to find the next
stop. In this case, composition_compute_stop_pos scans
buffer backward, and thus it never finds the sequence
"[PDF]."
> > And what should we do when the last character is one of
> > formatting characters?
> >
> > At last, it seems like an abuse of composition in this case
> > because those formatting characters don't construct a
> > grapheme cluster with the following char.
> OK, I'm convinced. Let's go with the hide mode instead. I hope the
> need for one more C-f/C-b will not be confusing. Maybe we should
> modify cursor motion commands to automatically move past these
> characters? What do other application do, for example OpenOffice?
In OpenOffice (3.2), we must type Left key twice to move
past one formatting characters. Gedit is the same.
---
Kenichi Handa
address@hidden
- [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/08/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/08/17
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/08/18
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/08/18
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM,
Kenichi Handa <=
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Eli Zaretskii, 2010/08/18
- Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Kenichi Handa, 2010/08/18
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM, Yair F, 2010/08/18
- Prev by Date:
Re: [emacs-bidi] Re: Hebrew tutorial
- Next by Date:
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
- Previous by thread:
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
- Next by thread:
Re: [emacs-bidi] Treatment of LRE,RLE,LRO,RLO,PDF,LRM,RLM
- Index(es):