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:35:24 -0700 (PDT) Message-ID: <1430555724149.e91f702e@Nodemailer> References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----Nodemailer-0.5.0-?=_1-1430555724503" X-Trace: ger.gmane.org 1430555971 29134 80.91.229.3 (2 May 2015 08:39:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 May 2015 08:39:31 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org, dgutov@yandex.ru To: "Stefan Monnier" , "=?UTF-8?Q?=E3=83=95=E3=82=A1=E3=83=9F=E3=83=9E?= =?UTF-8?Q?=EF=BC=B4=E3=82=AB=E3=83=BC=E3=83=89?= =?UTF-8?Q?=EF=BC=88=E3=83=9D=E3=82=A4=E3=83=B3?= =?UTF-8?Q?=E3=83=88=EF=BC=89=E3=81=8B=E3=82=89?= =?UTF-8?Q?=E3=81=AE=E3=81=8A=E7=9F=A5=E3=82=89?= =?UTF-8?Q?=E3=81=9B?=" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat May 02 10:39:20 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 1YoSxD-0007X7-NE for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 10:39:20 +0200 Original-Received: from localhost ([::1]:56358 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSxC-0004ou-SM for ged-emacs-devel@m.gmane.org; Sat, 02 May 2015 04:39:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoSx6-0004nL-Jl for emacs-devel@gnu.org; Sat, 02 May 2015 04:39:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YoStW-0000F1-EC for emacs-devel@gnu.org; Sat, 02 May 2015 04:35:32 -0400 Original-Received: from mail-qk0-x233.google.com ([2607:f8b0:400d:c09::233]:36073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YoStR-0000E2-Cx; Sat, 02 May 2015 04:35:25 -0400 Original-Received: by qku63 with SMTP id 63so61961104qku.3; Sat, 02 May 2015 01:35:25 -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=gyobvvUsjU3wGxQ/fPEDCuJmCestFyXsUrFiD+WRAIo=; b=wVC9/oMeyikyMzKS3In1Mwakt9o9rrq/htv8F86VRWBRGVcDQbPA4CuD51VALlfX3t b8RuUJkOEc2LCbPLkr5rQ1ILdbIK9WUqix6wGJ1VSXlY3xZAuBkKf2xLQ1EGOI9uLH8z +xBgsHllS8oawQ5yLS1rmpFx+gpGR7q4v7khHyfgRnB59XmgG0O67VNgMjFwjVaGavvu UpPJDS80dpaAFRMGkNJComkJtqpWpq8YIRnMQZwpyN/je+S1XCU9a9xROuyCdi4H49M+ wjUBKstYjDrQ7T2qKPQynJWkpMC+FH+NQrMeTMhVYnxbTI7QfecXZHv/QAQkv8T0M3LL XR6Q== X-Received: by 10.55.18.17 with SMTP id c17mr26895699qkh.25.1430555725014; Sat, 02 May 2015 01:35:25 -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 k85sm5112330qkh.48.2015.05.02.01.35.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 May 2015 01:35:24 -0700 (PDT) X-Google-Original-Date: Sat, 02 May 2015 08:35:24 GMT X-Mailer: Nodemailer (0.5.0; +http://www.nodemailer.com/) In-Reply-To: X-Orchestra-Oid: 1B625782-41E3-41A4-914E-B21C671CF2A2 X-Orchestra-Sig: 9163329eda0caf5403a69d2489725c3a9cefc662 X-Orchestra-Thrid: TFB12FED1-6944-4BF4-A204-E2CF54CCAD1C_1499752374264323516 X-Orchestra-Thrid-Sig: 45d73e69cb6cb4b513d0fed999557690c24c3449 X-Orchestra-Account: c77d8d85238a19f26c487d6dc7224607897b227e X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c09::233 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:186121 Archived-At: ------Nodemailer-0.5.0-?=_1-1430555724503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =E3=81=AB=E3=81=9F=E6=B3=A3=E3=81=8B=E3=81=AD=E3=81=91=E3=81=82=E3=81=9B= =E3=81=91=E3=81=8B=E3=81=8D=E3=81=AD=E3=81=AF=E3=81=8D=E3=81=8B=E3=81=8D= =E3=81=8B =E2=80=94 Sent from Mailbox On Fri, May 1, 2015 at 11:21 PM, Stefan Monnier wrote: >> If the back-end conceals potentially useful information, it should be >> fixed not to do so. > =22Conceal=22 makes it sound like it's ill-intentioned, done on purpose > or something. > For (defadvice find-tag ...), the problem is in advice.el. > Patches welcome, but since this library is on the way out AFAIC, I'd > recommend you don't bother spending time on it. >> That you personally find that information always redundant does not >> mean it's true for everyone else. There's more than one use case for >> these queries, see below. > We can't know what the user wants and handle all conceivable scenarios. > Maybe the user really wants to jump to this chunk of code somewhere that > does (fset foo bar) and hence ends up overriding the =22official=22 > definition of the function. But unless you can solve the halting > problem and read the user's mind at the same time, we'll have to settle > for something imperfect. > etags.el also failed miserably in some scenarios which xref/elisp > handles acceptably. E.g. try C-u M-. diff-mode-abrev-table RET. >> That's your misunderstanding. I described my user experience from >> using this new feature; I never said where the fixes should be made, > Well, you kept insisting that it's not a question of backend, so maybe > you didn't say where the fixes should go, but you did say where the = blame > should go. >> Says you. Through my naive-user eyes, filtering 140 hits to provide >> just a few is perfectly within the capabilities of the UI, at least in >> principle. > The 140 hits are just a list of locations. The UI has no fucking clue > whether these are function definitions or what, nor does it know in > which language the file is written. >> IOW, the separation of functionality is in the wrong place. To be >> useful, some of the =22smarts=22 need to be on the UI side, where user >> control can be best implemented, and where user intent is known much >> better. > The UI has to be agnostic. So the smarts can't be in the UI. The API > can be extended to provide the extra smarts that the UI might need, of > course. E.g. we could add to the API a function that sorts/groups the > entries, so the etags backend can sort them based on =22likelyhood=22 = rather > than group them by file. >> I very much hope Emacs will continue to be able to support the kind of >> activities I described above, which AFAIK are very important part of a >> software developer's job throughout the industry. > You fail to understand why complaint about etags.el. I'm not > complaining about `etags', but about the etags.el front-end, which is in > need of improvement to handle the case where the user is navigating > several completely different projects and doesn't want one to pollute > the other one. >>> I've tried several times to make real use of it, but always found it >>> completely unpalatable. What with having to build those damn TAGS >>> files, remember to refresh them, remember where they are, constantly >>> tell Emacs again where they are, deal with its inability to find the >>> right spot and having to repeat the =22C-u M-.=22 finger gymnastics >>> umpteen times. >> Those are exaggerations. > Partly, yes. I'm just venting my frustration with the tool, and > pointing out that if xref/elisp (and xref/etags) has some downsides, > etags.el had its own set of downsides. And some of those shouldn't be > that hard to fix (tho they would probably be a lot easier if we didn't > have to worry about annoying some old-time users because they'd have to > slightly change their habits). >> Building TAGS is almost instant, even in Emacs, > The problem is not computer-time but human-time. >> you need only refresh them very seldom, and Emacs offers the >> place from which to load them so you don't need to remember. > If Emacs knows where the file is, the user shouldn't need to be queried. >> But this, again, is immaterial for this discussion. I hope you will >> agree that, whatever issues we have with etags, replacing it with >> something that lacks important functionality is not a good idea. > As I said, going back to etags.el is not an option. >> That =22little detail=22 all but invalidates most of my use cases. > Then don't use that backend. E.g. use xref-etags-mode. >>> C-u M-. also lets you do loose matching, via completion, if your = memory >>> is failing you. >> I don't think completion is the right tool for these searches, because >> the name alone doesn't tell enough. > Don't pretend you don't know about xref-apropos. >> See above: you assume that the division of functionality between the >> UI and the back-ends is at the right place. > No I don't. I don't assume the API is fixed either. All I assume is > that the UI can't know about the programming language or about the > quality of any given answer, or any such thing. >>> But to me, =22find-tag=22 and =22find-tag-tag=22 are not two different >>> matches to my request. They're just two completely unrelated >>> things: either I'm looking for one or I'm looking for the other. >> Assuming you know what you are looking for, yes. I described a >> situation that is frequent for me where you generally don't, at least >> not well enough to be satisfied by a single exact match. > And that's not what M-. for. For that we have xref-apropos. >> And therein lies its weakness. I actually don't understand how this >> kind of assumption could be allowed to exist, when the =5Fdefault=5F > Because this assumption is known to be obtainable, with help from the > toolchain (the compiler will generally know with 100% certainty the few > possible definitions matching a particular use). > Stefan ------Nodemailer-0.5.0-?=_1-1430555724503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
=E3=81=AB=E3=81=9F=E6=B3=A3=E3=81=8B=E3=81=AD=E3=81=91=E3=81=82= =E3=81=9B=E3=81=91=E3=81=8B=E3=81=8D=E3=81=AD=E3=81=AF=E3=81=8D=E3=81=8B= =E3=81=8D=E3=81=8B

=E2=80=94
Sent from Mailbox


On Fri, May 1, 2015 at 11:21 PM= , Stefan Monnier <monnier@iro.umontreal.= ca> wrote:

> If the back-end conceals potentially useful information, it = should be
> fixed not to do so.

=22Conceal=22 makes it sound like it's ill-intentioned, done on = purpose
or something.

For (defadvice find-tag ...), the problem is in advice.el.
Patches welcome, but since this library is on the way out AFAIC, I'd
recommend you don't bother spending time on it.

> That you personally find that information always redundant = does not
> mean it's true for everyone else. There's more than one use case = for
> these queries, see below.

We can't know what the user wants and handle all conceivable = scenarios.
Maybe the user really wants to jump to this chunk of code somewhere = that
does (fset foo bar) and hence ends up overriding the =22official=22
definition of the function. But unless you can solve the halting
problem and read the user's mind at the same time, we'll have to = settle
for something imperfect.

etags.el also failed miserably in some scenarios which xref/elisp
handles acceptably. E.g. try C-u M-. diff-mode-abrev-table RET.

> That's your misunderstanding. I described my user experience = from
> using this new feature; I never said where the fixes should be = made,

Well, you kept insisting that it's not a question of backend, so = maybe
you didn't say where the fixes should go, but you did say where the = blame
should go.

> Says you. Through my naive-user eyes, filtering 140 hits to = provide
> just a few is perfectly within the capabilities of the UI, at = least in
> principle.

The 140 hits are just a list of locations. The UI has no fucking = clue
whether these are function definitions or what, nor does it know in
which language the file is written.

> IOW, the separation of functionality is in the wrong place. = To be
> useful, some of the =22smarts=22 need to be on the UI side, where = user
> control can be best implemented, and where user intent is known = much
> better.

The UI has to be agnostic. So the smarts can't be in the UI. The = API
can be extended to provide the extra smarts that the UI might need, of
course. E.g. we could add to the API a function that sorts/groups the
entries, so the etags backend can sort them based on =22likelyhood=22 = rather
than group them by file.

> I very much hope Emacs will continue to be able to support the= kind of
> activities I described above, which AFAIK are very important part = of a
> software developer's job throughout the industry.

You fail to understand why complaint about etags.el. I'm not
complaining about `etags', but about the etags.el front-end, which is = in
need of improvement to handle the case where the user is navigating
several completely different projects and doesn't want one to pollute
the other one.

>> I've tried several times to make real use of it, but = always found it
>> completely unpalatable. What with having to build those damn = TAGS
>> files, remember to refresh them, remember where they are, = constantly
>> tell Emacs again where they are, deal with its inability to = find the
>> right spot and having to repeat the =22C-u M-.=22 finger = gymnastics
>> umpteen times.
> Those are exaggerations.

Partly, yes. I'm just venting my frustration with the tool, and
pointing out that if xref/elisp (and xref/etags) has some downsides,
etags.el had its own set of downsides. And some of those shouldn't be
that hard to fix (tho they would probably be a lot easier if we didn't
have to worry about annoying some old-time users because they'd have = to
slightly change their habits).

> Building TAGS is almost instant, even in Emacs,

The problem is not computer-time but human-time.

> you need only refresh them very seldom, and Emacs offers the
> place from which to load them so you don't need to remember.

If Emacs knows where the file is, the user shouldn't need to be = queried.

> But this, again, is immaterial for this discussion. I hope = you will
> agree that, whatever issues we have with etags, replacing it with
> something that lacks important functionality is not a good idea.

As I said, going back to etags.el is not an option.

> That =22little detail=22 all but invalidates most of my use = cases.

Then don't use that backend. E.g. use xref-etags-mode.

>> C-u M-. also lets you do loose matching, via completion, = if your memory
>> is failing you.
> I don't think completion is the right tool for these searches, = because
> the name alone doesn't tell enough.

Don't pretend you don't know about xref-apropos.

> See above: you assume that the division of functionality = between the
> UI and the back-ends is at the right place.

No I don't. I don't assume the API is fixed either. All I assume = is
that the UI can't know about the programming language or about the
quality of any given answer, or any such thing.

>> But to me, =22find-tag=22 and =22find-tag-tag=22 are not = two different
>> matches to my request. They're just two completely unrelated
>> things: either I'm looking for one or I'm looking for the = other.
> Assuming you know what you are looking for, yes. I described a
> situation that is frequent for me where you generally don't, at = least
> not well enough to be satisfied by a single exact match.

And that's not what M-. for. For that we have xref-apropos.

> And therein lies its weakness. I actually don't understand = how this
> kind of assumption could be allowed to exist, when the = =5Fdefault=5F

Because this assumption is known to be obtainable, with help from = the
toolchain (the compiler will generally know with 100% certainty the = few
possible definitions matching a particular use).


Stefan


------Nodemailer-0.5.0-?=_1-1430555724503--