Re: UI inconveniences with M-.

["Fumitaka Tokumitsu" <toku345@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 7848 bytes --]

さほと



—
Sent from Mailbox

On Wed, Apr 29, 2015 at 11:41 AM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> [ 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

[-- Attachment #2: Type: text/html, Size: 8951 bytes --]