From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: bidi-display-reordering is now non-nil by default Date: Sat, 06 Aug 2011 19:17:44 +0300 Message-ID: <83aabmwm3b.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1312647599 31374 80.91.229.12 (6 Aug 2011 16:19:59 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 6 Aug 2011 16:19:59 +0000 (UTC) Cc: cyd@stupidchicken.com, list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org To: Lars Magne Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 06 18:19:54 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 1QpjbM-0004qC-UJ for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 18:19:53 +0200 Original-Received: from localhost ([::1]:53405 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpjbM-0006SU-Dp for ged-emacs-devel@m.gmane.org; Sat, 06 Aug 2011 12:19:52 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:37728) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpjbJ-0006Rj-JL for emacs-devel@gnu.org; Sat, 06 Aug 2011 12:19:50 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QpjbF-00007Z-KA for emacs-devel@gnu.org; Sat, 06 Aug 2011 12:19:49 -0400 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:44601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QpjbF-00007U-C3 for emacs-devel@gnu.org; Sat, 06 Aug 2011 12:19:45 -0400 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0LPI00J00L93WK00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 06 Aug 2011 19:19:43 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.94.185]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LPI00J3WLCTQCB0@a-mtaout23.012.net.il>; Sat, 06 Aug 2011 19:19:43 +0300 (IDT) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.175 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:142935 Archived-At: > From: Lars Magne Ingebrigtsen > Cc: Eli Zaretskii , list-general@mohsen.1.banan.byname.net, emacs-devel@gnu.org > Date: Sat, 06 Aug 2011 17:51:51 +0200 > > Basically, people compose their own summary lines. Even if we do what > Eli suggests, and default to putting in directional characters by > default, this won't really help the people who have customised their > summary buffers. Sorry, I don't understand. Please tell the details. You are talking to a man who doesn't use Gnus. What kinds of customizations are you talking about? > Take the default "from" spec, which is this: "%-23,23f". This means > "pad to 23 characters, and chop off bits that are longer than 23 > characters". The "from" is available in a dynamic variable that's > inserted in the buffer by the format-spec machinery. If I pad the > "from" with segmentation charaters at the start and end, so that > `gnus-tmp-from' becomes "\200Lars Lalala Ingebrigtsen\200", the last > directional character will be chopped off, and the bidi machinery will > wreak havoc with the characters that come afterwards. We need to add the directional characters after formatting. Or modify the ``format-spec machinery'', whatever that is, to remove characters in-between, but not the directional marks themselves, or to insert the marks as part of the formatting in the first place. If none of that can fix the problem, please tell the details of why not. > So, how would I solve this conundrum? I'd use text properties. :-) > > That is, Gnus would propertise `gnus-tmp-from' with `line-segment' > `from'. The rendering engine could then look at line segments > (i.e. consecutive ranges of characters with identical `line-segment' > text props) and do the bidi thing on each segment separately. This is a non-starter: as I explained elsewhere in this thread, the reordering code completely ignores text properties. It just finds the next character to display; the properties are thereafter considered by the code that calls the reordering engine.