bug#12535: 24.2.50; [PATCH] `edmacro-parse-keys' is incorrect for M-<TAB>

[Drew Adams <drew.adams@oracle.com>]

> > I really cannot imagine why that 6-char fix would
> > not have been applied sometime in the 7 years that
> > have elapsed since the report - let alone why the
> > bug would now be closed as "wontfix".
> 
> I think the reason is that when you say things like this:
> 
>   > Can you submit a new patch, preferably tested?
> 
>   Sorry; I really don't have the time now.  But I
>   think that all of the relevant info has been
>   provided, so you should be able to DTRT.
> 
> You unavoidably send the message that your time is more important than
> the person handling your bug report (to be clear, it's not the "I'm busy
> right now" part alone, but the combination of "I'm busy, you do it"
> that's the problem).

The "YOU should be able" was not, and is not,
directed at any particular person.  It's not at
all about "the person handling [my] bug report".
Not that I don't take into consideration someone
handling the report, but that "you" is not about
that person or any other.

It's a statement that the bug description - and
even a possible solution - is complete and clear
(IMHO), and Someone(TM) _could_ easily apply it.

And it questions why the bug should be _closed_,
if it has not yet been fixed.

It's not at all about my time vs someone else's
time.  We each contribute the way we can and the
way we want to.  I contributed a bug report, and
a possible fix, and I then contributed time and
effort trying to clarify and better communicate
the problem and proposed fix.

The possible fix is an "extra", a "nice-to-have",
a "freebie". - it's fine if how I think the
problem might be fixed is ignored in favor of a
better solution.  What's important is the bug
report - recording the bug so we're aware of it,
and so it might be fixed someday.

We are _all_ volunteers.  Submitting a bug report
is volunteer work, intended to help Emacs.  No
one should take a bug report as a commandment to
work or as a burden.  Bug reports are good, not
bad.  And they are for us all; they are not
personal directives for anyone to do anything.

> > Just the bug report, regardless of whether
> > any freebie suggested solution code was also
> > provided (which it was) [...]
> 
> Similarly, use of the word "freebie" implies that you don't consider the
> time spent reading and checking posted patches for mistakes as important.

No, it does not imply that at all.  See above.  It
stresses that what's important in the contribution
I chose to make is the bug report.  _If_ someone
wants to _also_ consider the fix I suggested, fine;
if not, another fix would be fine.

There is nothing in what I said that suggests that
I consider the work of actually fixing the bug to
be unimportant or trivial.  Relative to other bug
fixes I do think the suggested fix is pretty simple.

But I know that it takes time to apply and test
even a simple fix.  Just because I don't work on
that myself doesn't mean I trivialize that work
if done by someone else.  Quite the contrary.

If a school boy spends extra time reading poetry
and neglects his math studies, does that mean he
thinks math is unimportant or trivial?  No, that
doesn't follow.  He just prefers reading poetry.

The use of "freebie" emphasizes that I don't care
whether it gets fixed using my fix suggestion -
that was just a suggestion, aimed to help.  If
someone has a better fix then that's even better.

The point is that there is a _bug_, described.
It can be fixed, and I think that can be done
easily.  Whether someone else has the time or
will to do that is for them to decide.

When a user submits a bug report it's OK to ask
if they also want to provide a patch.  It's not
so OK to close the bug just because they don't
decline to do that.

In this case, the code change for the suggested
fix is truly trivial.  Requiring a patch and
testing from the submitter is over the top, IMO.

If that's the requirement - that the bug won't
be fixed unless the reporter submits a tested
patch - so be it.

Note the difference: The fact that the bug
_hasn't_ been fixed _because_ of that is a
bit surprising to me.  But _closing_ the bug
because of that, and because it hasn't yet
been fixed, is not good (IMHO).

> If bug reports were answered by utility-maximising robots this wouldn't
> matter.  However, we have only squishy humans available for bug report
> handling.  Therefore, please try to think about the human on the
> receiving end before you post something.

We are _all_ squishy humans, including users
who volunteer bug reports and possible fixes,
however imperfect or unclear the report or
unwise or imperfect the fix.

This reporter does _not_ expect that robots
read Emacs bug reports and fix bugs.  Nor do
I expect bugs to be closed robotically.  I'm
grateful that other squishy humans read bug
reports, try to understand them, and sometimes
find time to fix them.  I've always been so. 

Did I hound this thread with demands that
this bug be fixed - let alone demands that my
suggested fix be applied?  I don't think so.
How many years have passed?  How many times
did I ping or insist that it be fixed?

If no one wants to fix it, fine - but too bad
(for us all).  I don't blame (and have not
blamed) anyone for not volunteering to fix it.
I expressed surprise, years later, that it
hasn't been fixed and, especially, that it's
being closed.

Personally, I don't think such a bug (or any
bug that is recognized as such and is not
deemed unfeasible to fix) should be closed.

But I know that others can feel differently.
In some organizations (e.g. companies) there
are members whose job it is to reduce the set
of outstanding bugs.

I don't see why a user-run volunteer group
would want to close bugs (recognized as bugs
and as feasible to fix) just because time has
passed or there is currently no one to work
on fixing them.  No one gets a raise from
reducing the bug count.  But again, I know
that others can see this differently.