From: Jaakov <j_k_v@ro.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 13949@debbugs.gnu.org
Subject: bug#13949: (no subject)
Date: Tue, 22 Mar 2016 22:58:20 +0100 [thread overview]
Message-ID: <56F1BFFC.7090104@ro.ru> (raw)
In-Reply-To: <83zitq2s56.fsf@gnu.org>
On 03/22/2016 09:07 PM, Eli Zaretskii wrote:
>> Cc: 13949@debbugs.gnu.org
>> From: Jaakov <j_k_v@ro.ru>
>> Date: Tue, 22 Mar 2016 20:53:24 +0100
>>
>>>> I think you just didn't get my point.
>>>
>>> I'm getting your point, believe me.
>>>
>>>> Am I being unclear on the principal difference between
>>>> (1) _what_ a routine should do and
>>>> (2) _how_ it should do it?
>>>> ?
>>>
>>> I understand you, I just don't agree.
>>
>> Your argument for not agreeing was:
>>
>> "the buffer text is changed (at least twice), which turns on the
>> modified flag."
>>
>> If you do understand me, please observe that from the viewpoint of (1)
>> in the described examples the buffer text is NOT changed, neither once,
>> nor twice, not at all.
>> (Some properties may change, but not the buffer text. Also, the user has
>> no practical way to look at the intermediate computation.)
>>
>> Reason:
>>
>> In our case, in the view of (1) the term "buffer text is changed" is
>> defined, somewhat diffusely, as not "the same contents as the
>> corresponding file on the disk".
>>
>> Source:
>> "The text displayed in the mode line has the following format:
>> cs:ch-fr buf pos line (major minor)
>> ...
>> The next element on the mode line is the string indicated by ch. This
>> shows two dashes (‘--’) if the buffer displayed in the window has the
>> same contents as the corresponding file on the disk; i.e., if the buffer
>> is “unmodified”. If the buffer is modified, it shows two stars (‘**’)."
>> from
>> https://www.gnu.org/software/emacs/manual/html_node/emacs/Mode-Line.html#Mode-Line
>>
>> Therefore, the first part of your argument is invalid.
>>
>> Am I being clear?
>
> Yes.
>
> 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.
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.
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.
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
Therefore, I consider the above reasons for triaging as "wishlist"
flawed both in (a) and in (b).
Is that enlightening?
I am retracting the claim that modifies-flag or fill-properties have
bugs _alone_: this claim is too imprecise. What does have a bug is the
combination of ** and M-x fill-paragraph, with respect to the online
documentation mentioned before.
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'.
next prev parent reply other threads:[~2016-03-22 21:58 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 22:09 bug#13949: 24.3.50; `fill-paragraph' should not always put the buffer as modified Dani Moncayo
2013-03-14 3:43 ` Eli Zaretskii
2013-03-14 7:57 ` Dani Moncayo
2013-03-14 10:27 ` Andreas Röhler
2013-03-14 17:50 ` Eli Zaretskii
2013-03-14 13:38 ` Stefan Monnier
2013-03-14 17:53 ` Eli Zaretskii
2013-03-14 18:34 ` Andreas Röhler
2013-03-14 18:49 ` Eli Zaretskii
2013-03-14 19:01 ` Andreas Röhler
2013-03-14 19:19 ` Eli Zaretskii
2013-03-14 19:32 ` Andreas Röhler
2013-03-15 4:02 ` Stefan Monnier
2013-03-15 7:27 ` Dani Moncayo
2013-03-14 17:46 ` Eli Zaretskii
2013-03-14 18:34 ` Dani Moncayo
2016-03-22 10:50 ` bug#13949: 24.4.1; " Jaakov
2016-03-22 11:39 ` Andreas Röhler
2016-03-22 16:15 ` Eli Zaretskii
2016-03-22 17:40 ` Jaakov
2016-03-22 17:56 ` Michael Heerdegen
2016-03-22 18:07 ` Drew Adams
2016-03-22 18:23 ` Michael Heerdegen
2016-03-22 18:31 ` Eli Zaretskii
2016-03-22 18:42 ` Jaakov
2016-03-26 23:46 ` John Wiegley
2016-03-27 3:31 ` Óscar Fuentes
2016-03-27 7:44 ` Andreas Röhler
2016-03-27 15:09 ` Óscar Fuentes
2016-03-28 8:01 ` Andreas Röhler
2016-03-27 8:42 ` Andreas Schwab
2016-03-27 14:59 ` Óscar Fuentes
2016-03-27 15:15 ` Drew Adams
2016-03-27 15:21 ` Óscar Fuentes
2016-03-27 18:53 ` Drew Adams
2016-03-27 15:13 ` Drew Adams
2016-03-27 14:56 ` Eli Zaretskii
2016-03-27 15:28 ` Óscar Fuentes
2016-03-27 15:42 ` Dmitry Gutov
2016-03-27 15:52 ` Óscar Fuentes
2016-03-27 15:57 ` Lars Magne Ingebrigtsen
2016-03-27 16:21 ` Óscar Fuentes
2016-03-27 16:33 ` Lars Magne Ingebrigtsen
2016-03-27 16:46 ` Óscar Fuentes
2016-03-27 16:58 ` Lars Magne Ingebrigtsen
2016-03-27 18:22 ` Drew Adams
2016-03-27 15:29 ` Óscar Fuentes
2016-03-27 15:58 ` Eli Zaretskii
2016-03-27 16:05 ` Óscar Fuentes
2016-03-27 16:12 ` Eli Zaretskii
2016-03-27 16:37 ` Óscar Fuentes
2016-03-27 16:50 ` Eli Zaretskii
2016-03-27 17:30 ` Óscar Fuentes
2016-03-27 17:51 ` Eli Zaretskii
2016-03-27 16:38 ` Óscar Fuentes
2016-03-27 17:00 ` Lars Magne Ingebrigtsen
2016-03-27 16:14 ` Lars Magne Ingebrigtsen
2016-03-27 15:46 ` Lars Magne Ingebrigtsen
2016-03-27 16:04 ` Eli Zaretskii
2016-03-27 16:11 ` Lars Magne Ingebrigtsen
2016-03-27 16:18 ` Eli Zaretskii
2016-03-27 16:28 ` Lars Magne Ingebrigtsen
2016-03-28 10:39 ` Lars Magne Ingebrigtsen
2016-03-28 11:27 ` Lars Magne Ingebrigtsen
2016-03-28 11:32 ` Lars Magne Ingebrigtsen
2016-03-28 11:39 ` Lars Magne Ingebrigtsen
2016-03-28 13:46 ` Lars Magne Ingebrigtsen
2016-03-28 15:29 ` Eli Zaretskii
2016-03-28 15:39 ` Lars Magne Ingebrigtsen
2016-03-28 15:15 ` Eli Zaretskii
2016-03-28 15:39 ` Lars Magne Ingebrigtsen
2016-03-28 15:52 ` Óscar Fuentes
2016-03-28 16:29 ` Lars Magne Ingebrigtsen
2016-03-28 17:04 ` Eli Zaretskii
2016-03-28 17:07 ` Lars Magne Ingebrigtsen
2016-03-28 17:37 ` Eli Zaretskii
2016-03-28 17:45 ` Lars Magne Ingebrigtsen
2016-03-28 18:17 ` Eli Zaretskii
2016-03-28 8:09 ` Andreas Röhler
2016-03-27 15:28 ` Dmitry Gutov
2016-03-27 15:35 ` Óscar Fuentes
2016-03-27 15:46 ` Dmitry Gutov
2016-03-27 15:53 ` Lars Magne Ingebrigtsen
2016-03-27 20:24 ` Dmitry Gutov
2016-03-27 21:05 ` Óscar Fuentes
2016-03-27 21:20 ` Dmitry Gutov
2016-03-27 22:03 ` Óscar Fuentes
2016-03-27 15:35 ` Lars Magne Ingebrigtsen
2016-03-27 15:42 ` Dmitry Gutov
2016-03-27 15:50 ` Lars Magne Ingebrigtsen
2016-03-27 20:27 ` Dmitry Gutov
2016-03-27 21:36 ` Jaakov
2016-03-27 16:08 ` Jaakov
2016-03-22 17:52 ` Jaakov
2016-03-22 18:40 ` bug#13949: (no subject) Jaakov
2016-03-22 18:56 ` Eli Zaretskii
2016-03-22 19:07 ` Jaakov
2016-03-22 19:10 ` Eli Zaretskii
2016-03-22 19:53 ` Jaakov
2016-03-22 20:07 ` Eli Zaretskii
2016-03-22 21:58 ` Jaakov [this message]
2016-03-22 22:38 ` Glenn Morris
2016-03-23 15:57 ` Eli Zaretskii
2016-03-23 17:45 ` Jaakov
2016-03-26 23:33 ` John Wiegley
2016-03-23 15:57 ` Eli Zaretskii
2016-03-22 23:44 ` bug#13949: `fill-paragraph' should not always put the buffer as modified Petros Travioli
2016-03-28 4:55 ` bug#13949: fill-paragraph is buggy, but using MD5 is even more buggy Petros Travioli
2016-03-28 10:32 ` Andreas Schwab
2016-03-28 13:29 ` bug#13949: Aw: " Petros Travioli
2016-03-28 14:31 ` Andreas Schwab
2016-03-28 17:05 ` Eli Zaretskii
2016-03-28 15:16 ` Petros Travioli
2016-03-28 17:05 ` Lars Magne Ingebrigtsen
2016-03-28 17:06 ` Eli Zaretskii
2016-03-28 19:03 ` Petros Travioli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56F1BFFC.7090104@ro.ru \
--to=j_k_v@ro.ru \
--cc=13949@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).