emacs-devel
[Top][All Lists]
Advanced

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

Re: UI inconveniences with M-.


From: Stefan Monnier
Subject: Re: UI inconveniences with M-.
Date: Tue, 28 Apr 2015 22:41:27 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

[ Moving this to emacs-devel.  ]

>> > Emacs 24 also had "C-u M-." to go to the next one.  This one doesn't;
>> > moreover, if you try "C-u M-.", you get prompted for the symbol again,
>> > and if you type the same one, you get nowhere.  The other matches are
>> > only available via completion, see below.
>> Maybe we should write an xref-old-ui-mode.
> I didn't ask for the old UI.  (If I want it, I can still have it,
> since the etags.el commands are still available.)  I'm okay with the
> new UI.  This bug report is about the new UI, and its goal is to make
> the new UI better.

Then I don't understand what you mean by the text I quoted.  E.g.:

   if you try "C-u M-.", you get prompted for the symbol again,
   and if you type the same one, you get nowhere

Well, duh!  What did you expect?  In the new UI, "C-u M-." jumps to
*the* definition (the "C-u" is only used to let you type the name of
thing you're looking for), so of course if you just jumped to it, asking
to jump to it again will get you nowhere else.  I guess it would be OK
to make M-. emit a message like "Hello?  We're already here!" in this
corner case, if you want to make sure something happens.

> old UI was consistent and complete: it always displayed the first/next
> match and provided a command to go to the next/previous one.  By
> contrast, the new UI is inconsistent: with some back-ends it shows the
> list of matches and allows to navigate it, with others it shows only
> the first match and does not give any way to get the next match.

In the "M-. find-tag" example, the UI does let you see all matches.
It's just that there's only one.  If you want, we could make this case
popup an *xref* buffer with a single entry, but I think it makes more
sense to just jump straight to that one entry instead.

> But that's largely immaterial: this bug report is not about the
> back-end, it's about the UI.

I wouldn't be so sure.

>> Arguably, the find-tag advice in org-ctags.el could be offered as well,
>> if org-ctags.el happens to be loaded
> ??? Why should the xref matches depend on what is and isn't loaded?

Because that's how xref/elisp works.

> That would make xref exactly equivalent to "M-x apropos", which means
> this mode of operation would make xref entirely redundant.

To you, maybe.  Personally, I find it's *much* quicker to use M-. than
to use C-h f RET <go-to-the-link> RET, and it has the added benefit that
M-, brings me right back if I need to.

> To say nothing of the fact that this doesn't scale to any language
> except ELisp.

Not at all.  Many (most?) packages which offer a functionality along the
lines of "M-. to jump to the definition" use an implementation technique
which is fundamentally similar/equivalent (obviously, they don't query
a running Emacs, but they query a running REPL).

> We could offer this mode as an optional feature, but it certainly
> shouldn't be the default.

Many users here disagree.

> (One of my worst annoyances is to type a C-h command and be presented
> with "[No match]", because some package is not loaded or some function
> is not available in the Emacs configuration I happen to be using.)

Yes, that's a long standing problem, indeed.  I have a local hack which
tries to add to loaddefs.el a concise description of where definitions
might be found (basically, for each file, list the few prefixes used in
that file), so that "C-h f" can load those packages when needed.
It's "proof of concept" and it has occasionally rendered my Emacs
session unusable (e.g. because it ended up deciding to try and load,
say, w32-fns.el to see if it might contain the definition).  I think
I've now solved most of those problems in the w32-* files, but the
underlying risk is still there.

> That's one way of looking at it.  Another is to say that etags gave
> you more information and thus allowed to find more loose matches,
> which is helpful when your memory is failing you.

M-. jumps to the definition of the "thing under point".  There's no
memory involved.
If you're not sure what you're looking for, then you're expected to use
the completion facilities in C-u M-.

> But in the context of this bug report, that, too, is immaterial: if we
> think the etags back-end gives too much information, by all means
> let's filter it before presenting the matches.

Yes, that's clearly very much needed.

> Bonus points for making the filtering optional, since some people
> might like that, and in some situations even you might need it.

I disagree.  The filtering is needed by the design of the xref API.
If you want to see the "unfiltered" data, then use M-x xref-find-apropos.

> Then let's fix the results we display with the etags back-end to show
> only the relevant ones.

Yes, please.

> Saying that the back-end returns a confusingly large amount of bogus
> matches, and then switching to a UI that assumes much smarter
> back-ends (which don't really exist) makes very little sense to me.

The smarter backends already exist, in so far as there is already code out
there which provides the needed functionality.  It just doesn't use the
xref API yet, because it was written before xref.el.

> The old code attempted to support both use cases, by showing the exact
> match(es) first, followed by less likely ones.  We do similar things
> in other commands.  The advantages of such a method are that (1) you
> don't need to second-guess the user, (2) you provide only one command
> for the user to remember, and (3) if the user only _thinks_ she knows
> the name, but really doesn't, she can find the information without
> having to invoke another command.

>> I think that's an important feature of the new code in this respect.

> But it is incomplete without a means to get to the other possible
> matches in this case.

> To summarize my points in this sub-thread:

>   . the UI should depend much less on the back-end, ideally not at all

You keep repeating this, but that is absolutely meaningless to me (kind
of like "it doesn't work" in bug reports):
- This consistency was trivially obtained with the old etags.el code
  since it had one 1 backend.
- What the fuck should the new UI do if one backend returns 1 match and
  another returns a hundred (as in your "find-tag" example)?

>   . there should be a way to go to the next/previous match if the
>     *xref* buffer is not displayed (or not created in the first
>     place); if this happens because there's only one match, we should
>     say so explicitly

The only case where the *xref* is not displayed is when there's only
1 match returned by the backend.  So "go to the next/previous match" is
again meaningless.

>   . when there are more than one possible match, the UI should behave
>     similarly, i.e. display the *xref* buffer; when there's only one
>     match, it should _never_ display *xref*,

That's exactly what the code does.

>     and should display an indication of the fact that there's only one
>     match

The current code "displays" this indication by jumping to the sole match
instead of jumping to the *xref* buffer.  I think it's clear enough.

>   . if the criteria for filtering of the matches are very different
>     between the possible back-ends, there should be some agreed-upon
>     uniform default that returns roughly the same number of matches
>     with all back-ends, and the rest should be controlled by user
>     options

I don't see what that could concretely look like.


        Stefan



reply via email to

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