Re: Adding support for xref jumping to headers/interfaces

[Yuan Fu]

> On Mar 7, 2023, at 11:58 AM, Felician Nemeth <felician.nemeth@gmail.com> 
> wrote:
> 
> Yuan Fu <casouri@gmail.com> writes:
> 
>>> There's also the issue of assigning keys to them (for tmm-menubar
>>> alike interface), which might be harder to do automatically.
>>> 
>>> We could just do completing-read, but that's bound to be slower to work 
>>> with.
>>> 
>> 
>> I like the idea of xref-find-extra. For keys we can support both
>> auto-compute (use first character) and backend-chosen keys, similar to
>> read-multiple-choice. We can even allow users to customize it.
> 
> I think this approach might be problematic if the major-mode provides a
> "declaration" type and, say, Eglot provides a "definition" type.  But
> maybe, as you write, providing customization options to the users is a
> simple solution in this rare case.

We can provide a standard set of names & keys for common types and describe 
them in the docstring and manual, and ask major modes to follow it to their 
best effort. This way the common ones should be more or less consistent, and 
major modes are free to add specialized types.

> 
>> Completing-read is a bad idea, as you said, it’s going to be slow,
>> much slower and less pleasant to use.
> 
> Currently all I write are emails, but long ago I wrote a simple,
> tmm-based completing-read function to overcome this problem.  Maybe that
> approach is useful here as well:
> https://github.com/nemethf/single-key-completion/
> 

Very cool! I’ve been thinking about a “reduced M-x” that only shows a selected 
subset of the command that I use regularly, and use fast keys to pick 
candidates. This seems to fit that purpose.

Yuan