Re: xref backends for elisp-related modes Was: Re: Bad moves with xref-find-definitions

[joaotavora@gmail.com (João Távora)]

Vitalie Spinu <spinuvit@gmail.com> writes:

>  >>> Eli Zaretskii on Sun, 26 Apr 2015 17:51:18 +0300 wrote:
>
>  > Beware: quite a few commands pop up *Help* buffers whose contents have
>  > nothing to do with Lisp.  Some examples:
>
>  >   . C-u C-x =
>  >   . C-h C-\
>  >   . M-x describe-current-coding-system RET
>
>  > etc.
>
> It's because help-mode is not specialized enough. I think there should
> be `elisp-help-mode`,  `describe-help-mode` etc. which are derived from
> `help-mode`.

Maybe yes. But anyway Eli's right, some help contexts have nothing to do
with elisp. I see two options:

1) I like this derived mode approach. To implement it perhaps we could
   make `help-mode-setup' call some `help-mode-setup-function' so that
   `with-help-window' does the right thing. Then we set this var in the
   contexts we want. If this is the chosen approach, what should
   `help-mode-setup-function' default to? Perhaps the mew derived
   `elisp-help-mode' since that minimizes the number of describe-*'s to
   touch.

2) Otherwise, we have to explicitly reset the backend on a per-context
   basis. Now, should the default for help mode be `elisp-xref-find' and
   we reset those three, or the other way around? Is my previous
   (advice-add describe-thingy :after ...) strategy acceptable for this?

(BTW: the fix for apropos-mode and debugger-mode is not controversial
right?)

> Maybe obvious, but this struggle with the choice of the
> default backend wouldn't be there if xref was able to merge backends.

I don't see how. How would we remove elisp-xref-find as a backend in
certain help-mode contexts without touching the code where such
contexts are setup.

> (FWIW, I would also like to have elisp xref in info mode.)

But only for the elisp manual, right?

João