From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Fumitaka Tokumitsu" Newsgroups: gmane.emacs.devel Subject: Re: UI inconveniences with M-. Date: Sat, 02 May 2015 01:26:15 -0700 (PDT) Message-ID: <1430555175081.6ae666e3@Nodemailer> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1430555175455" X-Trace: ger.gmane.org 1430556002 29736 80.91.229.3 (2 May 2015 08:40:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 08:40:02 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, dgutov@yandex.ru To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 10:39:57 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YoSxo-0007zm-Po for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 10:39:57 +0200 Original-Received: from localhost ([::1]:56361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSxo-0005Cl-4S for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 04:39:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33719) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSxK-0004nN-JI for emacs-devel@gnu.org; Sat, 02 May 2015 04:39:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoSke-0004tJ-Ow for emacs-devel@gnu.org; Sat, 02 May 2015 04:26:23 -0400 Original-Received: from mail-qk0-x232.google.com ([2607:f8b0:400d:c09::232]:33029) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSkb-0004rI-0l; Sat, 02 May 2015 04:26:17 -0400 Original-Received: by qkx62 with SMTP id 62so62081827qkx.0; Sat, 02 May 2015 01:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:mime-version:message-id:in-reply-to:references:from:to:cc :subject:content-type; bh=KD51YKfzNMZvNGWDdtxGyOlz8pgBxJSsjS0ngEiVAxI=; b=M4hRAVpxQodr5/T5ZSW+SONr1uaR2AI0Fq/10kT1GP8YTG8UEv432jvJn+QF8v0HdI 9pZBve1zr3oLkgl7YGFO+3ybAyvNqd1ZJUewDtIQpJ5LOQXxPAd1ajlCOBuBaz55cRwp kLj/k3QSBFGyfqqHcb3KLN2zxpDMrPFRZkoMQmEqE/JgRUtpcIMpx0wYr4qJ4qEGE2JY N4Slsiq0tnL9+wnaqBmm/TWGgw5Q5JSMVCXwSR/GlaWMq5byPPgEKRVefZqf1hZzkeKG W11XnQW8MdvU5hrdjUoheRXB5cCxc+NbwaEiA7EM0YTvdTlLt95ZT8acb6dtHLogAAmO sAwg== X-Received: by 10.229.19.67 with SMTP id z3mr17008186qca.2.1430555176236; Sat, 02 May 2015 01:26:16 -0700 (PDT) Original-Received: from hedwig-73.prd.orcali.com (ec2-54-85-253-161.compute-1.amazonaws.com. [54.85.253.161]) by mx.google.com with ESMTPSA id 72sm20259590qhx.32.2015.05.02.01.26.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 May 2015 01:26:15 -0700 (PDT) X-Google-Original-Date: Sat, 02 May 2015 08:26:15 GMT X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) In-Reply-To: X-Orchestra-Oid: EE488992-92B0-4734-BB5D-B23DF89B6433 X-Orchestra-Sig: 39df5455fac3b978e5c86f33080810d92726a493 X-Orchestra-Thrid: TFB12FED1-6944-4BF4-A204-E2CF54CCAD1C_1499752374264323516 X-Orchestra-Thrid-Sig: 45d73e69cb6cb4b513d0fed999557690c24c3449 X-Orchestra-Account: f5af25332f3b3fd9cde1a93a8e5bbf5c32dd6e10 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c09::232 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:186122 Archived-At: ------Nodemailer-0.5.0-?=_1-1430555175455 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E3=81=95=E3=81=BB=E3=81=A8 =E2=80=94 Sent from Mailbox On Wed, Apr 29, 2015 at 11:41 AM, Stefan Monnier wrote: > [ Moving this to emacs-devel. ] >>> > Emacs 24 also had =22C-u M-.=22 to go to the next one. This one = doesn't; >>> > moreover, if you try =22C-u M-.=22, 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 =22C-u M-.=22, you get prompted for the symbol again, > and if you type the same one, you get nowhere > Well, duh! What did you expect=3F In the new UI, =22C-u M-.=22 jumps = to > *the* definition (the =22C-u=22 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 =22Hello=3F We're already here!=22 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 =22M-. find-tag=22 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 >> =3F=3F=3F Why should the xref matches depend on what is and isn't = loaded=3F > Because that's how xref/elisp works. >> That would make xref exactly equivalent to =22M-x apropos=22, 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 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=3F) packages which offer a functionality along = the > lines of =22M-. to jump to the definition=22 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 =22[No match]=22, 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 =22C-h f=22 can load those packages when needed. > It's =22proof of concept=22 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 =22thing under point=22. 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 =22unfiltered=22 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 =5Fthinks=5F 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 =22it doesn't work=22 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 =22find-tag=22 example)=3F >> . 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 =22go to the next/previous match=22 = 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 =5Fnever=5F 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 =22displays=22 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 ------Nodemailer-0.5.0-?=_1-1430555175455 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=E3=81=95=E3=81=BB=E3=81=A8

=E2=80=94
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 =22C-u M-.=22 to go to the next one= . This one doesn't;
>> > moreover, if you try =22C-u M-.=22, 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 =22C-u M-.=22, you get prompted for the symbol again,=
and if you type the same one, you get nowhere

Well, duh! What did you expect=3F In the new UI, =22C-u M-.=22 = jumps to
*the* definition (the =22C-u=22 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 =22Hello=3F We're already here!=22 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 =22M-. find-tag=22 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
> =3F=3F=3F Why should the xref matches depend on what is and isn't = loaded=3F

Because that's how xref/elisp works.

> That would make xref exactly equivalent to =22M-x apropos=22, = 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=3F) packages which offer a functionality = along the
lines of =22M-. to jump to the definition=22 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 =22[No match]=22, 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 =22C-h f=22 can load those packages when needed.
It's =22proof of concept=22 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 =22thing under point=22. = 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 =22unfiltered=22 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 =5Fthinks=5F = 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 =22it doesn't work=22 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 =22find-tag=22 example)=3F

> . 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 =22go to the next/previous = match=22 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 =5Fnever=5F 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 =22displays=22 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


------Nodemailer-0.5.0-?=_1-1430555175455--