From: Drew Adams <drew.adams@oracle.com>
To: Dmitry Gutov <dgutov@yandex.ru>, Eli Zaretskii <eliz@gnu.org>
Cc: 23426@debbugs.gnu.org
Subject: bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline
Date: Wed, 4 May 2016 09:04:39 -0700 (PDT) [thread overview]
Message-ID: <0ef7b74a-ba45-46a0-a46a-81bb6ae450a6@default> (raw)
In-Reply-To: <c5bd7279-341a-1ad7-4bb9-e2da5b35e345@yandex.ru>
> > It's the new feature that should perhaps not have a key. At
> > least it should not grab an existing key. There are plenty of
> > unbound keys in Dired. And why not just provide the command,
> > for now, and let users bind it themselves if they like?
>
> Because we want to provide a coherent, consistent interface to the
> users. Since M-. has changes to the xref UI,
Same issue there. Why replace that key binding? Why not provide
your new feature separately? What's the need to replace (now)?
I understand that you think this new does everything the old does,
and better. That's still not a good reason to replace the old
immediately (including just taking over its key bindings).
Just add the new - that should be enough. If it truly does
everything the old does, and better, that will soon enough be
clear to all, and there will be time enough to move out the old
eventually.
Emacs has long had parallel, different-behaving features that
filled more or less the same needs for users. We haven't felt
the imperative to replace one with another. You can use many
different commands or UIs in Emacs to get the same job done.
You can even emulate VI and CUA in Emacs. Emacs has been a
big tent, not an in-with-the-new-way-out-with-the-old puptent.
I welcome a show-all-search-hits-and-let-me-filter-and-choose
approach for Dired searching. I've even developed such features
myself, for my own use. I do not object to this feature - quite
the opposite.
What I question is replacing the existing features - and yes,
even just appropriating their key bindings. That is not
necessary - is it? Can't you just add this feature, without
fiddling with the existing, different ways to search? Why
must you insist on replacing and not be content to add?
> > You changed the default behavior immediately. That's a far
> > cry from providing, say, an ELPA package with the new feature
> > and letting users adopt it by choice, and then, after a few
> > years, discussing and deciding whether to replace the existing
> > default behavior. What's the hurry to replace?
>
> xref could have been incubated in ELPA, and that would have been a
> reasonable choice as well, but at the time it was decided to be good
> enough to be installed in the core already. So that ship has sailed.
"That ship has sailed" seems to be the latest excuse for all kinds
of stuff. Never heard that as an excuse here in past years.
And no; nothing has sailed. None of this stuff has "shipped".
Not curly-quotitis, and not this feature.
This is a relatively recent phenomenon: wide-ranging, quick
changes to C code etc., followed by "too late to question;
already done; too late to back out now", even before released.
> >> OTOH, when Drew will stop assuming "Emacs devs" have ill will, and
> >> release knee-jerk reactions, such as this one, based on that, is
> >> anyone's guess.
> >
> > When will Eli stop personalizing everything?
>
> There's no need to blame Eli for this, that's for sure.
I don't blame him (or anyone in particular) for the feature.
I mentioned Eli by name because he mentioned me by name, and
he attributed false motives to me. My complaint was about his
personalizing things, not about his support of this feature.
next prev parent reply other threads:[~2016-05-04 16:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-02 17:17 bug#23426: 25.0.93; dired-do-find-regexp doesn't find newline Heinz Rommerskirchen
2016-05-02 17:41 ` Drew Adams
2016-05-02 17:45 ` Drew Adams
2016-05-02 18:23 ` Dmitry Gutov
2016-05-03 1:18 ` Glenn Morris
2016-05-03 16:18 ` Eli Zaretskii
2016-05-03 23:08 ` Dmitry Gutov
2016-05-03 17:22 ` Dmitry Gutov
2016-05-03 19:00 ` Glenn Morris
2016-05-03 20:59 ` Dmitry Gutov
2016-05-04 2:05 ` Drew Adams
2016-05-04 2:34 ` Dmitry Gutov
2016-05-04 4:24 ` Drew Adams
2016-05-04 15:01 ` Eli Zaretskii
[not found] ` <<838tzpkgtj.fsf@gnu.org>
2016-05-04 15:31 ` Drew Adams
2016-05-04 15:39 ` Dmitry Gutov
2016-05-04 16:04 ` Drew Adams [this message]
2016-05-04 16:13 ` Eli Zaretskii
2016-05-04 16:00 ` Eli Zaretskii
[not found] ` <<83r3dhizis.fsf@gnu.org>
2016-05-04 16:32 ` Drew Adams
2016-05-04 16:51 ` Eli Zaretskii
2016-05-04 5:00 ` Kaushal Modi
2016-05-04 10:32 ` Dmitry Gutov
2016-05-04 13:32 ` Drew Adams
2016-05-04 13:49 ` Dmitry Gutov
2016-05-04 15:31 ` Drew Adams
2016-05-04 16:01 ` Eli Zaretskii
2016-05-04 15:15 ` Eli Zaretskii
2016-05-04 15:10 ` Eli Zaretskii
[not found] ` <<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default>
[not found] ` <<831t5hkg6x.fsf@gnu.org>
2016-05-04 15:39 ` Drew Adams
2016-05-04 15:53 ` Dmitry Gutov
2016-05-04 16:10 ` Drew Adams
2016-05-04 16:14 ` Eli Zaretskii
2016-05-04 16:20 ` Kaushal Modi
2016-05-04 16:25 ` Dmitry Gutov
2016-05-04 16:41 ` Eli Zaretskii
2016-05-04 18:06 ` Kaushal Modi
2016-05-04 16:28 ` Dmitry Gutov
2016-05-04 16:08 ` Eli Zaretskii
[not found] <<<CAFyQvY0KYfeg9-f8DiCJcEy5-W=yRFykLLpCHRtCeqzz9Bdi0g@mail.gmail.com>
[not found] ` <<3ba077a2-21e0-9799-4f8b-c07bd1623853@yandex.ru>
[not found] ` <<<6a4860bb-2b39-4da4-b2a7-7b8d15211fee@default>
[not found] ` <<<831t5hkg6x.fsf@gnu.org>
[not found] ` <<7da95e19-50ff-4ca5-a5b8-2a7f65c2a7cd@default>
[not found] ` <<6cf9e2bf-fa90-3783-b30a-9021074790b0@yandex.ru>
[not found] ` <<93badbbc-31f6-409d-8dff-d67e9202deca@default>
[not found] ` <<83lh3piyvq.fsf@gnu.org>
2016-05-04 16:23 ` Drew Adams
[not found] ` <<83oa8liz53.fsf@gnu.org>
2016-05-04 16:39 ` Drew Adams
2016-05-04 18:20 ` John Wiegley
2016-05-04 20:09 ` Drew Adams
2016-05-04 21:13 ` John Wiegley
2016-05-05 17:07 ` Eli Zaretskii
2016-05-05 23:44 ` John Wiegley
2016-05-05 17:03 ` Eli Zaretskii
2016-05-05 17:01 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0ef7b74a-ba45-46a0-a46a-81bb6ae450a6@default \
--to=drew.adams@oracle.com \
--cc=23426@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.