Re: UI inconveniences with M-.

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Fri, 01 May 2015 10:21:04 -0400
> 
> > 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.

Not according to my references.

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

Isn't that what I said?

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

Emacs has a school-book solution for these problems: let the user
specify what she wants, with prefix arguments and user options.

My point was that a back-end that isn't prepared for such degree of
control, and decides for the user what she wants is not just
"imperfect", it's semi-broken.

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

I don't see diff-mode-abrev-table in TAGS, so I don't understand what
you want to demonstrate with that.

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

No, I said that blaming the back-end for what I observed, and saying
that nothing can be done "because that's what the back-end gives" is
not the right way of approaching these kinds of problems.

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

The 140 hits are symbol names, not just locations.  Discerning between
exact matches, caseless matches, and partial matches does not need any
language-specific knowledge.  I don't understand what problems you see
here.

But if you are certain that the fixes belong to the back-end, it's
fine with me.  Just don't tell me that the back-end is to blame, and
therefore there's nothing that can be done.

> > 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 question is which smarts.  I'm saying that the UI cannot blindly
trust the back-end to always DTRT, it needs to control it according to
its needs and user preferences.  These smarts _must_ be in the UI.
Having just 2 or 3 query types -- either get me only one match or give
me all of them -- is too rough, there must be more shades of gray, and
more ways for the user to extend and refine the query.

The old API provided an approximation to this by returning a long list
in order of importance, so where you stopped asking for more was a
rather crude, but usually effective way of getting exactly what you
wanted.  This is now gone, so we must find other, hopefully better
ways of giving the user the same fine-grained control on what she gets
in response to a query.

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

This issue is tangential to the subject f this discussion.  My
complaints are valid even if you work with a single project, and in
fact were observed while working with a single project.

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

Irrelevant.  I wasn't saying etags was better, or didn't have
disadvantages.  I was talking about deficiencies of the current
solution, as a whole, for looking up definitions of symbols.  I don't
really care which back-end is used for that, but I do care about the
results, and I do care when if I switch back-ends and suddenly get
very different results.

> (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).

Yes, I'm an annoying guy.  Feel free to ask me to step down and
disappear from here, if that annoys you too much.  (The profanities
are already a sign of that.)

> > Building TAGS is almost instant, even in Emacs,
> 
> The problem is not computer-time but human-time.

What human time?  The time it takes to type "make TAGS"?

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

Emacs can guess where the user _might_ want it, but it has to allow
for seldom exceptions, otherwise how can the user switch to another
project or add its data to the current one?

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

It's definitely an option for this curmudgeon, if the new-and-improved
solution will not become better.

> > That "little detail" all but invalidates most of my use cases.
> 
> Then don't use that backend.  E.g. use xref-etags-mode.

Are we again talking about my personal problems?  If they are only
mine, I can solve them very easily, and don't need this discussion or
the bug reports to do so.

What do you tell users whose use case is similar to mine?  "Use
xref-etags-mode"?  Then why did we switch away of etags.el, if we
still need to use its core machinery?

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

I don't want 2 different commands.  I know about etags-apropos as
well, but never used it, because I never needed to.  Forcing me to use
2 different commands where I could use one is an annoyance.

Anyway, I'm out of this discussion.  Good luck selling your ideas and
use cases to others.  I'm not sold.  And I don't enjoy having to read
uncalled-for profanities in response to legitimate questions and
issues.