bug#19468: 25.0.50; UI inconveniences with M-.

[Eli Zaretskii]

> Cc: 19468@debbugs.gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Fri, 1 May 2015 05:27:18 +0300
> 
> On 04/30/2015 04:48 PM, Eli Zaretskii wrote:
> 
> > I believe the default in Emacs is to use caseless searches in these
> > situations, and leave it to the user to either customize
> > case-fold-search or type the exact letter-case if she wants such exact
> > matches.  With languages that customarily use both letter-cases, I see
> > no reason to deviate from that practice.
> 
> Yeah, that still works like that. "Followed by any matches ... but for 
> letter-case" simply means to me to use case-insensitive matching in the 
> first place, since the backend doesn't return matches in groups.

I'd still suggest to place the exact matches first.  The UI could do
that.

> > If it can't, it's probably because no one coded that.  But the rules
> > are not so complex, so it's not inconceivable that such code could
> > exist in the UI.
> 
> Still, that doesn't sound like a good idea. Backends know their 
> languages better.

I don't see anything language-specific here.  Etags.el has no
language-specific knowledge, either (it is delegated to etags.c).

Like I said elsewhere, I think making the UI too dumb might give us
sub-optimal design, wrt how functionality is divided between the UI
and the back-ends, and in particular produce more of unhappy user
experiences caused by the UI relying on the back-ends too much, and
the back-ends differing between them too much.

Case sensitivity, partial matches, and other similar stuff employed by
etags, and conceptually by any other similar facility, has almost
nothing to do with languages.  And if (and when) we want to support
match rules that do depend on languages, the API should allow
specifying such rules to the back-end, and the back-end should DTRT
when it receives a spec it cannot support.  For example, if the UI
requests only exact letter-case match, and the back-end is for a
case-insensitive language, that back-end should produce caseless
matches nonetheless.

> > Why not learn from find-tag-tag-order, and allow the same categories
> > of matches as it uses, sans those that make no sense outside of the
> > TAGS data?
> 
>  From where I'm standing, that's a customization preference, not a 
> design suggestion. The latter would include a proposal of changes to the 
> xref-find-function interface.

I stopped short of providing a complete proposal.  My design
suggestion is to generalize and abstract the match types used by
etags.  Customization preferences might then control which subset of
the set of match types are used for each query.