bug#13949: (no subject)

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 13949@debbugs.gnu.org
> From: Jaakov <j_k_v@ro.ru>
> 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.