bidi support? (Hebrew)

bidi support? (Hebrew)

[Uwe Brauer]

Hi


Sorry for posting in the devel list, but the last posting in the bidi
list is from 2011 and in gmane I cannot find the simple plain GNU emacs
mailing list.



I just wanted to try out the bidi support in GNU emacs 24.3
http://www.gnu.org/software/emacs/manual/html_node/emacs/Bidirectional-Editing.html

I compiled this GNU emacs version just with the plain .configure option.

However when I start GNU emacs and make 

C-h a 
bidi

No match is found (so no bidi-display-reordering etc)

Also in the Mule environment I cannot find anything indicating how to
switch to r2l.

What do I miss?

regards

Uwe Brauer 

some progress (was: bidi support? (Hebrew))

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1780 bytes --]

>> "Uwe" == Uwe Brauer <oub@mat.ucm.es> writes:

   > Hi

   > What do I miss?
Well the http://www.emacswiki.org/emacs/DisplayEngineForBiDi

Gives some hints, however I am missing interactive function turning bidi
on and off.

So the following is mostly trivial.
BTW where and how can I use bigger fonts for hebrew? (I am using  Laptop
with a 12 inch screen and the one emacs uses per default are small)

;; Basic setup for hebrew, using the bidi-engine, 
;; and an external hebrew-keyboard, (KDE with the phonetic option on)

(setq-default bidi-display-reordering t)


(defun my-turn-bidi-on ()
  "Just start with  to R2L."
  (interactive)
  (setq  bidi-paragraph-direction 'right-to-left)
  (message "R2L on!"))

(defun my-turn-bidi-off ()
  "Just start with  to L2R."
(interactive)
  (setq  bidi-paragraph-direction 'left-to-right)
  (message "R2L off!"))

;; this is from Xemacs, where (interactive "_") exists.

;; by Adrian Kubala Adrian Kubala <adrian@sixfingeredman.net>


(defun make-repeat-command (symbol command-list)
  "Command changes with each repetition.
SYMBOL is a symbol unique to this command."
  (if (eq last-command symbol)
      (set symbol (+ (eval symbol) 1))
    (set symbol 0))
  (if (>= (eval symbol) (length command-list))
      (set symbol 0))
  (call-interactively (nth (eval symbol) command-list))
  (setq this-command symbol))


(defun my-toggle-bidi ()
;  (interactive "_")
  (interactive)
  (make-repeat-command 'my-toggle-bidi '(my-turn-bidi-on
                                  my-turn-bidi-off)))


(global-set-key [(control right)] 'my-turn-bidi-on)
(global-set-key [(control left)] 'my-turn-bidi-off)
(global-set-key [(control down)] 'my-toggle-bidi)


(provide 'my-hebew-init)

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: bidi support? (Hebrew)

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Fri, 21 Jun 2013 13:16:11 +0200
> 
> I just wanted to try out the bidi support in GNU emacs 24.3
> http://www.gnu.org/software/emacs/manual/html_node/emacs/Bidirectional-Editing.html

That's a good start ;-)

> However when I start GNU emacs and make 
> 
> C-h a 
> bidi
> 
> No match is found (so no bidi-display-reordering etc)

bidi-display-reordering exists, but is not a user option, which is why
"C-h a" will not show it.  But "M-x apropos-variable RET bidi RET"
should show a couple of hits, and "M-x apropos RET bidi RET" will show
even more.

> Also in the Mule environment I cannot find anything indicating how to
> switch to r2l.
> 
> What do I miss?

The support you are looking for is turned on by default.  Just start
typing, and you will see it (there's a slew of hebrew-* input methods
for you to choose from, if you don't have a Hebrew keyboard).

Re: some progress (was: bidi support? (Hebrew))

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Fri, 21 Jun 2013 15:27:49 +0200
> 
> 
> Well the http://www.emacswiki.org/emacs/DisplayEngineForBiDi

It's awfully outdated.  Bidirectional editing in Emacs is no longer
"work in progress", since the release of Emacs 24.1.

> I am missing interactive function turning bidi on and off.

There isn't any.  Why would you need one?

> BTW where and how can I use bigger fonts for hebrew? (I am using  Laptop
> with a 12 inch screen and the one emacs uses per default are small)

Does it help to type "C-x C-+"?

> (setq-default bidi-display-reordering t)

That is already so by default.

> (defun my-turn-bidi-on ()
>   "Just start with  to R2L."
>   (interactive)
>   (setq  bidi-paragraph-direction 'right-to-left)
>   (message "R2L on!"))

No need, Emacs determines the correct base direction of each paragraph
automatically, using the method described in the UAX#9.

And paragraph direction has very little to do with display of
bidirectional text per se.  The latter works no matter what is the
paragraph's base direction.  If it didn't, you'd be unable to have R2L
text in a middle of an otherwise L2R paragraph.

> (defun my-turn-bidi-off ()
>   "Just start with  to L2R."
> (interactive)
>   (setq  bidi-paragraph-direction 'left-to-right)
>   (message "R2L off!"))

Likewise, not needed.

Re: some progress

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

   >> From: Uwe Brauer <oub@mat.ucm.es>
   >> Date: Fri, 21 Jun 2013 15:27:49 +0200
   >> 
   >> 
   >> Well the http://www.emacswiki.org/emacs/DisplayEngineForBiDi

   >> I am missing interactive function turning bidi on and off.

   > There isn't any.  Why would you need one?

   >> BTW where and how can I use bigger fonts for hebrew? (I am using  Laptop
   >> with a 12 inch screen and the one emacs uses per default are small)

   > Does it help to type "C-x C-+"?
Only  a little bit, the ascii chars are getting really bigger the hebrew
ones only a slightly bit. Do I need additional fonts (I am on (K)ubuntu 10.04)???

   >> (setq-default bidi-display-reordering t)

   > That is already so by default.

   >> (defun my-turn-bidi-on ()
   >> "Just start with  to R2L."
   >> (interactive)
   >> (setq  bidi-paragraph-direction 'right-to-left)
   >> (message "R2L on!"))

   > No need, Emacs determines the correct base direction of each paragraph
   > automatically, using the method described in the UAX#9.

Ok you are right. There are even nikkud!
However the input methods which are offered do no include hebrew
phonetic, by which I mean 


 "aleph" is on "a" etc.

That is why I use the input via KDE and that is why I need to turn on
R2L manually.



So maybe the best solution would be to provide also hebrew-phonetical[1]
Because I am a little worried how KDE keyboard and nested text may work
together.

I can give it a try to have also a hebrew-phonetical. Which are the
files to be modified?



   > And paragraph direction has very little to do with display of
   > bidirectional text per se.  The latter works no matter what is the
   > paragraph's base direction.  If it didn't, you'd be unable to have R2L
   > text in a middle of an otherwise L2R paragraph.

   >> (defun my-turn-bidi-off ()
   >> "Just start with  to L2R."
   >> (interactive)
   >> (setq  bidi-paragraph-direction 'left-to-right)
   >> (message "R2L off!"))

   > Likewise, not needed.

Footnotes:
[1]  (BTW what is hebrew-lyx suppose to be? KDE also offers it and I cannot
see any difference to standard hebrew, ok I don't have a hebrew keyboard
here, so maybe . /  etc are different.



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: some progress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 16:03:35 +0200
> 
>    > Does it help to type "C-x C-+"?
> Only  a little bit, the ascii chars are getting really bigger the hebrew
> ones only a slightly bit. Do I need additional fonts (I am on (K)ubuntu 10.04)???

You need more/better fonts.

> However the input methods which are offered do no include hebrew
> phonetic, by which I mean 
> 
> 
>  "aleph" is on "a" etc.

Try hebrew-biblical-sil, it comes close.

And "C-h C-\" will display a keyboard schematics that will tell you
which key inserts which character.

> That is why I use the input via KDE and that is why I need to turn on
> R2L manually.

??? I don't understand: as long as Emacs gets the correct characters,
no matter how they were created, everything else, including paragraph
direction, should "just work".

> So maybe the best solution would be to provide also hebrew-phonetical[1]
> Because I am a little worried how KDE keyboard and nested text may work
> together.
> 
> I can give it a try to have also a hebrew-phonetical. Which are the
> files to be modified?

leim/quail/hebrew.el.

> [1]  (BTW what is hebrew-lyx suppose to be? KDE also offers it and I cannot
> see any difference to standard hebrew, ok I don't have a hebrew keyboard
> here, so maybe . /  etc are different.

I expect hebrew-lyx in Emacs to be the same as what KDE offers.  But I
never checked.

Re: some progress

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1501 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:



   > You need more/better fonts.

Any recommentations?
   >> However the input methods which are offered do no include hebrew
   >> phonetic, by which I mean 
   >> 
   >> 
   >> "aleph" is on "a" etc.

   > Try hebrew-biblical-sil, it comes close.

Right, but still not the same

   > And "C-h C-\" will display a keyboard schematics that will tell you
   > which key inserts which character.

   >> That is why I use the input via KDE and that is why I need to turn on
   >> R2L manually.

   > ??? I don't understand: as long as Emacs gets the correct characters,
   > no matter how they were created, everything else, including paragraph
   > direction, should "just work".


Ok, the issue is with say C-c that will give C-hebrew-char with the KDE
hebrew keyboard.

However there is another issue I just found out.

If I start to write hebrew the way you described it via the input
method, then the cursor is at the left part of the buffer and does not
move while the hebrew letters are written. 




However when I use the functions I described earlier 
(defun my-turn-bidi-on ()
  "Just start with  to R2L."
  (interactive)
  (setq  bidi-paragraph-direction 'right-to-left)
  (message "R2L on!"))

Then the cursor jumps to the right and behaves in a visual way as I
expect it to behave.
As a matter of fact this is the way I would like to write hebrew and not
via the input method.






[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: bidi support? (Hebrew)

[Stefan Monnier]

> C-h a
> bidi

> No match is found (so no bidi-display-reordering etc)

The bidi-* variables are not "custom"izable, so they don't show up in
C-h a.  In general, you shouldn't need to touch them.

> Also in the Mule environment I cannot find anything indicating how to
> switch to r2l.

There's nothing to do: just type in Hebrew (for instance) and it should
be displayed properly.


        Stefan

Re: some progress

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

   >> From: Uwe Brauer <oub@mat.ucm.es>
   >> Cc: emacs-devel@gnu.org
   >> Date: Fri, 21 Jun 2013 16:03:35 +0200
   >> 
   >> > Does it help to type "C-x C-+"?
   >> Only  a little bit, the ascii chars are getting really bigger the hebrew
   >> ones only a slightly bit. Do I need additional fonts (I am on (K)ubuntu 10.04)???

   > You need more/better fonts.

Thing is in OpenOffice I seem to have better hebrew fonts. How am I
supposed to use these in emacs? 

Years ago I had something like this 

alias eheb   'emacs -font "-m17n-mule-medium-r-normal--20-140-100-100-p-90-iso10646-1" -bg grey86 \!* &'

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: some progress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 16:53:02 +0200
> 
>    > You need more/better fonts.
> 
> Any recommentations?

Not for Ubuntu.  I hope someone who uses that could tell you more.

>    >> That is why I use the input via KDE and that is why I need to turn on
>    >> R2L manually.
> 
>    > ??? I don't understand: as long as Emacs gets the correct characters,
>    > no matter how they were created, everything else, including paragraph
>    > direction, should "just work".
> 
> 
> Ok, the issue is with say C-c that will give C-hebrew-char with the KDE
> hebrew keyboard.

That's true, but unrelated to the directionality issue, see below.

> If I start to write hebrew the way you described it via the input
> method, then the cursor is at the left part of the buffer and does not
> move while the hebrew letters are written. 

I don't get the scenario, please describe what you do starting from
"emacs -Q".

> However when I use the functions I described earlier 
> (defun my-turn-bidi-on ()
>   "Just start with  to R2L."
>   (interactive)
>   (setq  bidi-paragraph-direction 'right-to-left)
>   (message "R2L on!"))
> 
> Then the cursor jumps to the right and behaves in a visual way as I
> expect it to behave.

In a buffer other than *scratch*, whenever the first character you
type is a Hebrew character, the cursor will automatically jump top the
right margin of the window.  (*scratch* and every other buffer
suitable for typing programs has its bidi-paragraph-direction set to
left-to-right by default.)

> As a matter of fact this is the way I would like to write hebrew and not
> via the input method.

Input method has nothing to do with paragraph direction, only with how
characters are inserted.

Re: some progress

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 785 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:



   >> If I start to write hebrew the way you described it via the input
   >> method, then the cursor is at the left part of the buffer and does not
   >> move while the hebrew letters are written. 

   > I don't get the scenario, please describe what you do starting from
   > "emacs -Q".


You are right, I have to admit.

However if I want to have one line us-ascii and the next line in hebrew,
without a empty line between them, then I have to use the function I
described, since I prefer to have the hebrew input always with the
cursor at the right position of the buffer. (Right as opposed to left,
not in the sense of correct).

But maybe this is my personal preference.

Thanks for the great work!



[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: bidi support? (Hebrew)

[Glenn Morris]

Uwe Brauer wrote:

> in gmane I cannot find the simple plain GNU emacs mailing list.

http://dir.gmane.org/gmane.emacs.help
https://lists.gnu.org/mailman/listinfo/help-gnu-emacs

Which is also a literal newsgroup, gnu.emacs.help.

Re: some progress

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


   >> So maybe the best solution would be to provide also hebrew-phonetical[1]
   >> Because I am a little worried how KDE keyboard and nested text may work
   >> together.
   >> 
   >> I can give it a try to have also a hebrew-phonetical. Which are the
   >> files to be modified?

   > leim/quail/hebrew.el.
Ok just a question every different hebrew input method starts with 

(quail-define-package
 "hebrew-full" "Hebrew" "עִ֫" nil "Hebrew Full method.

What is  "עִ֫" suppose to mean? Shall I leave it? Change it?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: some progress

[Uwe Brauer]

[-- Attachment #1.1: Type: text/plain, Size: 247 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


   > I don't get the scenario, please describe what you do starting from
   > "emacs -Q".

Are lisp files different? I did some testing and the scenario for
example occurs in the following file:


[-- Attachment #1.2: hebrew-test.el --]
[-- Type: application/emacs-lisp, Size: 1238 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: some progress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 18:04:01 +0200
> 
> However if I want to have one line us-ascii and the next line in hebrew,
> without a empty line between them, then I have to use the function I
> described

The function you described will change the base direction for every
paragraph in the buffer, so you cannot have R2L paragraphs and L2R
paragraphs in the same buffer.  Sometimes this is what you will want,
sometimes not.

> since I prefer to have the hebrew input always with the cursor at
> the right position of the buffer.

Emacs keeps the cursor at its logical position.  As you well know,
when the text direction changes, there are 2 possible places to put
the cursor, so Emacs must pick up one of them.

Re: some progress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 18:42:45 +0200
> 
> Ok just a question every different hebrew input method starts with 
> 
> (quail-define-package
>  "hebrew-full" "Hebrew" "עִ֫" nil "Hebrew Full method.
> 
> What is  "עִ֫" suppose to mean? Shall I leave it? Change it?

It's the mnemonics that is displayed in the mode line.  Each input
methods is supposed to have a different mnemonics, so ideally you
should change that for a new method.

Re: some progress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Jun 2013 19:45:08 +0200
> 
> Are lisp files different? I did some testing and the scenario for
> example occurs in the following file:

Every major mode for a programming language by defaults sets
bidi-paragraph-direction to left-to-right, since anything else will
result in a horribly wrong display, should some "paragraph" begin with
a strong R2L character.

Re: some progress

[Uwe Brauer]

[-- Attachment #1.1: Type: text/plain, Size: 794 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

   >> From: Uwe Brauer <oub@mat.ucm.es>
   >> Cc: emacs-devel@gnu.org
   >> Date: Fri, 21 Jun 2013 18:42:45 +0200
   >> 
   >> Ok just a question every different hebrew input method starts with 
   >> 
   >> (quail-define-package
   >> "hebrew-full" "Hebrew" "עִ֫" nil "Hebrew Full method.
   >> 
   >> What is  "עִ֫" suppose to mean? Shall I leave it? Change it?

   > It's the mnemonics that is displayed in the mode line.  Each input
   > methods is supposed to have a different mnemonics, so ideally you
   > should change that for a new method.


Ok, here is a patch for the phonetic keyboard.

Sorry since it contains no ascii chars, I decide to use application/octet-stream
which usually should be avoided.


[-- Attachment #1.2: hebrew-patch --]
[-- Type: application/octet-stream, Size: 2052 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: some progress

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Date: Fri, 21 Jun 2013 21:46:08 +0200
> 
> Ok, here is a patch for the phonetic keyboard.

Thanks.  A few suggestions below.

Also, if we are to accept this, we will need a copyright assignment
from you.

> + ("A" ?א)  ; Alef
> + ("B" ?ב)  ; Bet

This wastes keys, since 'a' is also mapped to aleph.  Wouldn't it make
more sense to have upper-case vowels to produce nikkud instead?  E.g.,
'A' could produce 'ַ' (u+05b7), 'E' could produce 'ֶ' (u+05b6), 'I'
could produce 'ִ', etc.  Upper-case consonants could then produce
letters with dagesh or other diacrticals, like 'בּ' for 'B' etc.

> + ("O" ?ס)  ; Samekh

It is IMO better to use 's' for samekh, 'S' for sin, and leave 'O' for
vav or perhaps even וֹ.  Also, I see no shin at all; perhaps 'w' would
be a good candidate.

> + ("R" ?ר)  ; Resh
> + ("R" ?ר)  ; Resh

Why twice?

> + ("." ?.)  ; Stop

Why do you need this identity mapping?

> + ("[" ?\])  ; mirroring
> + ("]" ?\[)  ; mirroring
> + ("(" ?\))  ; mirroring
> + (")" ?\()  ; mirroring
> + ("{" ?})  ; mirroring
> + ("}" ?{)  ; mirroring
> + ("<" ?>)  ; mirroring
> + (">" ?<)  ; mirroring

What about / and \ ?

Re: some progress

[Uwe Brauer]

[-- Attachment #1.1: Type: text/plain, Size: 2838 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

   >> From: Uwe Brauer <oub@mat.ucm.es>
   >> Date: Fri, 21 Jun 2013 21:46:08 +0200
   >> 
   >> Ok, here is a patch for the phonetic keyboard.

   > Thanks.  A few suggestions below.

I am sorry to have sent the patch  without extensive testing, 

   > Also, if we are to accept this, we will need a copyright assignment
   > from you.

Of course, but how? Could I sent a pgp signed assignment?

   >> + ("A" ?א)  ; Alef
   >> + ("B" ?ב)  ; Bet


Ok before going to the errors, some remarks about the keyboard in
question.

For those of us, who use Hebrew only occasionally the standard Hebrew
keyboard needs too much of adaptation to be practical [1].

There is a lot of polemics about what would be a good substitute and as
I understand it you can either

    -  have a phonetic approach: try to map the hebrew letters to its
       phonetic relatives in  us-ascii like bet-->b or

    -  try to use the forms of the letters, so shin-->w samesh-->o.


Now the keyboard I am referring to is the Hebrew-phonetic keyboard
provided by KDE, I don't know whether there is a gnome version and I
also don't know whether MS windows or Apple provide something
similar. 

The keyboard, I admit, is not entirely consistent. As you complained
o-->samesh but w--> wav. 

Nevertheless I think it should be accepted as it is, because now there
are a couple of applications with BIDI support in Linux: besides LyX,
Kile and Openoffice (I am sure there are more). 

When I used Hebrew in Lyx I could configure my own hebrew-phonetic
keyboard, but I don't know how to do this for openoffice and kile, I
even don't know whether it is possible or one should then re configure
the KDE layout. 

Since this KDE layout is some sort of standard (in the KDE world) I
think it is worth to have it in GNU emacs. Maybe we should name it
hebrew-phonetic-kde or something like this. I attach a file in which you
can see the distribution of the kde-keyboard and which is an answer to
most of your critics.



[snip]


   >> + ("R" ?ר)  ; Resh
   >> + ("R" ?ר)  ; Resh

   > Why twice?

My fault! I also forgot shin!

   >> + ("." ?.)  ; Stop

   > Why do you need this identity mapping?

   >> + ("[" ?\])  ; mirroring
   >> + ("]" ?\[)  ; mirroring
   >> + ("(" ?\))  ; mirroring
   >> + (")" ?\()  ; mirroring
   >> + ("{" ?})  ; mirroring
   >> + ("}" ?{)  ; mirroring
   >> + ("<" ?>)  ; mirroring
   >> + (">" ?<)  ; mirroring

Well this I just copied from other layout found in the hebrew.el
file. If it is not necessary we can delete it.
   > What about / and \ ?

Now I am not sure that it is really needed.

Uwe 



Footnotes:
[1]  I wounder whether it was Eliezer Ben-Yehuda himself who invented
     it. :-D


[-- Attachment #1.2: hebrew-phonetic --]
[-- Type: application/octet-stream, Size: 264 bytes --]

a א
b ב
c צ
d ד
e א
f פ
g ג
h ה
i י
j י
k כ
l ל
m מ
n נ
o ס
p פ
q ק
r ר
s ש
t ת
u ו
v ו
w ו
x ח
y ע
z ז
  
A א
B ב
C צ
D ד
E א
F ף
G ג
H ה
I י
J י
K ך
L ל
M ם
N ן
O ס
P ף
Q ק
R ר
S ש
T ט
U ו
V ו
W ו
X ח
Y ע
Z ז


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

a strict visual cursor in r2l and l2r buffers (was: some progress)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]


Hi

This is a slightly different issue. Would it be possible to implement a
strict visual[1] cursor for buffers containing  R2L and L2R  text??

As far as I can see Lyx and openoffice don't provide it. I am not sure
but maybe old GNU emacs 19.34 (with the mule patch) had it.

Uwe Brauer 


Footnotes:
[1]  when ever I hit left arrow, the cursor moves left, independent of
     the R2L or L2R text.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: a strict visual cursor in r2l and l2r buffers (was: some progress)

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 22 Jun 2013 19:09:27 +0200
> 
> This is a slightly different issue. Would it be possible to implement a
> strict visual[1] cursor for buffers containing  R2L and L2R  text??

It's possible, just not trivial.  Patches are welcome.

Re: a strict visual cursor in r2l and l2r buffers

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:



   >> This is a slightly different issue. Would it be possible to
   >> implement a strict visual[1] cursor for buffers containing R2L and
   >> L2R text??

   > It's possible, just not trivial.  Patches are welcome.
Lisp or C?

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sun, 23 Jun 2013 18:22:49 +0200
> 
>    >> This is a slightly different issue. Would it be possible to
>    >> implement a strict visual[1] cursor for buffers containing R2L and
>    >> L2R text??
> 
>    > It's possible, just not trivial.  Patches are welcome.
> Lisp or C?

Whatever you like (although I think doing this is Lisp will be very
inelegant, if not next to impossible).

Re: a strict visual cursor in r2l and l2r buffers

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 421 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
   >> 
   >> > It's possible, just not trivial.  Patches are welcome.
   >> Lisp or C?

   > Whatever you like (although I think doing this is Lisp will be very
   > inelegant, if not next to impossible).

Oops unfortunately  my C knowledge is not very deep and I asked to see
whether it could be done in lisp, the your answer seems to indicate:
impracticable.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sun, 23 Jun 2013 21:43:33 +0200
> 
>    >> Lisp or C?
> 
>    > Whatever you like (although I think doing this is Lisp will be very
>    > inelegant, if not next to impossible).
> 
> Oops unfortunately  my C knowledge is not very deep and I asked to see
> whether it could be done in lisp, the your answer seems to indicate:
> impracticable.

Don't let my opinions discourage you: I could be wrong.  If you find a
good way to solve this in Lisp, by all means propose it.

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sun, 23 Jun 2013 21:43:33 +0200
> 
>    >> > It's possible, just not trivial.  Patches are welcome.
>    >> Lisp or C?
> 
>    > Whatever you like (although I think doing this is Lisp will be very
>    > inelegant, if not next to impossible).
> 
> Oops unfortunately  my C knowledge is not very deep and I asked to see
> whether it could be done in lisp, the your answer seems to indicate:
> impracticable.

I decided it was high time for Emacs to have visual-order cursor
motion.  So trunk revision 113221 implements that, please try it (by
customizing the new option visual-order-cursor-movement).  When that
option is non-nil, arrow keys will move in strict visual order.  The
feature still has some rough edges in some complicated situations, but
C-f or C-b or C-n/C-p should provide a fire escape in those cases.

And before everybody and their dog run to customize that option, let
me tell you that it will make absolutely no difference, except
unearthing some exciting new bugs, as long as you edit strict
left-to-right text (because in that case, the screen order and the
buffer order coincide).  It only makes sense to customize this option
to a non-nil value if you routinely need to work with bidirectional
text.

Note that text selection is still done in logical order (and should
continue to be so, if you ask me), even when this new option is
non-nil.  Therefore, shifted arrow keys move in visual order, but
select text in logical order, which could cause surprising effects wrt
the highlighted portions of text.  (Microsoft Word disables
visual-order cursor motion if Shift is pressed, but I consider that a
misfeature.)

Enjoy.

Re: a strict visual cursor in r2l and l2r buffers

[Stefan Monnier]

> me tell you that it will make absolutely no difference, except
> unearthing some exciting new bugs, as long as you edit strict
> left-to-right text

Actually, it makes no difference in L2R-only paragraphs and in
R2L-only paragraphs.  It only affects movement when you have mixed R2L
and L2R text in the same paragraph.


        Stefan

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Uwe Brauer <oub@mat.ucm.es>,  emacs-devel@gnu.org
> Date: Sat, 29 Jun 2013 11:17:02 -0400
> 
> > me tell you that it will make absolutely no difference, except
> > unearthing some exciting new bugs, as long as you edit strict
> > left-to-right text
> 
> Actually, it makes no difference in L2R-only paragraphs and in
> R2L-only paragraphs.  It only affects movement when you have mixed R2L
> and L2R text in the same paragraph.

That's true, but R2L-only paragraphs are very rare in real life, which
is why the related scripts are called "bidirectional".  Just type a
digit or two, and see for yourself.

Re: a strict visual cursor in r2l and l2r buffers

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
   >> 
   >> Oops unfortunately  my C knowledge is not very deep and I asked to see
   >> whether it could be done in lisp, the your answer seems to indicate:
   >> impracticable.

   > I decided it was high time for Emacs to have visual-order cursor
   > motion.  So trunk revision 113221 implements that, please try it
   > (by customizing the new option visual-order-cursor-movement).  When
   > that option is non-nil, arrow keys will move in strict visual
   > order.  The feature still has some rough edges in some complicated
   > situations, but C-f or C-b or C-n/C-p should provide a fire escape
   > in those cases.

Very cool, thanks a lot. I will test it immediately. 

The relevant command
for obtaining  the trunk version  is 

bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk

Isn't it[1]?

The server seems to be down or my connection too slow 
I obtain 
bzr.savannah.gnu.org:4155: Connection timed out


Footnotes:
[1]  most emacs pkg projects use git, Xemacs uses mercury and GNU emacs
     uses bzr...


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 29 Jun 2013 18:10:33 +0200
> 
> The relevant command
> for obtaining  the trunk version  is 
> 
> bzr branch bzr://bzr.savannah.gnu.org/emacs/trunk
> 
> Isn't it[1]?

Yes, if you didn't already have a prior checkout of the trunk.

> The server seems to be down or my connection too slow 
> I obtain 
> bzr.savannah.gnu.org:4155: Connection timed out

After how much time did you get the timeout?

Re: a strict visual cursor in r2l and l2r buffers

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


   > Yes, if you didn't already have a prior checkout of the trunk.

   >> The server seems to be down or my connection too slow 
   >> I obtain 
   >> bzr.savannah.gnu.org:4155: Connection timed out

   > After how much time did you get the timeout?

30 sec aprox.

I also tried git, although I am not sure that I get the trunk there 

git clone git://git.savannah.gnu.org/emacs.git

Same behavior.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 29 Jun 2013 19:04:30 +0200
> 
>    >> The server seems to be down or my connection too slow 
>    >> I obtain 
>    >> bzr.savannah.gnu.org:4155: Connection timed out
> 
>    > After how much time did you get the timeout?
> 
> 30 sec aprox.
> 
> I also tried git, although I am not sure that I get the trunk there 
> 
> git clone git://git.savannah.gnu.org/emacs.git
> 
> Same behavior.

Strange, I see no problems whatsoever accessing Savannah.

Re: a strict visual cursor in r2l and l2r buffers

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 970 bytes --]

>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:


   > Strange, I see no problems whatsoever accessing Savannah.


Good and bad news:

Good: I finally could download the trunk form another
place. I think I did my homework in installing all the necessary tools
on this machine (that is not the one where I compiled the official emacs
24 version). I installed automake and autoconf, and run 
(I am on Kubuntu)

sudo apt-get build-dep emacs 

./configure went through. 


Bad: 

Make broke down with the following error

Loading macroexp.elc...
Wrong type argument: number-or-marker-p, nil
make[2]: ***
[/home/oub/ALLES/Add-Import/Soft/trunk/lisp/calendar/cal-loaddefs.el]
Error 255 
make[2]: Leaving directory `/home/oub/ALLES/Add-Import/Soft/trunk/lisp'
make[1]: ***
[/home/oub/ALLES/Add-Import/Soft/trunk/src/../lisp/loaddefs.el] Error 2 
make[1]: Leaving directory `/home/oub/ALLES/Add-Import/Soft/trunk/src'
make: *** [src] Error 2


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5556 bytes --]

Re: a strict visual cursor in r2l and l2r buffers

[Eli Zaretskii]

> From: Uwe Brauer <oub@mat.ucm.es>
> Cc: emacs-devel@gnu.org
> Date: Sat, 29 Jun 2013 21:33:44 +0200
> 
> Bad: 
> 
> Make broke down with the following error
> 
> Loading macroexp.elc...
> Wrong type argument: number-or-marker-p, nil
> make[2]: ***
> [/home/oub/ALLES/Add-Import/Soft/trunk/lisp/calendar/cal-loaddefs.el]
> Error 255 
> make[2]: Leaving directory `/home/oub/ALLES/Add-Import/Soft/trunk/lisp'
> make[1]: ***
> [/home/oub/ALLES/Add-Import/Soft/trunk/src/../lisp/loaddefs.el] Error 2 
> make[1]: Leaving directory `/home/oub/ALLES/Add-Import/Soft/trunk/src'
> make: *** [src] Error 2

Yes, I just reported that a few minutes ago.  I hope it will be fixed
soon enough.