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: Tue, 16 Aug 2011 13:37:19 +0300 Message-ID: <83fwl1tzfk.fsf@gnu.org> References: <4E48D309.6050503@acdlabs.ru> <83hb5jujjs.fsf@gnu.org> <874o1j10zv.fsf@fencepost.gnu.org> <8362lyvcli.fsf@gnu.org> <87fwl2r0l4.fsf@stupidchicken.com> <83zkjatnkz.fsf@gnu.org> <877h6et8oi.fsf@stupidchicken.com> <83vctxua2y.fsf@gnu.org> <8739h1al7f.fsf@fencepost.gnu.org> <83k4adu2r1.fsf@gnu.org> <87ei0l8ykt.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1313491062 30358 80.91.229.12 (16 Aug 2011 10:37:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 16 Aug 2011 10:37:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Aug 16 12:37:37 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 1QtH1c-00056P-Pb for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 12:37:37 +0200 Original-Received: from localhost ([::1]:56004 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtH1c-0006Yu-BV for ged-emacs-devel@m.gmane.org; Tue, 16 Aug 2011 06:37:36 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:52732) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtH1a-0006Yo-3q for emacs-devel@gnu.org; Tue, 16 Aug 2011 06:37:35 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QtH1Y-0001qL-RE for emacs-devel@gnu.org; Tue, 16 Aug 2011 06:37:34 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:44814) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QtH1W-0001pG-Ec; Tue, 16 Aug 2011 06:37:30 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LQ000D00O4G8W00@a-mtaout22.012.net.il>; Tue, 16 Aug 2011 13:37:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.228.171.158]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LQ000BP9O65L3J0@a-mtaout22.012.net.il>; Tue, 16 Aug 2011 13:37:18 +0300 (IDT) In-reply-to: <87ei0l8ykt.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:143302 Archived-At: > From: David Kastrup > Date: Tue, 16 Aug 2011 12:01:22 +0200 > > Eli Zaretskii writes: > > >> From: David Kastrup > >> Date: Tue, 16 Aug 2011 09:07:16 +0200 > >> > >> Eli Zaretskii writes: > >> > >> >> From: Chong Yidong > >> > > >> >> since there is no near-term solution, how bout turning off bidi > >> >> display reordering for prog-mode buffers? > >> > > >> > What for? No one complained about it yet, and leaving it on helps > >> > find bugs and inefficiencies in the bidi display engine. So my vote > >> > is NAY. > >> > >> Sounds like the plan is to make Emacs painful to use for everyone in > >> order to make it a priority for L2R users to solve R2L problems. > > > > If L2R users don't want bidirectional support any place near them, > > You are putting words into my mouth. No, I'm reading what they say loud and clear. > > to the degree that they are unwilling to help make it better at the > > cost of some moderate effort, please tell so now. > > Most users are _unable_ to help. Wrong. They help _a_lot_ by using the display features and reporting bugs. I'm grateful to all of them, because I could never find these problems myself. > We have refrained from enabling features like font-locking by default in > releases until the costs of using them for everyone were under control. Whether or not the bidi display is good enough to hit the street should be an issue near the end of the pretest, which has not even started yet. So raising these claims now is unjustified and premature at best. > Nobody is arguing to remove R2L support. The question is about what > defaults are sensible to put into a release. You have yourself worked > rather hard to make sure that one can have performance comparable to > before by disabling bidi support altogether. The possibility to disable bidi support is a debugging aid, that's all. That is why it is not a user variable. Don't read anything else into that. > Your standard reaction for regressions encountered in connection with > discussions about both performance problems as well as more fine-grained > defaults is threats. Hogwash. My standard reaction to that is fixing every regression that is being reported. Anyone who looks at the bug tracker will see that. When I disagree with suggestions to change the defaults, I explain why. I would expect my opinions and explanations to have some considerable weight, precisely _because_ I'm working on this alone, and therefore know much more about these issues than anyone else here. > I understand that you have invested a large amount of work into R2L > typesetting, and I understand that it is vital for your personal > resources (including your motivation) that others join in the > effort. I have no problems keeping doing this alone. But I need to know that I have the support of the Emacs community in doing so. It is okay to ask questions about the technical solutions that I implement or suggest, or suggest alternatives. But as soon as my _motives_ are questioned, as soon as someone dares to suggest that I'm deliberately putting users through suffering for some personal reasons, that is the sign of lack of support. I will not go on without support. I refuse to work on features that will not be used in a released Emacs, for no good reason except that it brings more complexity and perhaps some moderate slowdown. If someone thinks that complexity and some slowdown can be avoided while doing so much more, then they are dreaming. Every significant feature we put in Emacs always causes similar effects. Testing them in a variety of environments and workflows is the only way of getting them improved and enhanced for the users. This feature is no different. > But you really should think whether your way of dealing with technical > problems by ostracizing is doing yourself a favor, let alone anybody > else. I have no problem with your technical comments, never had them. What triggered this exchange was a nasty personal attack on myself and my motives, which had nothing to do with technicalities. That I will not tolerate, not from you, not from anyone else.