[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#19468: 25.0.50; UI inconveniences with M-.
Date: Thu, 30 Apr 2015 16:48:20 +0300

> Cc: address@hidden, address@hidden
> From: Dmitry Gutov <address@hidden>
> Date: Thu, 30 Apr 2015 01:56:40 +0300
> On 04/29/2015 06:46 PM, Eli Zaretskii wrote:
> > I'd suggest first an exact match, followed by any matches that are
> > exact but for letter-case.
> I think we've settled on "only exact matches" (to the best of backend's 
> ability) for xref-find-definitions.

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.

> However, in xref-find-apropos we shouldn't like the exact matches that 
> much, and likely care about all matches.


> In that command's output we could use the order in which etags
> returns its results.

I agree.

> >> Without using the order, in which matches are returned by the backend, we 
> >> can't even know what the "best matches" are.
> >
> > Of course, we can: see above.
> The backend can. The UI can't, thus far (unless only the best matches 
> are returned to it).

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.

> > Moreover, ideally the API to the back-end should allow the UI to
> > control the matches applied by the back-end, so that the UI gets only
> > the matches it wants in the first place.
> Would you like to describe it in more detail? The current main options 
> are: "give me matches for this name" and "give me matches for this 
> regexp". There's nothing that would correspond to find-tag-tag-order.

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?

> > In general, I think it would be good to have a user option that
> > controls which predicates are used by the etags back-end.  I think we
> > should group the predicates into meaningful groups (e.g., it makes no
> > sense to use tag-exact-match-p without tag-implicit-name-match-p).
> > The default list of the predicates should IMO include these:
> >
> >    tag-exact-match-p tag-implicit-name-match-p tag-symbol-match-p
> See the newly added defvar `etags-xref-find-definitions-tag-order'.
> The last element seems a bit too lax to me, but it's up to you.

Thanks, I will take a look soon.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]