emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [emacs-bidi] Mixed L2R and R2L paragraphs and horizontal scroll


From: Eli Zaretskii
Subject: Re: [emacs-bidi] Mixed L2R and R2L paragraphs and horizontal scroll
Date: Tue, 02 Feb 2010 22:04:51 +0200

> Date: Tue, 2 Feb 2010 00:05:28 +0200
> From: "Ehud Karni" <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > > scrolled (23) in a smaller window:
> > >        +-------------------------------+
> > >        |$ong-description               |
> > >        |$NOITPIRCSED-GNO               |
> > >        +--------------------------------
> >
> > Why like above and not like below:
> >
> >        +-------------------------------+
> >        |$ong-description               |
> >        |$RCSED-GNOL-YREV               |
> >        +--------------------------------
> 
> Because if you choose your way of scrolling, you always see the same
> part (of different length) - the beginning of the Hebrew text.

Well, actually, no, that's not what I meant.  Although I understand
how I could confuse people (even you ;-) about what I think should
happen.

So let me tell directly and unequivocally what I propose.  There are
two main principles:

  . Line truncation and continuation is done in the visual order

  . Horizontal scrolling is done in the logical order

What this means is that an L2R line that ends with a stretch of R2L
text will be continued as follows:

       +-------------------------------+
       |name2 1234 catag2 NOITPIRCSED-\|
       |GNOL-YREV                      |
       +-------------------------------+

and truncated thusly:

       +-------------------------------+
       |name2 1234 catag2 NOITPIRCSED-$|
       +-------------------------------+

Similarly, an R2L line will be continued like this:

       +-------------------------------+
       |/RCSED-GNOL-YREV-YREV-YREV-YREV|
       |                         NOITPI|
       +-------------------------------+

and truncated like this:

       +-------------------------------+
       |$RCSED-GNOL-YREV-YREV-YREV-YREV|
       +-------------------------------+

Horizontal scrolling will cause these two paragraphs:

       +-------------------------------+
       |name1 1234 catag1 very-long-de$|
       |                               |
       |$RCSED-GNOL-YREV-YREV-YREV-YREV|
       +-------------------------------+

to successively look like below, each time after hscrolling by one or
more columns to the left:

       +-------------------------------+
       |$me1 1234 catag1 very-long-des$|
       |                               |
       |$IRCSED-GNOL-YREV-YREV-YREV-YR$|
       +-------------------------------+

       +-------------------------------+
       |$e1 1234 catag1 very-long-desc$|
       |                               |
       |$PIRCSED-GNOL-YREV-YREV-YREV-Y$|
       +-------------------------------+
...
       +-------------------------------+
       |$ catag1 very-long-description |
       |                               |
       | NOITPIRCSED-GNOL-YREV-YREV-YR$|
       +-------------------------------+
...
       +-------------------------------+
       |$very-long-description         |
       |                               |
       |         NOITPIRCSED-GNOL-YREV$|
       +-------------------------------+

Okay?

At least regarding line truncation, I checked ``prior art''.  The
Wordprocessor-That-Shall-Remain-Unnamed truncates long lines exactly
like I show above: in the visual order.  (Of course, it doesn't have
the truncation glyphs, but instead pops up the horizontal scroll bar.)
My other reason for doing truncation and continuation in visual order
is that it's much easier ;-) The code that produces glyphs and fills
the glyph matrices with them proceeds in the visual order, as it did
in the unidirectional display.  So it is easy enough to stop when we
hit the window margin.  Truncating in logical order, i.e. producing
something like

       +-------------------------------+
       |name2 1234 catag2 ED-GNOL-YREV$|
       +-------------------------------+

requires a much more serious surgery of the redisplay code.

Note that ED-GNOL-YREV in the last example above is the _beginning_ of
the R2L text, as opposed to

       +-------------------------------+
       |name2 1234 catag2 NOITPIRCSED-$|
       +-------------------------------+

in my suggestion, where we display the _end_ of the R2L text.

> Suppose the the Hebrew text is very long, twice the window size, then
> you'll see only the first width-of-screen Hebrew characters, no matter
> how much scrolling you do.

I hope you see now that this is not so.  Scrolling "to the left" will
eventually show every character of the R2L text at the end of the
line.

> > > Example 3: text, mostly in Hebrew but some lines have no Hebrew,
> > > like arithmetic formulas (Latin + digits + neutrals only) or
> > > ls output (real recent email I got).
> > >
> > > Here we could use either external dictation of RTL direction or
> > > automatic paragraph direction. In RTL direction the formula may be
> > > displayed wrongly (if neutral characters are on the sides). When
> > > automatic paragraph direction is used, short lines may be too far
> > > apart.
> >
> > A real example will help here.
> 
> Here is a real example (upper case = Hebrew)
> PUT THE FILES IN
> /dir1/sdr2/sdr3
> AND I WILL TAKE THEM
> 
> This will appear as (think of 160 character wide text screen):
>                                                    NI SELIF EHT TUP
> /dir1/sdr2/sdr3
>                                                MEHT EKAT LLIW I DNA

And why would ``rigid scrolling'' help in this case?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]