Eli Zaretskii | 1 Feb 2010 05:11
Picon

Re: Mixed L2R and R2L paragraphs and horizontal scroll

> Date: Sun, 31 Jan 2010 21:01:29 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: emacs-bidi <at> gnu.org, emacs-devel <at> gnu.org
> 
>  > In a R2L line, columns should be numbered from the
>  > right margin of the window.
> 
> Technically columns are numbered by counting characters following the
> last newline in the buffer text.

As Miles points out, it's not a simple character counting, but I see
what you mean.

> Just that for R2L text you have to jump to the end of the text first
> and then go back in the text.

Actually, if a R2L line displays text made mostly of strong R
characters (which is normally the case), the first character at the
right margin of the window is also the first character following the
newline in the buffer's logical order.

> So I suppose you're using the term window margin as metaphor here.

Yes, in a sense.  In the displayed portion of the buffer, that is
really the window margin, though.

> There is one thing I conceptually don't understand yet: When I currently
> shrink the width of a window Emacs doesn't hide text at the left side of
> the window but text at the right side may get truncated when the window
> becomes too small.  Will this behavior be reverted for R2L text in the
(Continue reading)

martin rudalics | 1 Feb 2010 09:34
Picon
Picon

Re: Mixed L2R and R2L paragraphs and horizontal scroll

 > Actually, if a R2L line displays text made mostly of strong R
 > characters (which is normally the case), the first character at the
 > right margin of the window is also the first character following the
 > newline in the buffer's logical order.

Unless it's horizontally scrolled.

 >> There is one thing I conceptually don't understand yet: When I currently
 >> shrink the width of a window Emacs doesn't hide text at the left side of
 >> the window but text at the right side may get truncated when the window
 >> becomes too small.  Will this behavior be reverted for R2L text in the
 >> sense that text at the left side is truncated?
 >
 > Yes, the truncation for R2L lines will happen at the left, and the
 > truncation glyph will be displayed there as well.  (It actually
 > already works like that, at least on a tty.)

It might be probably interesting for a user to dynamically switch during
typing whether a buffer should be dominantly displayed as R2L or L2R.

martin

Eli Zaretskii | 1 Feb 2010 21:21
Picon

Re: Mixed L2R and R2L paragraphs and horizontal scroll

> Date: Mon, 01 Feb 2010 09:34:53 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: emacs-bidi <at> gnu.org, emacs-devel <at> gnu.org
> 
> It might be probably interesting for a user to dynamically switch during
> typing whether a buffer should be dominantly displayed as R2L or L2R.

I already implemented such a feature: a per-buffer variable that
forces all paragraphs to be either L2R or R2L.  A value of `nil' means
the direction of each paragraph is dynamically determined by applying
the rules described in the Unicode Standard Annex 9 (UAX#9).
martin rudalics | 2 Feb 2010 09:08
Picon
Picon

Re: Mixed L2R and R2L paragraphs and horizontal scroll

 > I already implemented such a feature: a per-buffer variable that
 > forces all paragraphs to be either L2R or R2L.  A value of `nil' means
 > the direction of each paragraph is dynamically determined by applying
 > the rules described in the Unicode Standard Annex 9 (UAX#9).

I meant a function which does (1) set such a variable and (2) apply it
to one or all windows showing a buffer.  Calling this function would
temporarily override any L2R/R2L specifications specified for a file,
buffer, or paragraph.

BTW, do UAX#9 paragraphs require new definitions for `paragraph-start'
or `paragraph-separate'?

martin

Eli Zaretskii | 2 Feb 2010 20:30
Picon

Re: Mixed L2R and R2L paragraphs and horizontal scroll

> Date: Tue, 02 Feb 2010 09:08:40 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: emacs-bidi <at> gnu.org, emacs-devel <at> gnu.org
> 
>  > I already implemented such a feature: a per-buffer variable that
>  > forces all paragraphs to be either L2R or R2L.  A value of `nil' means
>  > the direction of each paragraph is dynamically determined by applying
>  > the rules described in the Unicode Standard Annex 9 (UAX#9).
> 
> I meant a function which does (1) set such a variable

You mean, besides "M-x set-variable RET"?

> and (2) apply it to one or all windows showing a buffer.

Currently, the variable is per-buffer, so it affects all the windows
showing that buffer.  Why would one need to do that only in some
windows showing a buffer?

> Calling this function would temporarily override any L2R/R2L
> specifications specified for a file, buffer, or paragraph.

There are no specifications for a file (unless you set the variable
I'm talking about in file's local variables section).  As for
individual paragraphs, control of their base direction is not by some
Emacs setting, but by inserting special formatting characters at the
beginning of each paragraph.  These characters (LRM and RLM) are
supposed to be invisible by default, i.e. displayed as zero-width
space, but they have strong directionality, L for LRM and R for RLM.
Since UAX#9 says that a paragraph's base direction is determined by
(Continue reading)

martin rudalics | 3 Feb 2010 17:06
Picon
Picon

Re: Mixed L2R and R2L paragraphs and horizontal scroll

 >> I meant a function which does (1) set such a variable
 >
 > You mean, besides "M-x set-variable RET"?

Yes, because it would have affected the appearance of text in one window
only.

 >> and (2) apply it to one or all windows showing a buffer.
 >
 > Currently, the variable is per-buffer, so it affects all the windows
 > showing that buffer.  Why would one need to do that only in some
 > windows showing a buffer?

I thought about giving users the possibility to work with a L2R
dominated view in one window and a R2L dominated one in another.  But if
I now understand your lock-step proposal correctly, these windows would
show the text in a similar fashion anyway.  So there seems no need to do
what I said.

martin


Gmane