Use elisp--xref-backend in *Apropos* and *Help* (Was Re: [ELPA] New package: transient)

[João Távora]

Since we're on the subject of Elisp development help, can we restart the
discussion on how to get the `elisp--xref-backend` activated in *Apropos*
and help?  The default `etags--xref-backend` isn't very useful there.  Plus,
when one is used to M-. and M-, it's a little strange to have to switch to C-h o
to follow the very commonly occurring references to symbols.

I recall correctly, we had already settles that it's a decently good idea,
but we ran into some loading precedence problem and the effort stalled.
Is that the right recollection?  It doesn't seem to make a lot of sense,
since all we apparently need is `add-hook`.

Anyway, it can be argued that `elisp--xref-backend` isn't the _best_ choice
for those buffers, and that we should be taking the user to say, the manual
when searching from those places.  Or maybe, the `elisp--xref-backend` could
also collect matches from the manual, why not?

Thanks,
João

On Sat, May 2, 2020 at 11:57 AM Philippe Vaucher
<address@hidden> wrote:
>>
>> > My original use case is: I want to copy an association list, I know the 
>> > function will probably have "copy" in its
>> > name and "alist", let's C-h f for "alist TAB" and fail because no results. 
>> > Start again with "copy TAB" and filter
>> > the lots of "copy-*" function until I find copy-alist.
>>
>> "C-u C-h a copy alist RET" finds that function as the single hit.  As
>> does "C-u C-h a alist copy RET".
>
>
> Right, that works well. Thanks. It's not the most obvious keybinding but "C-h 
> d copy alist" also works.
>
>
>>
>> > Now imagine if this particual function was named "asscpy"
>> > instead how frustrated I'd be :-)
>>
>> You will be frustrated because you use the wrong command.  "C-h f" is
>> not your friend unless you have a very good idea of the function's
>> name.  That's why "apropos" family of commands were invented: to help
>> you find something you don't know by name.  There's a best tool for
>> each job, and "C-h f" is not a good tool for this job.
>>
>> But I already said that, several times.  And since you still disagree,
>> then I must insist that my response to Richard was spot-on: he asked
>> why doesn't "C-h d" do the job, and my response was, in a nutshell,
>> that what "C-h d" does is not relevant for you and other users who
>> think and are accustomed to work like you do.  You disagreed with my
>> conclusion, but we now made one more full circle, and established that
>> my conclusion was correct after all.
>
>
> I think we are mixing two concepts here. To search for a single function, 
> where you already know the keywords, yes "C-h d" works. To get a curated list 
> of the API of a topic, not so much. Because my examples mix both finding a 
> specific function and getting the curated list, I guess we were each talking 
> about the specific function example and I want talking about the curated list.
>
> I still think "C-h d alist", because it does not give me assq and assoc is 
> not doing a good job.
>
> Because alist is controversial let's take "C-h d regexp match": it does not 
> give me string-match nor match-string. If I search for "regex match" then I 
> find match-string.
>
> But overall I understand your point better now, you are not supposed to use 
> "C-h d" to get a curated list of the api of a topic, it's just to find a 
> single function. For that I agree it's a good tool.
>
>
>>
>> > Also imagine how self-documenting and self-discoverable Emacs Lisp would
>> > be if things where properly namespaced, like we ask for all packages to be 
>> > on MELPA/ELPA and friends.
>>
>> I'm not objected to have aliases that would make it easier to find out
>> the function's name using simple completion, but I think you greatly
>> overestimate the usefulness of that in many practical situations.
>> Meanwhile there are existing features designed specifically for these
>> use cases, which do their job much more efficiently _today_, and you
>> choose to disregard them or treat them as second-class citizens.  I
>> think it's a mistake, but I can only make suggestions and point out
>> that those features do exist.
>
>
> I'm still not very satisfied about the tools you showed for listing an 
> overview of the API to manipulate regexp, or files, or processes (etc). What 
> you are basically saying is that wanting to have this overview is overrated, 
> but for me it helps me understand the landscape of how the API works and is 
> designed. What functions would be available should I need them in the future, 
> what parts is missing, etc.
>
> For now the only tool I have is the manual page with "M-x keep-lines -- 
> function".
>
>
>>
>> > As said earlier, probably that my way of thinking is not common around 
>> > here, but I'd not be surprised if it was
>> > common for many developpers, maybe outside Emacs Lisp.
>>
>> My earnest advice for those developers is to try the features I
>> mentioned, they might find them useful in situations similar to the
>> one you described, and they might then decide to use them more than
>> what they do today.
>
>
> I'll certainly start to use it more.
>
> Thanks,
> Philippe



-- 
João Távora