[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Tino Calancha
Subject: Re: Dired: Improve symmetry in mark/unmark commands bound to keys
Date: Mon, 26 Sep 2016 18:23:08 +0900 (JST)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

On Sun, 25 Sep 2016, John Wiegley wrote:

"AS" == Andreas Schwab <address@hidden> 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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]