bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#28439: suggestion: support case-independent xref-find-definitions pr


From: Dmitry Gutov
Subject: bug#28439: suggestion: support case-independent xref-find-definitions prompt TAB
Date: Tue, 19 Sep 2017 03:55:34 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Thunderbird/56.0

On 9/14/17 8:01 PM, Eli Zaretskii wrote:

Sorry, what don't we want to follow the value of completion-ignore-case?

Because it has a much broader effect.

I guessed so. But do you have a particular problem in mind?

And because the issue here is
inconsistency between completion and actual matching in
xref-find-definitions.  They should be consistent, IMO.

I think I agree, because xref--read-identifier calls completing-read with nil require-match argument (so we can't rely on the completion table to correct the input), but your patch doesn't fix the inconsistency. It only moves the identifier read toward the case-fold-search default.

The fact that we have the option tags-case-fold-search (used in
find-tag-tag, among other places) probably means that some users prefer
not to ignore case.

Then maybe an alternative is to make tags-case-fold-search nil by
default? Or make xref--read-identifier be case-insensitive if
case-fold-search is non-nil?

The other way around: etags--xref-find-definitions can bind tags-case-fold-search to the value of completion-ignore-case. Or whichever xref-specific variable we add.

We'd also need to add case-insensitive search support to elisp--xref-find-definitions, I suppose. So far, find-function-search-for-symbol always performs case-sensitive search. It's rarely a problem, though, because Elisp uses capital letters very infrequently.

Maybe we could add a similar xref-specific option on top, but I'm not
sure why completion-ignore-case is not good enough.

We could change its default to t, though.

Emacs-wide?  Or just when completing on identifiers?

Either is fine, as far as I'm concerned.





reply via email to

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