[Top][All Lists]

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

Re: force initialization of a datatype?

From: Dmitry Gutov
Subject: Re: force initialization of a datatype?
Date: Sat, 7 Nov 2015 22:21:59 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:42.0) Gecko/20100101 Thunderbird/42.0

On 11/07/2015 08:30 PM, Stephen Leake wrote:

Why can't we reuse the contents of those variables?

`help-fns-describe-function-functions' is intended to be called from
'describe-function'; it puts the results in a buffer.

Indeed, I (mistakenly) meant the other one.

`elisp-xref-find-def-functions' puts the results in a list of xrefs. So
the code is different.

After looking at it more, I mostly agree. It has a distinct value: determining additional "type-and-file" combinations corresponding to the symbol in question, or something along these lines. (1)

Which extend the behavior of elisp--xref-find-definitions, which currently iterates over variables, functions, faces and aliases.

Not all entries on `elisp-xref-find-def-functions' have a corresponding
entry in `find-function-regexp-alist'; they are not equivalent.

The other entries seem to have their equivalents inside the elisp--xref-find-definitions definition. That probably means something.

A difference between the list of things xref can display and those that
describe-function can display is a bug (that includes more than just
those two lists).

What about M-x find-function not finding certain definitions that xref-find-definitions can? I don't exactly have a solid idea for improvement, but it seems like xref-mode-local-overload returns a set of xrefs pointing to locations that M-x find-function can't jump to.

It'll only jump to the "original" function definition, right?

> ...
There were a lot of such bugs when xref was introduced.

I've fixed some of them with `elisp-xref-find-def-functions', others
with other code in elisp--xref-find-definitions. There are still
a few remaining; see the FIXMEs in elisp-mode.el.

Thank you.

The only relevant FIXME I see now mentions advised functions.

You seem to be suggesting that there should be a way to write one
function for both lists; that's certainly not possible.

You're right.

We might be able to switch to a dispatching "display-function", with
one backend for help buffers and one for xrefs. But that does not change
the essential point that different code needs to be written for both.

Yes, we need different code to "display" the entities: convert them to xrefs on one side, and convert them to help buffer contents on the other side.

The code that produces the list of the entities, however, could be unified.

I'm not sure that help-fns-describe-function-functions is a close counterpart to elisp--xref-find-definitions, however (2). describe-symbol-backends seems to be closer to that.

(1) For that reason, the current name of this variable doesn't seem fitting: the functions don't find "definitions", they find distinct entities bearing the given name. The actual finding of definitions is delegated to find-func and its hooks.

(2) help-fns-describe-function-functions's purpose seems to be more along the lines of adding extra blurbs to the description of the same entity.

reply via email to

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