From: Drew Adams <drew.adams@oracle.com>
To: Helmut Eller <eller.helmut@gmail.com>, emacs-devel@gnu.org
Subject: RE: Generalizing find-definition
Date: Sat, 6 Dec 2014 10:38:47 -0800 (PST) [thread overview]
Message-ID: <ef0ed614-3a0d-4333-b966-dd0abeed240c@default> (raw)
In-Reply-To: <m21tod88em.fsf@gmail.com>
> A problem seems to be that xref-identifier-at-point would need a
> possibly complicated heuristic to determine if we are at such a
> filename or a "normal" identifier. Maybe it's easier to have a
> separate xref-file-name-at-point which would by default do what
> ffap-guess-file-name-at-point does. For ELisp it should
> additionally recognize (require 'foo) and somehow reuse find-library.
And..., and somehow..., and..., and somehow...
In general, this is the wrong approach, I think.
Q. When does reuse of a file name or a URL or... at point make
sense?
A. As input to a command that acts on a file name or a URL or...
The *particular command* already knows what kind of thing it
expects. All that's needed, as a *general* mechanism, is a
general way to pull text at point into the minibuffer.
That's where the design effort should be, IMO. And this
mechanism should be entirely decoupled from any particular
use of the grabbed text. That's my main point here.
In particular, `find-definition' itself might be misguided.
I cannot really speak to whether it is, but that's my hunch.
Doesn't a user know what kind of thing definition s?he wants
to look up? Does s?he really need Emacs to guess what kind
of thing is at point (a guess that is fraught with ambiguity)?
The problem comes down, I think, to providing a key (or keys)
that will *grab what the user wants at point*.
We should then bind that key in `minibuffer-local-map' so that
it is available *always*, regardless of the minibuffer-reading
command and the particular way of reading (with completion or
not, and for any kind of completion).
There is room for imagination and invention here, and that is
where the effort should be placed, IMHO.
Let's suppose that we start by trying for just a single key -
`M-.', for instance. Clearly, adding more "grab" keys would
make it easier for a user to make known to Emacs what to grab,
but it would also make users know more keys etc. We can always
add more. Let's see what can be done with one, for starters.
As food for thought, here is a description of what `M-.' does
in Icicles, from the minibuffer. I don't claim that this is
the full solution - at all. As I said, I think there is plenty
of room for invention, to come up with good ways for a user to
tell Emacs what thing(s) to grab at point.
Icicles currently uses a single key, `M-.', to grab stuff into
the minibuffer from point. You customize what your general
preferences are in this regard.
The choice you make is whether repeated use of `M-.' should,
by default, grab (a) additional stuff of the same type or
(b) alternative stuff of different types (i.e., replacing,
in the minibuffer, what the previous invocation grabbed).
You can override your general preference (alternatives vs
more-of-the-same) on the fly when you use `M-.', by
providing a prefix arg.
For example, if you generally prefer that repeated `M-.'
grab different kinds of thing at point (default behavior),
then `C-u M-.' switches the behavior temporarily so that
repeating `M-.' grabs successive occurrences of the same
kind of thing.
There is additional, more complex behavior available as
well. You can customize the sequence of functions used to
grab different kinds of thing. You can grab successive
things of the same type to the left or to the right of
point. You can grab alternative things at point and
insert not the grabbed text but the result of evaluating
it as a Lisp sexp.
This page describes the behavior of `M-.' in Icicles:
http://www.emacswiki.org/Icicles_-_Inserting_Text_from_Cursor
And this part describes the details outlined above:
http://www.emacswiki.org/Icicles_-_Inserting_Text_from_Cursor#RepeatedM.
To be clear, I am not at all proposing this same behavior
for Emacs. I point to it as food for thought.
What I am suggesting is only this:
1. It makes sense to concentrate on coming up with a
useful, general-purpose grab-text-at-point minibuffer
command, not with a general-purpose `find-definition'
top-level command.
2. What Icicles does in this regard might serve as some
food for thought. But there are surely more and
better possibilities.
3. Everything useful need not be combined in a single
minibuffer command (such as Icicles tries to do with
`M-.'). Having different, easily understood behaviors
on separate keys can also be a good way to go.
HTH.
next prev parent reply other threads:[~2014-12-06 18:38 UTC|newest]
Thread overview: 172+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-02 14:15 Generalizing find-definition Jorgen Schaefer
2014-11-02 15:34 ` Stefan Monnier
2014-11-02 16:29 ` Jorgen Schaefer
2014-11-02 18:14 ` Helmut Eller
2014-11-02 18:35 ` Jorgen Schaefer
2014-11-02 19:51 ` Helmut Eller
2014-11-02 20:17 ` Jorgen Schaefer
2014-11-03 2:22 ` Stefan Monnier
2014-11-03 7:03 ` Helmut Eller
2014-11-03 7:44 ` Jorgen Schaefer
2014-11-03 14:17 ` Stephen Leake
2014-11-03 14:30 ` Stefan Monnier
2014-11-03 18:28 ` Jorgen Schaefer
2014-11-03 20:09 ` Stefan Monnier
2014-11-03 20:55 ` Jorgen Schaefer
2014-11-03 22:38 ` Stefan Monnier
2014-11-04 14:52 ` Stephen Leake
2014-11-04 18:12 ` Stefan Monnier
2014-11-04 23:13 ` Stephen Leake
2014-11-05 2:00 ` Stefan Monnier
2014-11-06 15:33 ` Dmitry Gutov
2014-11-06 19:40 ` Stephen Leake
2014-11-07 2:57 ` Yuri Khan
2014-11-07 20:56 ` Dmitry Gutov
2014-11-03 22:39 ` Stefan Monnier
2014-11-04 14:58 ` Stephen Leake
2014-11-03 23:46 ` Stephen J. Turnbull
2014-11-04 7:58 ` Jorgen Schaefer
2014-11-04 2:52 ` Yuri Khan
2014-11-04 7:41 ` Jorgen Schaefer
2014-11-06 15:22 ` Dmitry Gutov
2014-11-06 16:51 ` Stefan Monnier
2014-11-06 17:00 ` Helmut Eller
2014-11-06 17:08 ` Multiple next-error sources Jorgen Schaefer
2014-11-06 23:15 ` Stefan Monnier
2014-11-07 9:49 ` Jorgen Schaefer
2014-11-07 14:59 ` Stefan Monnier
2014-11-07 15:24 ` Daniel Colascione
2014-11-07 15:55 ` Stefan Monnier
2014-11-07 16:08 ` Daniel Colascione
2014-11-07 18:17 ` Stefan Monnier
2014-11-07 18:22 ` Daniel Colascione
2014-11-07 19:06 ` Stefan Monnier
2014-11-07 15:41 ` Jorgen Schaefer
2014-11-07 16:03 ` Stefan Monnier
2014-11-07 16:55 ` Alan Mackenzie
2014-11-07 17:10 ` Daniel Colascione
2014-11-07 17:40 ` Alan Mackenzie
2014-11-08 8:55 ` Dmitry Gutov
2014-11-07 18:08 ` Stefan Monnier
2014-11-07 18:21 ` Alan Mackenzie
2014-11-07 18:48 ` Stefan Monnier
2014-11-07 19:51 ` Alan Mackenzie
2014-11-03 14:46 ` Generalizing find-definition Stephen Leake
2014-11-03 16:42 ` Stefan Monnier
2014-11-04 15:39 ` Stephen Leake
2014-11-04 18:14 ` Stefan Monnier
2014-11-17 20:10 ` Jorgen Schaefer
2014-11-18 8:07 ` Stephen Leake
2014-11-18 11:24 ` Helmut Eller
2014-11-18 12:48 ` Dmitry Gutov
2014-11-18 12:03 ` Helmut Eller
2014-11-19 14:27 ` Stefan Monnier
2014-11-19 14:51 ` Ivan Shmakov
2014-11-19 22:31 ` Stefan Monnier
2014-11-20 0:15 ` Stephen Leake
2014-11-20 4:18 ` Stefan Monnier
2014-11-18 16:31 ` Stefan Monnier
2014-11-20 0:21 ` Stephen Leake
2014-11-20 4:19 ` Stefan Monnier
2014-11-20 20:21 ` Jorgen Schaefer
2014-11-20 13:44 ` Helmut Eller
2014-11-20 20:28 ` Jorgen Schaefer
2014-11-20 20:42 ` Helmut Eller
2014-11-20 23:27 ` Stefan Monnier
2014-11-20 23:42 ` Jorgen Schaefer
2014-11-21 3:05 ` Stefan Monnier
2014-11-21 8:24 ` martin rudalics
2014-11-30 13:29 ` Stefan Monnier
2014-11-23 13:44 ` Johan Claesson
2014-12-01 17:31 ` Helmut Eller
2014-12-04 3:13 ` Stephen Leake
2014-12-04 8:07 ` Stephen Leake
2014-12-04 12:45 ` Helmut Eller
2014-12-04 9:11 ` Helmut Eller
2014-12-04 16:19 ` Stephen Leake
2014-12-04 16:49 ` Helmut Eller
2014-12-05 9:43 ` Stephen Leake
2014-12-05 13:25 ` Helmut Eller
2014-12-05 17:41 ` Stephen Leake
2014-12-06 8:55 ` Helmut Eller
2014-12-06 18:19 ` Stephen Leake
2014-12-06 18:38 ` Drew Adams [this message]
2014-12-07 16:52 ` Stephen Leake
2014-12-06 22:57 ` Stefan Monnier
2014-12-07 9:55 ` Helmut Eller
2014-12-08 14:33 ` Stefan Monnier
2014-12-08 19:58 ` Helmut Eller
2014-12-08 21:38 ` Stefan Monnier
2014-12-08 21:58 ` Jorgen Schaefer
2014-12-09 2:33 ` Stefan Monnier
2014-12-09 2:34 ` Stefan Monnier
2014-12-09 8:40 ` Helmut Eller
2014-12-09 14:03 ` Dmitry Gutov
2014-12-09 14:47 ` Helmut Eller
2014-12-11 4:06 ` Dmitry Gutov
2014-12-11 8:09 ` Helmut Eller
2014-12-11 11:12 ` Helmut Eller
2014-12-11 18:36 ` Helmut Eller
2014-12-11 19:21 ` David Engster
2014-12-11 19:36 ` Helmut Eller
2014-12-11 21:53 ` David Engster
2014-12-11 22:04 ` David Engster
2014-12-12 7:26 ` Helmut Eller
2014-12-11 22:52 ` Dmitry Gutov
2014-12-11 23:55 ` Stefan Monnier
2014-12-11 23:59 ` Dmitry Gutov
2014-12-11 15:07 ` Stefan Monnier
2014-12-11 18:43 ` Helmut Eller
2014-12-11 20:11 ` Stefan Monnier
2014-12-11 20:31 ` Helmut Eller
2014-12-11 21:33 ` Stefan Monnier
2014-12-15 17:21 ` Dmitry Gutov
2014-12-15 21:13 ` Stefan Monnier
2014-12-15 21:24 ` Dmitry Gutov
2014-12-15 21:57 ` Helmut Eller
2014-12-15 22:06 ` Dmitry Gutov
2014-12-15 22:17 ` Helmut Eller
2014-12-15 22:26 ` Dmitry Gutov
2014-12-15 22:41 ` Helmut Eller
2014-12-15 22:54 ` Dmitry Gutov
2014-12-15 23:03 ` Helmut Eller
[not found] ` <54901FEB.1090704@yandex.ru>
[not found] ` <m2k31ric89.fsf@gmail.com>
[not found] ` <5490962D.7010105@yandex.ru>
[not found] ` <m2y4q75ntx.fsf@gmail.com>
2014-12-16 21:40 ` Dmitry Gutov
2014-12-17 7:25 ` Helmut Eller
2014-12-19 8:00 ` Dmitry Gutov
2014-12-19 8:49 ` Helmut Eller
2014-12-19 14:34 ` Dmitry Gutov
2014-12-19 8:56 ` Helmut Eller
2014-12-19 13:36 ` Dmitry Gutov
2014-12-25 20:25 ` Dmitry Gutov
2014-12-26 3:50 ` Stefan Monnier
2014-12-28 22:21 ` Dmitry Gutov
2014-12-29 0:24 ` Stefan Monnier
2014-12-29 0:38 ` Dmitry Gutov
2014-12-29 1:54 ` Dmitry Gutov
2014-12-29 14:20 ` Stefan Monnier
2014-12-29 16:17 ` Eli Zaretskii
2014-12-29 17:27 ` Dmitry Gutov
2014-12-29 17:37 ` Eli Zaretskii
2014-12-29 18:56 ` Stefan Monnier
2014-12-27 19:01 ` Stephen Leake
2014-12-27 21:22 ` Stephen Leake
2014-12-12 1:29 ` Stephen Leake
2014-12-12 3:05 ` Stefan Monnier
2014-12-12 11:15 ` Stephen Leake
2014-12-12 13:58 ` Stefan Monnier
2014-12-13 9:56 ` Dmitry Gutov
2014-12-12 5:05 ` Dmitry Gutov
2014-12-10 9:11 ` Stephen Leake
2014-12-10 13:02 ` Dmitry Gutov
2014-12-10 17:00 ` Stephen Leake
2014-12-10 19:06 ` Stefan Monnier
2014-12-12 1:03 ` Stephen Leake
2014-12-10 14:10 ` Stefan Monnier
2014-12-11 4:08 ` Dmitry Gutov
2014-12-08 22:36 ` Stephen Leake
2014-11-02 22:26 ` Stephen Leake
2014-11-03 7:31 ` Jorgen Schaefer
2014-11-03 8:13 ` Helmut Eller
2014-11-03 13:49 ` Stephen Leake
2014-11-03 17:58 ` Jorgen Schaefer
2014-11-04 15:54 ` Stephen Leake
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ef0ed614-3a0d-4333-b966-dd0abeed240c@default \
--to=drew.adams@oracle.com \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).