Proposing Addition of a BIDI SubMenu to "Options"

Proposing Addition of a BIDI SubMenu to "Options"

[Mohsen BANAN]

Particularly in the beginning (after release of
emacs24), I think bidi users would want/need to
change reordering and paragraph directionality
often in various buffers.

I think it is a good idea to make that easy for
novice users who may not like (setq) very much.

The code below is what I have been using to create
a "BIDI" menu for Perso-Arabic BLEE users. (BLEE
is ByStar's Emacs User Environment)

I am proposing that something like this be added
to the Options Menu -- Perhaps right after Mule.

In addittion to English, I think it would be kool
for the menu items to also be in Hebrew, Arabic
and Persian. I have included starting point
Persian text below.

As a bidi user, I often use these. So, I really
think something like this would be useful.

If this is a worthwhile suggestion, how will we be
making it happen?

Thanks.

...Mohsen


--- bystar-bidi-menu.el begins: ---

;;;
;;;

(require 'easymenu)

;;;
;;; Global BIDI Menu
;;;

;; (blee:blee:menu)
;; (bystar:bidi-global:menu)
(defun bystar:bidi-global:menu ()
  (easy-menu-define 
    bidi-menu 
    nil 
    "Global BIDI Menu"
    '("Bi-Directional -- BIDI"
      "---"
      ["يک طرفه -- reordering off" bidi-display-reordering-off t]
      ["دو طرفه -- reordering on" bidi-display-reordering-on t]
      ["کدام طرف؟ --  current reordering show" bidi-display-reordering-show t]
      "---"
      ["چپ به راست -- paragraph left-to-right" bidi-paragraph-direction-left-to-right t]
      ["راست به چپ -- paragraph right-to-left" bidi-paragraph-direction-right-to-left t]
      ["خودبه خود -- paragraph auto-detect" bidi-paragraph-direction-auto-detect t]
      ["کدام جهت؟ -- current paragraph direction" bidi-paragraph-direction-current t]
       ))
  )


;; (bidi-display-reordering-on)
(defun bidi-display-reordering-on ()
  (interactive)
  (setq bidi-display-reordering t)
  (recenter)
  )

;; (bidi-display-reordering-off)
(defun bidi-display-reordering-off ()
  (interactive)
  (setq bidi-display-reordering nil)
  (recenter)
  )

;; (bidi-display-reordering-show)
(defun bidi-display-reordering-show ()
  (interactive)
  (describe-variable 'bidi-display-reordering)
  )


;; (bidi-paragraph-direction-right-to-left)
(defun bidi-paragraph-direction-right-to-left ()
  (interactive)
  (setq bidi-paragraph-direction 'right-to-left)
  (recenter)
  )

;; (bidi-paragraph-direction-left-to-right)
(defun bidi-paragraph-direction-left-to-right ()
  (interactive)
  (setq bidi-paragraph-direction 'left-to-right)
  (recenter)
  )


;; (bidi-paragraph-direction-auto-detect)
(defun bidi-paragraph-direction-auto-detect ()
  (interactive)
  (setq bidi-paragraph-direction nil)
  (recenter)
  )

;; (bidi-paragraph-direction-current)
(defun bidi-paragraph-direction-current ()
  (interactive)
  (describe-variable 'bidi-paragraph-direction)
  ;;(current-bidi-paragraph-direction)
  )



(provide 'bystar-bidi-menu)

--- bystar-bidi-menu.el ends: ---

Re: Proposing Addition of a BIDI SubMenu to "Options"

[Eli Zaretskii]

> From: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>
> Date: Tue, 02 Aug 2011 20:37:57 -0700
> 
> 
> I am proposing that something like this be added
> to the Options Menu -- Perhaps right after Mule.

Thanks.

I object to exposing bidi-display-reordering to the user level.  It is
no accident that I didn't make it a user option (unlike
bidi-paragraph-direction).  There should be no reason for users to
change this variable, at least not conveniently.

As for the rest, what you suggest is a beginning, but it should
include more.  For example, a command to make the current paragraph
(and only the current paragraph) L2R resp R2L, a command to enclose a
portion of text into a directional embedding, with or without
directional override, etc.  We don't want users to be experts in the
UBA to edit bidirectional text conveniently.

The challenge is to come up with a good UI for these features.
IMNSHO, a menu item that just sets a variable is largely missing the
point in this respect, because setting a variable is the easy part of
this stuff.

> In addittion to English, I think it would be kool
> for the menu items to also be in Hebrew, Arabic
> and Persian. I have included starting point
> Persian text below.

That already works in most toolkits (all of those I tried, but I don't
have access to all of the supported ones).  But what you are trying to
do is start a localization of the Emacs UI, not just display
bidirectional text in a menu item.  That is a much larger issue, and
it cannot be sneaked in just for some scripts and languages.  It must
be part of some larger framework.

For example, even if we consider just the R2L languages, we should
allow to customize the UI so that the menu-bar items and the tool-bar
buttons, as well as the mode line, display starting at the right
margin of the frame, like other applications do.

And there are more issues to tackle, as significant portions of the
Emacs UI are implemented as text inserted into buffers (e.g.,
Customize, Dired, etc.).  Making all this localizable is a large job,
but it cannot be bypassed.

Re: Proposing Addition of a BIDI SubMenu to "Options"

[Mohsen BANAN]

My intent in initiating this thread was just to
get a bidi submenu started.

What would go into that menu can evolve.

UIs are always the sort of thing that need
iteration and profit from usage feedback.

So, if you and others agree that this is a good
time to put in place a starting point, then let's
do it. 

If you think it is too soon, then we wait.

We can start with something very simple.
Once the menu file is part of emacs24 trunk, we
can make it be better and grow.

I fully recognize that my file was not anything
other than a very simple starting point.

Some more notes are included in-line below.

>>>>> On Wed, 03 Aug 2011 05:24:58 -0400, Eli Zaretskii <eliz@gnu.org> said:

  >> From: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>
  >> Date: Tue, 02 Aug 2011 20:37:57 -0700
  >> 
  >> 
  >> I am proposing that something like this be added
  >> to the Options Menu -- Perhaps right after Mule.

  Eli> Thanks.

  Eli> I object to exposing bidi-display-reordering to the user level.  It is
  Eli> no accident that I didn't make it a user option (unlike
  Eli> bidi-paragraph-direction).  There should be no reason for users to
  Eli> change this variable, at least not conveniently.

In theory I agree.

In practice I catch myself using that menu item.

  Eli> As for the rest, what you suggest is a beginning, but it should
  Eli> include more.  For example, a command to make the current paragraph
  Eli> (and only the current paragraph) L2R resp R2L, a command to enclose a
  Eli> portion of text into a directional embedding, with or without
  Eli> directional override, etc.  We don't want users to be experts in the
  Eli> UBA to edit bidirectional text conveniently.

Agreed.

Those features make great sense.

  >> In addittion to English, I think it would be kool
  >> for the menu items to also be in Hebrew, Arabic
  >> and Persian. I have included starting point
  >> Persian text below.

  Eli> That already works in most toolkits (all of those I tried, but I don't
  Eli> have access to all of the supported ones).  But what you are trying to
  Eli> do is start a localization of the Emacs UI, not just display
  Eli> bidirectional text in a menu item.  That is a much larger issue, and
  Eli> it cannot be sneaked in just for some scripts and languages.  It must
  Eli> be part of some larger framework.

  Eli> For example, even if we consider just the R2L languages, we should
  Eli> allow to customize the UI so that the menu-bar items and the tool-bar
  Eli> buttons, as well as the mode line, display starting at the right
  Eli> margin of the frame, like other applications do.

  Eli> And there are more issues to tackle, as significant portions of the
  Eli> Emacs UI are implemented as text inserted into buffers (e.g.,
  Eli> Customize, Dired, etc.).  Making all this localizable is a large job,
  Eli> but it cannot be bypassed.

You are very right.

At somepoint we need to create an entire framework
for internationalization of emacs.

My intent in adding a few sprinkles of Farsi into
those menus was different.

I am thinking that bidi can open the door to lots
of new users. It could be the sole reason why
someone uses emacs. Because it is the best bidi
editor in the world -- bar none.

So, I thought in the spirit of promoting, we would
just include a few sprinkles of Hebrew, Arabic and
Persian in bidi menus. 

More philosophically speaking, I believe to win
the Proprietary vs Non-Proprietary tussle, we need
to crisply identify the tear points and focus on
the tear points. 

I believe there are two tear points.

  1) Markets and economic models in which
     proprietary software and proprietary services
     are less competetive. For example the
     Perso-Arabic market.

  2) Creation of Software-Service continuums.

So, the idea of including Hebrew, Arabic and
Persian in bidi menus was just in the spirit of
marketing emacs.

Thanks.

...Mohsen

Re: Proposing Addition of a BIDI SubMenu to "Options"

[Eli Zaretskii]

> From: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>
> Cc: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>,  emacs-devel@gnu.org
> Date: Wed, 03 Aug 2011 11:23:09 -0700
> 
> So, if you and others agree that this is a good
> time to put in place a starting point, then let's
> do it. 
> 
> If you think it is too soon, then we wait.

It's not too soon, although we must be cautious not to introduce too
many new features, as the pretest is close.

>   Eli> I object to exposing bidi-display-reordering to the user level.  It is
>   Eli> no accident that I didn't make it a user option (unlike
>   Eli> bidi-paragraph-direction).  There should be no reason for users to
>   Eli> change this variable, at least not conveniently.
> 
> In theory I agree.
> 
> In practice I catch myself using that menu item.

Because there are still bugs, and when we see a potential bug, we want
to check if it's due to bidi.  That's specific to development.  But
the menu bar is for the users, not for developers.