Re: [Emacs-diffs] master d7df36e: Rewrite elisp--xref-find-definitions to handle many more cases; add tests.

[Dmitry Gutov]

On 08/12/2015 02:30 AM, Stephen Leake wrote:

> > How come you saw fit to undo the tweaks that I've added over time?
>
> Because they got in the way of some of my uses of xref-find-definitions.

At least a question would've been nice.

> In general, rather than using similar heuristics in the low level code,
> we should be adding hints from the source being searched, and/or the
> user.

In general, elisp-xref doesn't open the source files. When used with 
xref-find-apropos, that was rather slow.

> For example, one heuristic returned only the function when there are
> both function and feature with the same name. But there are times when I
> want to see both, or one or the other.

If the feature and the function have the same name, idiomatically, they 
will always be in the same file. Why wouldn't you want to jump to the 
function? If it's not right, M-< is not too far away (or M->, as per below).

I see you're also jumping to the (provide 'xxx) forms. What's the use in 
that?

> So if I'm searching for the
> identifier at point, in code like this:
>
>          (dvc-log-edit ...) ;; point on '-l'; show defun
>          (require 'dvc-log-edit) ;; point on '-l'; show feature
>
> In both cases, we can easily tell from the source near point what the
> user is searching for.

Right, it's a good default behavior. But then we'll have to decide how 
the user could indicate whether elisp-xref should *not* look at the 
context. Currently, C-u only forces the prompt to appear, but the 
default value will still use the text properties from the context (if 
xref-default-identifier-at-point includes them).

> Yes. But I thought the heuristic the previous code used was: "if there
> is both a variable and a function by the same name, _assume_ they are
> located in the same place, so only return the function". That assumption
> is broken for some of my code, and I assume in many others as well.
>
> However, you point out later that you used (memq sym minor-mode-list) to
> determine if this is from define-minor-mode.
>
> I didn't realize why that was there when reading the code.
>
> So I'll put that back, with a comment this time :).

There was a comment: "Don't show minor modes twice". I thought it 
explained the purpose of (not (and (fboundp sym) (memq sym 
minor-mode-list))) clearly enough.

And even if the code is not commented, one can try to preserve the part 
that aren't obviously in need of change.

> The other one is find-alias-regexp.
>
> Yes; then other code could use it as well. Should the default value of
> find-function-regexp-alist contain them? I don't see any harm in that.

I guess so.