[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.
- Re: Adding support for xref jumping to headers/interfaces, (continued)
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/03/07
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/03/06
- Re: Adding support for xref jumping to headers/interfaces, John Yates, 2023/03/06
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/03/06
- Re: Adding support for xref jumping to headers/interfaces, John Yates, 2023/03/06
- Re: Adding support for xref jumping to headers/interfaces, Ergus, 2023/03/09
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/03/10
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/03/10
- Re: Adding support for xref jumping to headers/interfaces, Dmitry Gutov, 2023/03/10
- Re: Adding support for xref jumping to headers/interfaces, João Távora, 2023/03/11
- Re: Adding support for xref jumping to headers/interfaces,
Ergus <=