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: Ergus
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Sat, 11 Mar 2023 00:45:03 +0100


On March 10, 2023 10:55:24 PM GMT+01:00, Dmitry Gutov <dgutov@yandex.ru> wrote:
>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.
>

It is mostly conceptual. In the languages without declarations generally the 
declaration IS the definition itself.


>> 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 understand... I was thinking in a dumb check of coincidences between 
references and definitions list. Implying to call both and a side to side 
comparison ... But it doesn't worth it probably....


>
>>> 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.

I am very excited to see this feature working...

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


reply via email to

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