emacs-devel
[Top][All Lists]
Advanced

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

Re: Adding support for xref jumping to headers/interfaces


From: Dmitry Gutov
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Fri, 10 Mar 2023 23:55:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1

On 10/03/2023 02:57, Ergus wrote:
Ho Dmitry and Joao

On March 6, 2023 3:09:40 PM GMT+01:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
On 06/03/2023 01:40, John Yates wrote:
For languages that do not distinguish declaration from definition,
another alternative is to have both key bindings reference the same
find-definition functionality.

Yes please, just fall back to find-definition (or find-references) + a warning 
when find-declaration or the the others are not supported? It is simpler and 
practical.

Could you explain this usage scenario? Why not just report "unsupported" and let the user try again with the simpler key binding (M-.)?

It's not like people will prefer to reach for C-M-?, or will hit it by accident.

Alternatively there could be a default fallback command similar to 
find-references but reordering to list definitions first (just an example)

That sounds harder because at the moment our "reference" items don't have indication of which type they are. So if we wanted this to work well, we'd have to mandate that additional information, and we don't have any good implementation options for either etags or elisp backend that would do that.

I think I would generally prefer for the "find declarations" binding to end 
with an error when unsupported rather than repeat an existing command which is already 
accessible through an easier key binding.

Otherwise some users might waste time wondering over the difference, testing, 
and comparing -- I myself would, probably.


Before binding to a key maybe let's start again with the  simpler: to add them 
in the right click context menu... And we can find a binding later.

We can do both.



reply via email to

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