Eli Zaretskii | 15 Jul 09:22
Picon

Hebrew tutorial

Is anyone working on this, per chance?
Eli Zaretskii | 31 Jul 18:53
Picon

Re: Hebrew tutorial

> Date: Thu, 15 Jul 2010 10:22:49 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Is anyone working on this, per chance?

No one responded, so I did this myself.  It's in the repository now;
suggestions for improvements and corrections are welcome.

If you want to read it _as_ a tutorial (with "C-h t"), then you will
need for now to manually set bidi-display-reordering non-nil, because
"C-h t" currently doesn't honor file-local variables -- something to
be fixed in the near future.

(I wrote the entire tutorial in Emacs, and found the level of support
we have now quite satisfactory, even in a few cases where I needed to
use the bidi formatting control characters to get the text to display
like I wanted.  I also discovered a couple of minor bugs, which I will
fix soon.)
Yair F | 2 Aug 00:04
Picon

Re: Re: Hebrew tutorial

Some small comments.

1. LRM and RLM are visible in text they look like dirt. It is an emacs  bug.
2 The section "NOTICE: The main purpose of the Emacs tutorial is to teach you
 the most important standard Emacs commands (key bindings)."
 etc. is not localized. I believe this is a bug as well.
3. Please use the Hebrew Maqaf instead of hyphen.
4. Please try to avoid the acronyms instead of  ש-ע"ג (why the
hyphen?) write שעל גבי.
5. About Copyright section I would suggest that you look at
the GPL translation by Adv. Haim Ravia available here:
http://www.law.co.il/computer-law/free-software/2007/07/13/gpl-3-hebrew-translation/

Yair
Eli Zaretskii | 2 Aug 05:03
Picon

Re: Re: Hebrew tutorial

> Date: Mon, 2 Aug 2010 01:04:05 +0300
> From: Yair F <yair.f.lists <at> gmail.com>
> Cc: emacs-bidi <at> gnu.org
> 
> Some small comments.

Thanks.

> 1. LRM and RLM are visible in text they look like dirt. It is an emacs  bug.

Yes.  Handa-san tells me that there should eventually be rules to
compose them with the next character, so they will become invisible.
But this is not set up yet.

> 2 The section "NOTICE: The main purpose of the Emacs tutorial is to teach you
>  the most important standard Emacs commands (key bindings)."
>  etc. is not localized. I believe this is a bug as well.

This is inserted by tutorial.el, and it is in English in all the
tutorials.

> 3. Please use the Hebrew Maqaf instead of hyphen.

Why? what's wrong with the hyphen?

> ש-ע"ג (why the hyphen?)

This is how you are supposed to write acronyms preceded by articles.
If you write שע"ג, it could be interpreted as a 3-letter acronym,
which it isn't.
(Continue reading)

Eli Zaretskii | 2 Aug 19:56
Picon

Re: Re: Hebrew tutorial

> Date: Mon, 02 Aug 2010 06:03:06 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: emacs-bidi <at> gnu.org
> 
> > 2 The section "NOTICE: The main purpose of the Emacs tutorial is to teach you
> >  the most important standard Emacs commands (key bindings)."
> >  etc. is not localized. I believe this is a bug as well.
> 
> This is inserted by tutorial.el, and it is in English in all the
> tutorials.

Just to make my intent clear: if someone wants to enhance tutorial.el
so that it could insert translated versions of this text, please feel
free.
Yair F | 2 Aug 23:08
Picon

Re: Re: Hebrew tutorial

On Mon, Aug 2, 2010 at 6:03 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

>> 2 The section "NOTICE: The main purpose of the Emacs tutorial is to teach you
>>  the most important standard Emacs commands (key bindings)."
>>  etc. is not localized. I believe this is a bug as well.
>
> This is inserted by tutorial.el, and it is in English in all the
> tutorials.
>
The it is a bug not-specific to  Hebrew. :)

>> 3. Please use the Hebrew Maqaf instead of hyphen.
>
> Why? what's wrong with the hyphen?

Despite what most of us have been accustomed in the last 30 years,
hyphen is foreign
to the Hebrew language. Take another look at the newspapers or books published
by serious publishers.

> This is how you are supposed to write acronyms preceded by articles.
> If you write שע"ג, it could be interpreted as a 3-letter acronym,
> which it isn't.

Let's just settle on not using acronyms then. :)
Eli Zaretskii | 7 Aug 11:57
Picon

Re: Re: Hebrew tutorial

> Date: Mon, 2 Aug 2010 01:04:05 +0300
> From: Yair F <yair.f.lists <at> gmail.com>
> Cc: emacs-bidi <at> gnu.org
> 
> 3. Please use the Hebrew Maqaf instead of hyphen.

I tried that, but the results look ugly, at least on MS-Windows: the
Maqaf is composed with the preceding character and almost entirely
blends with it as result of this composition.  Is this something
specific to the Windows Uniscribe engine?  Is this an Emacs bug?

Anyway, until this is fixed, if possible, I don't think we should use
Maqaf in the tutorial.

> 4. Please try to avoid the acronyms instead of  ש-ע"ג (why the
> hyphen?) write שעל גבי.

I removed all of the acronyms, with the single exception of ע"י, which
I think is very common in modern Hebrew texts.

Thanks again for your comments.
Amit Ramon | 8 Aug 22:25
Picon

Re: Re: Hebrew tutorial

Eli Zaretskii <eliz <at> gnu.org> [2010-08-07 12:57 +0300]:

>> 3. Please use the Hebrew Maqaf instead of hyphen.
>
>I tried that, but the results look ugly, at least on MS-Windows: the
>Maqaf is composed with the preceding character and almost entirely
>blends with it as result of this composition.  Is this something
>specific to the Windows Uniscribe engine?  Is this an Emacs bug?

I think this is a (new) bug. I can see it on Linux/X, and it was
working fine until about a month ago. I reported it on the emacs-devel
list.

In principle Yair is right - in Hebrew maqaf is used to join words,
not a hyphen.
Yair F | 9 Aug 12:59
Picon

Re: Re: Hebrew tutorial

On Sun, Aug 8, 2010 at 11:25 PM, Amit Ramon <amit.ramon <at> gmail.com> wrote:
> I think this is a (new) bug. I can see it on Linux/X, and it was
> working fine until about a month ago. I reported it on the emacs-devel
> list.

It is a bug in composition rules. Until the composition picture would
be clearer I will try to create
a simple patch that won't suffer from this problem later this evening.
Kenichi Handa | 9 Aug 13:09

Re: Re: Hebrew tutorial

In article <8362zmwxru.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> > 3. Please use the Hebrew Maqaf instead of hyphen.

> I tried that, but the results look ugly, at least on MS-Windows: the
> Maqaf is composed with the preceding character and almost entirely
> blends with it as result of this composition.  Is this something
> specific to the Windows Uniscribe engine?  Is this an Emacs bug?

It's an Emacs bug.  I've just committed a fix.

---
Kenichi Handa
handa <at> m17n.org
Yair F | 9 Aug 20:15
Picon

Re: Re: Hebrew tutorial

On Mon, Aug 9, 2010 at 2:09 PM, Kenichi Handa <handa <at> m17n.org> wrote:
> In article <8362zmwxru.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
>> > 3. Please use the Hebrew Maqaf instead of hyphen.
>
>> I tried that, but the results look ugly, at least on MS-Windows: the
>> Maqaf is composed with the preceding character and almost entirely
>> blends with it as result of this composition.  Is this something
>> specific to the Windows Uniscribe engine?  Is this an Emacs bug?
>
> It's an Emacs bug.  I've just committed a fix.
>

Thank you, it is working correctly now.

05C3 (Sof Pasuq) is also non-composable character. Please fix it as well.

Also, when trying to replace the dash character with Maqaf using
M-% in the toutorial, the cursor (notifying point) is not always
positioned in the correct place, the replacement is correctly
highlighted using font-lock.
Kenichi Handa | 10 Aug 03:36

Re: Re: Hebrew tutorial

In article <AANLkTiktPE6a9GHPbf5U+nZ-56oQ_Hu_a6ozDBiR3OgR <at> mail.gmail.com>, Yair F
<yair.f.lists <at> gmail.com> writes:

> 05C3 (Sof Pasuq) is also non-composable character. Please fix it as well.

Just done.

> Also, when trying to replace the dash character with Maqaf using
> M-% in the toutorial, the cursor (notifying point) is not always
> positioned in the correct place, the replacement is correctly
> highlighted using font-lock.

In isearch too, the cursor is positioned (logically) after
the matched text.  The problem is that, in BIDI text, that
position may be far from the matched text on screen.

By the way, in M-% (query-replace), the "notifying point" is
not the cursor, but the region highlighted by the face
`isearch' (the default is lightskyblue1 on magenta3).  So,
perhaps, it may be better to hide cursor in query-replace.

---
Kenichi Handa
handa <at> m17n.org
Eli Zaretskii | 14 Aug 10:57
Picon

Re: Re: Hebrew tutorial

> Date: Mon, 9 Aug 2010 21:15:41 +0300
> From: Yair F <yair.f.lists <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, emacs-bidi <at> gnu.org
> 
> On Mon, Aug 9, 2010 at 2:09 PM, Kenichi Handa <handa <at> m17n.org> wrote:
> > In article <8362zmwxru.fsf <at> gnu.org>, Eli Zaretskii <eliz <at> gnu.org> writes:
> >> > 3. Please use the Hebrew Maqaf instead of hyphen.
> >
> >> I tried that, but the results look ugly, at least on MS-Windows: the
> >> Maqaf is composed with the preceding character and almost entirely
> >> blends with it as result of this composition.  Is this something
> >> specific to the Windows Uniscribe engine?  Is this an Emacs bug?
> >
> > It's an Emacs bug.  I've just committed a fix.
> >
> 
> Thank you, it is working correctly now.

For me as well.  I now replaced some of the hyphens with a Maqaf.

> Also, when trying to replace the dash character with Maqaf using
> M-% in the toutorial, the cursor (notifying point) is not always
> positioned in the correct place, the replacement is correctly
> highlighted using font-lock.

This is normal.  As Handa-san pointed out, cursor position is before
the _next_ character _in_the_logical_order_.  It could be a bit
confusing when the search string ends between level runs, but the same
is true for cursor position outside I-search as well.  So if we want
to fix that in some way, we need to fix it in general cursor
(Continue reading)

Larry Denenberg | 18 Aug 06:12

Re: Re: Hebrew tutorial


>As Handa-san pointed out, cursor position is before the _next_
>character _in_the_logical_order_.

Could you clarify this a little for us relative newcomers?

Suppose I type אבגדה in a RTL context and then C-b twice.  Point is now
between ג and ד, but the visible cursor is between ד and ה.  Presumably
this is because the cursor is positioned before the ד, as you say, where
"before" means "to the left of" rather than "preceding, according to the
current direction".  This may be consistent, but from the user's point
of view it seems terribly confusing.  So I've been wondering if this is
a known issue or the intended behavior.

Here's another newbie question that's perhaps Aquamacs-specific:  Mouse
clicks seem to be interpreted with respect to a logical, rather than
rendered, version of the buffer.  If I type a line of RTL text and then
click near the beginning of the line (i.e., on the right side of the
display), the cursor gets positioned on the left side of the display,
presumably as close to the end of the line as my click was from the
beginning of the line.  Again, if this is intended it's not clear why,
but perhaps it's a known deficiency or perhaps I'm doing somthing wrong.

/Larry Denenberg
larry <at> denenberg.com
http://larry.denenberg.com/
Eli Zaretskii | 18 Aug 08:09
Picon

Re: Re: Hebrew tutorial

> cc: emacs-bidi <at> gnu.org
> Cc: larry <at> denenberg.com
> From: Larry Denenberg <larry <at> denenberg.com>
> Date: Wed, 18 Aug 2010 07:12:21 +0300
> 
> Suppose I type אבגדה in a RTL context and then C-b twice.  Point is now
> between ג and ד, but the visible cursor is between ד and ה.

What do you mean by "between"? are you using a bar cursor, by any
chance?  The default block cursor is put _on_ a character, so there's
no "between".  In the case you describe, the block cursor should be on ד.
Does that work for you?

If the problem is with the bar cursor, then it could be a bug; I don't
think I did anything special yet for the bar cursor in RTL context.  I
will have a look when I have time.

> Here's another newbie question that's perhaps Aquamacs-specific:  Mouse
> clicks seem to be interpreted with respect to a logical, rather than
> rendered, version of the buffer.  If I type a line of RTL text and then
> click near the beginning of the line (i.e., on the right side of the
> display), the cursor gets positioned on the left side of the display,
> presumably as close to the end of the line as my click was from the
> beginning of the line.  Again, if this is intended it's not clear why,
> but perhaps it's a known deficiency or perhaps I'm doing somthing wrong.

Sounds like a bug, I will take a look.
Larry Denenberg | 18 Aug 17:56

Re: Re: Hebrew tutorial


>> Suppose I type אבגדה in a RTL context and then C-b twice.  Point is now
>> between ג and ד, but the visible cursor is between ד and ה.
>
>What do you mean by "between"? are you using a bar cursor, by any
>chance?  The default block cursor is put _on_ a character, so there's
>no "between".

Indeed I am; Aquamacs uses a bar cursor by default (set in aquamacs.el).
This cursor is helpful and intuitive since it accurately reflects the
position of point---except in RTL mode, where things are confusing.
Here's another example: the plain ol' delete-backward-char command
currently deletes a character not touching the cursor!

I agree that using a block cursor mitigates the problem, but I still
think this issue should be addressed.

/Larry Denenberg
larry <at> denenberg.com
http://larry.denenberg.com/
Eli Zaretskii | 18 Aug 18:47
Picon

Re: Re: Hebrew tutorial

> cc: Larry Denenberg <larry <at> denenberg.com>, emacs-bidi <at> gnu.org
> From: Larry Denenberg <larry <at> denenberg.com>
> Date: Wed, 18 Aug 2010 18:56:45 +0300
> 
> 
> Indeed I am; Aquamacs uses a bar cursor by default (set in aquamacs.el).
> This cursor is helpful and intuitive since it accurately reflects the
> position of point---except in RTL mode, where things are confusing.
> Here's another example: the plain ol' delete-backward-char command
> currently deletes a character not touching the cursor!
> 
> I agree that using a block cursor mitigates the problem, but I still
> think this issue should be addressed.

I just fixed this (but I don't know when will Aquamacs get these
fixes).

Thanks.
Eli Zaretskii | 18 Aug 18:45
Picon

Re: Re: Hebrew tutorial

> From: Eli Zaretskii <eliz <at> gnu.org>
> Date: Wed, 18 Aug 2010 02:09:00 -0400
> Cc: emacs-bidi <at> gnu.org
> 
> If the problem is with the bar cursor, then it could be a bug; I don't
> think I did anything special yet for the bar cursor in RTL context.  I
> will have a look when I have time.

It was indeed a bug with a bar cursor.  Now fixed, but not yet on NS,
let alone Aquamacs.

> > Here's another newbie question that's perhaps Aquamacs-specific:  Mouse
> > clicks seem to be interpreted with respect to a logical, rather than
> > rendered, version of the buffer.  If I type a line of RTL text and then
> > click near the beginning of the line (i.e., on the right side of the
> > display), the cursor gets positioned on the left side of the display,
> > presumably as close to the end of the line as my click was from the
> > beginning of the line.  Again, if this is intended it's not clear why,
> > but perhaps it's a known deficiency or perhaps I'm doing somthing wrong.
> 
> Sounds like a bug, I will take a look.

This is also a bug, I will work on it soon.

Thanks for reporting these issues.
Eli Zaretskii | 20 Aug 16:35
Picon

Re: Re: Hebrew tutorial

> Date: Wed, 18 Aug 2010 19:45:06 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 
> 
> > > Here's another newbie question that's perhaps Aquamacs-specific:  Mouse
> > > clicks seem to be interpreted with respect to a logical, rather than
> > > rendered, version of the buffer.  If I type a line of RTL text and then
> > > click near the beginning of the line (i.e., on the right side of the
> > > display), the cursor gets positioned on the left side of the display,
> > > presumably as close to the end of the line as my click was from the
> > > beginning of the line.  Again, if this is intended it's not clear why,
> > > but perhaps it's a known deficiency or perhaps I'm doing somthing wrong.
> > 
> > Sounds like a bug, I will take a look.
> 
> This is also a bug, I will work on it soon.

This tricky bug is also fixed now.  Fixing it was 3 lines of code and
10 lines of commentary explaining why those 3 lines were needed.

Thanks again for pointing out these problems.

Gmane