Re: UI inconveniences with M-.

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

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

にた泣かねけあせけかきねはきかきか



—
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.
> "Conceal" 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 "official"
> 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 "smarts" 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 "likelyhood" 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 "C-u M-." 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 "little detail" 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, "find-tag" and "find-tag-tag" 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 _default_
> 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

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