From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mohsen BANAN Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Sat, 06 Aug 2011 12:21:17 -0700 Organization: ByStar Federation of Autonomous Libre Services -- http://www.by-star.net Message-ID: References: <878vre95g3.fsf@fencepost.gnu.org> <87fwlm7fam.fsf@fencepost.gnu.org> <87bowa7dza.fsf@fencepost.gnu.org> <877h6y7chn.fsf@fencepost.gnu.org> <831ux6cv5o.fsf@gnu.org> <87d3gpku3o.fsf@gnus.org> <834o1ypa2b.fsf@gnu.org> <87aabnn3mz.fsf@stupidchicken.com> <83mxfnwwyd.fsf@gnu.org> <87ipqbzogt.fsf@stupidchicken.com> <83liv7wqhe.fsf@gnu.org> <87liv75xsh.fsf@stupidchicken.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1312658497 26488 80.91.229.12 (6 Aug 2011 19:21:37 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 19:21:37 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, larsi@gnus.org, list-general@mohsen.1.banan.byname.net To: Chong Yidong Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 21:21:31 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QpmR7-0004gq-Rm for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 21:21:30 +0200 Original-Received: from localhost ([::1]:54297 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpmR6-0004Oq-Jf for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 15:21:28 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50966) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpmR3-0004Oa-Q7 for emacs-devel@gnu.org; Sat, 06 Aug 2011 15:21:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpmR2-0006wR-JG for emacs-devel@gnu.org; Sat, 06 Aug 2011 15:21:25 -0400 Original-Received: from 0016.bacs.by-star.net ([198.62.92.166]:45394) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QpmR2-0006w9-25 for emacs-devel@gnu.org; Sat, 06 Aug 2011 15:21:24 -0400 Original-Received: (qmail 17012 invoked from network); 6 Aug 2011 12:16:12 -0700 Original-Received: from 192.168.0.181 ([192.168.0.181]) by 0016.bacs.by-star.net ([198.62.92.166]) with ESMTP via TCP; 06 Aug 2011 19:16:12 -0000 In-Reply-To: <87liv75xsh.fsf@stupidchicken.com> (Chong Yidong's message of "Fri, 05 Aug 2011 17:54:54 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 198.62.92.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:142941 Archived-At: >>>>> On Fri, 05 Aug 2011 17:54:54 -0400, Chong Yidong said: Chong> Still, it seems better not to change Gnus to proactively insert LRM Chong> characters, but leave it to those users who care to customize it as Chong> necessary. In the default value of gnus-summary-line-format, Chong> "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\n" Chong> the subject (%s) is followed by a newline. If a user wants to change Chong> this to include, say, the article number, that could be done via Chong> "%U%R%z%I%(%[%4L: %-23,23f%]%) %s\u200E%N\n" Chong> This has the advantage of avoiding inserting the insertion of excess LRM Chong> characters by default. The disadvantage, of course, is that it requires Chong> some extra knowledge from users, but we can handle this by adding a note Chong> to the docstring. I am opposed to the direction that you are advocating. Instead of discussing merits of tactics, I want us to first step back and look at where we are and what we are trying to do. The topic at hand is: Making emacs24 packages bidi-aware In a previous message a while back, I attempted to move things towards formulation/articulation of goals, policies and strategies. My hope was that those playing a leadership role would build on that. Permit me to attempt in formulating some policies for making emacs24 packages bidi-aware. A- We make a distinction between receiving/displaying bidi-awareness and sending/originating bidi-awareness. B- We consider displaying bidi-awareness of emacs24 packages more urgent and more important. C- Anytime that an emacs24 package receives bidi-input that results in display problems, we consider that a bug and file a bug report. D- With respect to displaying, at package level we attempt to eliminate bidi specific options. Displaying bidi is viewed as omni-present through emacs. It is not a feature to be opted-in or opted-out -- or require special configuration. E- With respect to originating bidi-awareness, bidi specific options are perfectly reasonable. Now, assuming that the above policies are reasonable, here are the problems that I see with the direction that you advocated: Chong> Still, it seems better not to change Gnus to proactively insert LRM Chong> characters, but leave it to those users who care to customize it as Chong> necessary. In the default value of gnus-summary-line-format, So, 1) You are saying users "who care" must do bidi-specific customization to get bidi-display to work in Gnus. Which conflicts with my (D). 2) You are saying that it is acceptable to not have the LRM for the subject line. In which case when a bidi message arrives display may be messed up (C). Jason pointed to this previously: Jason> Users who get a lot of RTL email may be motivated enough to do that, but Jason> users who seldom get such mail (and what they do get is probably mostly Jason> spam) will still see the muddled up Jason> summary line as a bug. It is not reasonable for us to accept emacs24 to only be working right some of the time. What you suggested, is a neat temporary hack. I already changed mine to: (setq gnus-summary-line-format ":%U%R %B %s %-60=\u200E|%4L |%-20,20f\u200E|%&user-date; \n") And things are lining up better. Thanks. But let's not just aim for temporary hacks. Let's try to eliminate all necessary complexities -- particularly when they require user exposure. Permit me to also suggest some strategies for making emacs24 packages bidi-aware. - We first put on the table several package use cases to bring out problem patterns. Thus far, as usage cases we have: - Gnus Summary mode - mail citations - XML mode -- Michael Duggan'si nfo was great I'd like to suggest a couple more. Bidi ramifications to auctex mode. And perhaps org's todo. I hope to be following up with these soon. - These usage patterns will likely demonstrate a need for something like a bidi-kit.el Where say insertion of LRM/... at string or point or ... gets common code. And also become a facility for bidi-menu.el features that were previously discussed. - Based on something like bidi-kit.el provide some examples so that in situations where the package maintainer is not motivated someone else can take care of moving the package forward towards more bidi-awareness. In other words we need to spread the knowledge for making emacs24 packages bidi-aware. Emacs24 is now in feature freeze stage. What we have is what we have. And with what we have, many bidi-display problems can be properly fixed. It is a matter of doing it. In summary, I am opposed to considering proper display of bidi by packages as an option requiring special configuration. ...Mohsen