From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#13949: (no subject) Date: Wed, 23 Mar 2016 17:57:17 +0200 Message-ID: <83mvpp2nmq.fsf@gnu.org> References: <56F191A0.9050803@ro.ru> <83bn664a0t.fsf@gnu.org> <56F197E5.908@ro.ru> <8360we49c7.fsf@gnu.org> <56F1A2B4.8010401@ro.ru> <83zitq2s56.fsf@gnu.org> <56F1BFFC.7090104@ro.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1458748703 10736 80.91.229.3 (23 Mar 2016 15:58:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Mar 2016 15:58:23 +0000 (UTC) Cc: 13949@debbugs.gnu.org To: Jaakov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Mar 23 16:58:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ailAh-0003AA-CY for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 16:58:11 +0100 Original-Received: from localhost ([::1]:44666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailAg-0003Ka-Og for geb-bug-gnu-emacs@m.gmane.org; Wed, 23 Mar 2016 11:58:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51418) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailAc-0003KC-By for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:58:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ailAZ-00023r-4j for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:58:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37480) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailAZ-00023m-0V for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:58:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ailAY-0002pE-5K for bug-gnu-emacs@gnu.org; Wed, 23 Mar 2016 11:58:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Mar 2016 15:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13949 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13949-submit@debbugs.gnu.org id=B13949.145874866410831 (code B ref 13949); Wed, 23 Mar 2016 15:58:02 +0000 Original-Received: (at 13949) by debbugs.gnu.org; 23 Mar 2016 15:57:44 +0000 Original-Received: from localhost ([127.0.0.1]:34607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailAG-0002od-FD for submit@debbugs.gnu.org; Wed, 23 Mar 2016 11:57:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:60341) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ailAF-0002oP-A1 for 13949@debbugs.gnu.org; Wed, 23 Mar 2016 11:57:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ailA6-0001wG-Vt for 13949@debbugs.gnu.org; Wed, 23 Mar 2016 11:57:38 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ailA6-0001wC-SQ; Wed, 23 Mar 2016 11:57:34 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1898 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1ailA5-0008U0-N4; Wed, 23 Mar 2016 11:57:34 -0400 In-reply-to: <56F1BFFC.7090104@ro.ru> (message from Jaakov on Tue, 22 Mar 2016 22:58:20 +0100) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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:115393 Archived-At: > Cc: 13949@debbugs.gnu.org > From: Jaakov > Date: Tue, 22 Mar 2016 22:58:20 +0100 > > > But you are entirely missing the point. I'm not saying anything about > > the subject of this report, except this: it's an enhancement request. > > Why? Because (a) the code does exactly what it was designed to do, > > not something different; and (b) the effect of what the code does in > > this case is not a serious problem, like a crash or inability to do > > something important, it is just a minor annoyance. > > > > Therefore, the triage of the bug report as an enhancement request > > (a.k.a. "wishlist") is correct. > > > > Please note that I said nothing at all about whether the code should > > do something else, or whether the documentation should be corrected to > > use a different definition of what the "**" indication means. This > > would be a different argument, and I might even agree with you there. > > I'm only talking about the severity value, nothing else. > > > > OK? > > > I'm puzzled that I have to write the following trivialities, but no. > > Objections to your first paragraph: > > Please note that your (a) is neither usual nor directly usable: there is > no easy way to check "what it was designed to do", since the original > design of ** and fill-paragraph need not be > - available to today users > - relevant to the current state of the evolved software. Of course, there's a way: we, the Emacs developers, know very well how this was designed. The buffer-modified indication is set upon each modification of buffer text, and is reset by saving the buffer to a file or by a direct manual action, as in M-~. That is how it's designed to work, and that's what it does. > So, if you do insist on (a) as a way to differentiate on whether some > behavior is a bug or a feature, I would like to see this definition on > the GNU pages, accompanied by a proof that it was there yesterday (e.g. > a reference to the waybackmachine). And with a description of the > earlier _designed_ behavior of ** and fill-paragraph. You have it above. If that's not official enough for you, I'm sorry, but we don't have enough resources to satisfy your requests for such documentation (and you don't have any real right to demand it to begin with). > The right thing to check is not "what it was designed to do", but > whether fill-paragraph produces "an incorrect or unexpected result, or > [...] behave[s] in unintended ways." (See > https://en.wikipedia.org/wiki/Software_bug with today's date.) Our only > _common_ source of correct, expected, intended behavior descriptions is > here the documentation of the mode line and fill-paragraph. With regard > to this source of descriptions, ** and fill-paragraph together have a > bug, not a feature by the Wikipedia definition which I have no reason to > disbelieve. I'm not arguing whether or not there's a bug, I'm arguing only about its severity level. > Your (b) "the effect ... is not a serious problem" is absolutely > _unrelated_ to the GNU wishlist definition: "for any feature request, > and also for any bugs that are very difficult to fix due to major design > considerations.", see > https://debbugs.gnu.org/Developer.html#severities Wishlist is the only level provided by debbugs which means "enhancement", so that's what we use. If there were a better named value, we would probably use it instead. > Therefore, I consider the above reasons for triaging as "wishlist" > flawed both in (a) and in (b). I'm not surprised. > Is that enlightening? Not really. > Please note that I am not claiming that the expectations, intentions, > correctness statements for ** and fill-paragraph were clearly expressed. > In fact, they are very diffusely expressed. However, if you downgrade > this bug report based on the fact of the imprecision of the descriptions > of the results/behavior, I urge you to downgrade virtually all other bug > reports about routines with a comparable or worse level of > documentation. I.e., probably every single report in the emacs bug > database. If you do not do that, I see no reason to keep the bug report > downgraded and urge you to upgrade this bug report to 'normal'. Sorry, I'm not going to upgrade it. And I don't really understand why you keep insisting on that, since the severity has no effect whatsoever on either the probability that the bug will be fixed, nor on our willingness to accept patches for that if and when submitted. IOW, this argument is a complete waste of time and energy.