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: Ehud Karni
Subject: Re: [emacs-bidi] Mixed L2R and R2L paragraphs and horizontal scroll
Date: Thu, 4 Feb 2010 16:02:58 +0200

On Wed, 03 Feb 2010 20:59:13 Eli Zaretskii wrote:
>
> Maybe you are talking about how lines are re-flowed by these word
> processors.  If so, the Emacs equivalent is fill-paragraph, or the
> various packages (like longlines) that do it automatically for you.
> When a line is filled, a newline is inserted, and then the order of
> the text spread between several lines is what you expect:

OK, I want it to work like fill-paragraph, but I don't want to REALLY
do fill-paragraph, because I don't want to modify the file AT ALL.


>        +----------------------------------------+
>        |some latin text followed by HTIW HCAORP\|
>        |PA SILE FO TLUSER LARUTANNU EHT DNA SNO\|
>        |ITPO GNILLORCS TNEREFFID EHT FO GNITART\|
>        |SNOMED ROF TXET GNOL 2YREV 1YREV WERBEH\|
>        | small latin tail                       |
>        +----------------------------------------+
>
> And yes, the R2L text reads bottom to top.  But rewriting the central
> piece of the display engine to make this use-case look better is
> beyond my resources.  There's a lot of more important (IMO) issues to
> take care of.  If this will really annoy users (and we won't know
> until bidi Emacs hits the FTP sites, because these features are unique
> to Emacs), someone else will have to come and do the surgery it takes,
> sorry.

>From experience (with my visual Hebrew package) this is very annoying.
Think of 3 very long (150, 270 and 150 characters) viewed on 80
characters wide screen, It is very confusing to find the start of
each line and to read upward 1 or 2 lines and go down again.


> > with smaller screen (assume only 7 lines long):
> >
> >        +--------------------+
> >        |some latin text fol$|
> >        |lowed by HTIW HCAOR$|
> >        |PPA SILE FO TLUSER $|
> >        |LARUTANNU EHT DNA S$|
> >        |NOITPO GNILLORCS TN$|
> >        |EREFFID EHT FO GNIT$|
> >        |ARTSNOMED ROF TXET $|
> >        +--------------------+
>
> Again, I think you meant \ for continuation lines, not $ for
> truncation.

Yes.

> > Oops, the beginning of the Hebrew text disappeared.
>
> And this is significantly worse than if the _end_ of the text
> disappears, because...?

Yes, it is definitely worse. First the the case of text that goes just
a screen and half down. You'll have to scroll one page down, read a
few lines upward, that scroll up, find the last line you read and
continue upward, you may need scroll up once more for the beginning of
the text. Second, consider the case of a very, very long text (more
than 100 continuation lines), it is almost impossible to find its
start with your way, while in my way it is just the normal way of
scrolling down (I do it by half screen at a time).


> That's not the same rules applied to scrolling, that's exactly the
> same situation of truncating a mixed L2R/R2L text as you described
> above.
>
> The issue with scrolling was when you have _two_ different paragraphs,
> one with left-to-right base direction, the other with right-to-left.

I don't think this issue is problematic per se. I think that if the
solution for R2L scrolling is good (when all the paragraphs are R2L)
then it can be applied even when combined with L2R paragraphs on the
same screen without any annoyance to the user.

Ehud.


--
 Ehud Karni           Tel: +972-3-7966-561  /"\
 Mivtach - Simon      Fax: +972-3-7976-561  \ /  ASCII Ribbon Campaign
 Insurance agencies   (USA) voice mail and   X   Against   HTML   Mail
 http://www.mvs.co.il  FAX:  1-815-5509341  / \
 GnuPG: 98EA398D <http://www.keyserver.net/>    Better Safe Than Sorry




reply via email to

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