From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Newsgroups: gmane.emacs.bugs Subject: bug#9571: 24.0.50; user option to turn off bidi, please Date: Fri, 23 Sep 2011 15:01:32 +0200 Message-ID: <878vpffm4z.fsf@gmail.com> References: <87obybg01n.fsf@gmail.com> <834o03sgsu.fsf@gnu.org> <87d3erfrb5.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1316783275 9183 80.91.229.12 (23 Sep 2011 13:07:55 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 23 Sep 2011 13:07:55 +0000 (UTC) Cc: 9571@debbugs.gnu.org To: Juanma Barranquero , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 23 15:07:50 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1R75Tp-0004oB-E3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 15:07:49 +0200 Original-Received: from localhost ([::1]:33352 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R75To-00054v-V6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 23 Sep 2011 09:07:48 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54915) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R75Tm-00054S-1s for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 09:07:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R75Tc-00076o-FC for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 09:07:46 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:47932) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R75Tc-00076i-AK for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 09:07:36 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R75U2-0004Za-4k for bug-gnu-emacs@gnu.org; Fri, 23 Sep 2011 09:08:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 23 Sep 2011 13:08:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9571 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: wontfix Original-Received: via spool by 9571-submit@debbugs.gnu.org id=B9571.131678323817526 (code B ref 9571); Fri, 23 Sep 2011 13:08:02 +0000 Original-Received: (at 9571) by debbugs.gnu.org; 23 Sep 2011 13:07:18 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R75TK-0004Yd-Bc for submit@debbugs.gnu.org; Fri, 23 Sep 2011 09:07:18 -0400 Original-Received: from mail-fx0-f44.google.com ([209.85.161.44]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R75TH-0004YU-H0 for 9571@debbugs.gnu.org; Fri, 23 Sep 2011 09:07:16 -0400 Original-Received: by fxd18 with SMTP id 18so3531947fxd.3 for <9571@debbugs.gnu.org>; Fri, 23 Sep 2011 06:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=EH6/hhtxd5loELzH/2W3NvoilIdMHUjMbAMktTypx/g=; b=T4gNw18DMVhCNJEPNufX0azNuRqE4b6bg7KS+3BcEL6nn7VArWWd3tuiAAdjbBWahy RMQPLt3q7EppfmkovJis1Kw7RsoEteE9DVH3nYbvKZvJ8qFh2qlGgzYKesYvhT06UrxZ 8gGouRiLNVhSxOhFNAV8k/kgev2zg3Fggaz+0= Original-Received: by 10.223.48.211 with SMTP id s19mr4995830faf.33.1316783208466; Fri, 23 Sep 2011 06:06:48 -0700 (PDT) Original-Received: from localhost (176.119.broadband10.iol.cz. [90.177.119.176]) by mx.google.com with ESMTPS id h16sm11026477fab.19.2011.09.23.06.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Sep 2011 06:06:47 -0700 (PDT) In-Reply-To: (Juanma Barranquero's message of "Fri, 23 Sep 2011 13:45:35 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 23 Sep 2011 09:08:02 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:51714 Archived-At: On Fri, 23 Sep 2011 13:45:35 +0200 Juanma Barranquero wrote: > 2011/9/23 =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec : >> I still think "there is no way back" is all the more reason to be as >> helpful and open about the changes and possible problems as possible. > > Pretest *is* the moment to discover, and hopefully fix, the possible prob= lems... It's meant to be, yes, but I suspect most users just wait for the release. And in any case, clear information about an experimental (or call it "new", if "experimental" is controversial) feature and related issues is very useful for pretesters, too. >> In >> other words, not clearly saying that bidi might bring problems and how >> to work around them in the user documentation at this point would only >> be reasonable if Emacs bidi was pretty much a solved problem, but that's >> really not the impression I got from the related emacs-devel discussions >> or even from your explanation. > > That's a bit absurd, IMO (no offense intended). New features are never > a "solved problem" until they have been extensively tested, and then > some. That has to be done at some point in time. And that moment is > now. Some features are more experimental than others, some are more annoying when gone wrong than others, and some cause annoyances harder to diagnose than others. On Fri, 23 Sep 2011 13:50:59 +0200 Eli Zaretskii wrote: >> From: =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec >> Cc: 9571@debbugs.gnu.org >> Date: Fri, 23 Sep 2011 13:09:49 +0200 >>=20 >> By under-documenting the issue you only provide more opportunity to >> FUD. In other words, not clearly saying that bidi might bring >> problems and how to work around them in the user documentation at >> this point would only be reasonable if Emacs bidi was pretty much a >> solved problem, but that's really not the impression I got from the >> related emacs-devel discussions or even from your explanation. > > I happen to be a documentation freak, and tried to do my best in > documenting everything related to bidi. If you can suggest specific > changes to the user manual or NEWS about this, please do. Saying in > the manual that some feature "means trouble" is not something we use > to do, because users will say "if it's trouble, why don't you fix > it?". We need to find a way of saying something useful that will help > users nonetheless. Suggestions are welcome. When you take one example Lars reported recently -- a buffer where the current bidi code wasn't able to diagnose the paragraph direction properly (or something) in a relatively untypical buffer (a lot of long lines without paragraph breaks). It made the buffer unusable. Now, how would a user diagnose or solve this issue? How would the current documentation help him in doing so? The user has to figure out that 1) (a problem with) the bidi reordering is the cause of the problem 2) they can work around it by setting bidi-display-reordering to nil. I'm rather sure the current documentation provides no clue as to point 1) (because it doesn't say such problems might occur and there is no other way to know), and I'm not quite sure it provides sufficient clues for point 2) (it says the variable "controls whether text in the buffer is reordered for display"; is a user with no clue about bidi likely to understand that as "when set to nil, the text in the buffer should behave just as before the bidi feature was introduced"? I don't know, but I suspect I might not, if I hadn't seen previous comments and references to the variable and its effects on emacs-devel and other places). I think unless you're pretty sure such problems are not likely to occur again, you should at least say (in NEWS if not in the manual; I would probably check the NEWS first in such situation anyway) that such things can happen and how to work around it (and you should probably also say that bidi is here to stay anyway so disabling it is only a workaround, encouraging users to report issues instead of just turning bidi off). --=20 =C5=A0t=C4=9Bp=C3=A1n