bug#13949: (no subject)

[Jaakov]

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'.