Re: Dired: Improve symmetry in mark/unmark commands bound to keys

[Tino Calancha <tino.calancha@gmail.com>]

On Sun, 25 Sep 2016, John Wiegley wrote:

>>>>>> "AS" == Andreas Schwab <schwab@linux-m68k.org> writes:
>
>>>>> I disagree and object to such a change.
>>>>
>>>> But is the only way that makes sense. You objection has no grounds.
>>>
>>> I stated my grounds. They might not make sense to you, but they do to me.
>
> AS> No, they make absolutely no sense. The prefix was obviously never intented
> AS> to be used with this command. The only intented use of the second argument
> AS> was the its caller, dired-flag-extension. That is easy to prove, because
> AS> before commit 736b582 it wasn't even documented in the doc string.
>
> Hi Andreas,
>
> I'm interested in the technical content of this exchange, but there is no
> place for telling the maintainer of a project that his objection is without
> ground. He _is_ our ground, and I ask everyone to respect this. If you believe
> otherwise, we're always on the lookout for future maintainers to take up the
> baton.
>
> So, while I like the appeal to consistency, if Eli objects, then I object, and
> you should feel obliged to resolve our concerns -- in terms of the issues at
> hand -- rather than stating they are baseless. Doing so will not move the
> discussion forward.
Hi John,

maybe the forms from Andreas where not the best, i acknowledge that, but
its not true that Andreas gave no strong arguments against the applied 
solution.  I miss similar strong arguments from the other side.
I still don't know why the bug report was closed such prompt considering
the issue was polemic.

1) First argument from Eli to reject my patch was that, there was no
    actually bug because you can provide the marker interactively by its
    code point.  He was worry something using that behaviour could be
    hurt if we modified it.

We inmediately told him that has absolutely no sense to ask the user to
input a code point to specify a character.  I cannot imagine anyone on 
this planet using such feature.  I would expect better arguments than
that to defeat a position.

That should be enough to make him open his eyes and follow our suggestion
based in a deep knowledge on Dired accumulated during many yers.

2) Then, we came back with another argument similar than: well, i have 
noticed there are no many ways in Dired to change the mark character, so
i would like to let this command to do such thing.

Again we answer him, that according with our large experience marking
facilities on Dired that is _not_ a good idea.  There is only one sensical
thing to do in such situation: I am with Andreas and Drew on this, it 
should _unmark_.

I might understand Andreas frustration after receive argumens 1) and 2),
and right after see close the bug report.  I felt the same way.
We are not a pair a clowns that where walking around.  We are
also Dired experts trying the fix one problem in the right way.  We feel
that our arguments have being neglected/ignored and the topic has being
prematurely closed.

In addition, i don't think you should unconditionaly object just
because Eli object.  The point to have 2 Emacs leaders is exactly to
have 2 brains looking the thing.  They might agree sometimes, the may
disagree others.
Also, keep in a wrong decision after several people are telling you that
is wrong is a double mistake.  You may think is a way to reafirm the
leadership.  I think is exactly the opposite.

This topic is very sensitive and important: its more than that commit, its 
about how Emacs take the decisions.

I may understand one hypotetical situation where some people say A and
others say B.  In that case the leader should unblock the situation and
decide what direction to follow.  But, if we have another situation where
N people say A and just the leader say B, the common sense tell us that
probably B is wrong.  I would expect Emacs would chose in
such situation A.  We are not python with its BDFL, i thought Emacs is
more democratic.  If its not the case, then i should not belong to
this community any more.