unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Mohsen BANAN <list-general@mohsen.1.banan.byname.net>,
	emacs-devel@gnu.org
Subject: Re: Proposing Addition of a BIDI SubMenu to "Options"
Date: Wed, 03 Aug 2011 11:23:09 -0700	[thread overview]
Message-ID: <yx2mxfq1hiq.fsf@mohsen.1.banan.byname.net> (raw)
In-Reply-To: <E1QoXhC-0003lM-4g@fencepost.gnu.org> (Eli Zaretskii's message of "Wed, 03 Aug 2011 05:24:58 -0400")


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



  reply	other threads:[~2011-08-03 18:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-03  3:37 Proposing Addition of a BIDI SubMenu to "Options" Mohsen BANAN
2011-08-03  9:24 ` Eli Zaretskii
2011-08-03 18:23   ` Mohsen BANAN [this message]
2011-08-03 19:33     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yx2mxfq1hiq.fsf@mohsen.1.banan.byname.net \
    --to=list-general@mohsen.1.banan.byname.net \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).