From: Spencer Baugh <sbaugh@catern.com>
To: emacs-devel@gnu.org
Subject: Re: Adding support for xref jumping to headers/interfaces
Date: Sat, 11 Nov 2023 07:38:37 -0500 [thread overview]
Message-ID: <87r0kw8nxu.fsf@catern.com> (raw)
In-Reply-To: CALDnm511HtDW8oDBwii28WB_dEbRVV6QavPPJPKyw48JvCVgqQ@mail.gmail.com
João Távora <joaotavora@gmail.com> writes:
> On Fri, Nov 10, 2023 at 5:36 PM Spencer Baugh <sbaugh@janestreet.com> wrote:
>> For example, do you expect to support symbol renaming in refactor.el?
>> That if anything seems like something which deserves its own binding.
>
> Yes, it will have its own command, and you can discuss with the
> bindings people to bind it to some key, I won't oppose it.
> refactor-rename is analogous xref-find-definition, it's a concept
> that we're very confident that we can provide in all refactoring
> backends, LSP or not.
>
>> That being said, maybe we could have mode-specific commands and bindings
>> for these things. So if something is supported in a language, a major
>> mode could make a binding for that. And then, just, we might encourage
>> using the same bindings in each mode that binds something.
>
> Aha! Yes, of course. That's the Emacs way. The advent of LSP sometimes
> makes us forget that LSP's tradeoffs are there because LSP doesn't have
> the concept of mode or any kind of programming language. That's why
> it is so stiff sometimes. But we do, we have a existing abstraction
> for dealing with languages, the major mode, a pretty flexible one. And
> we have a mature programming language.
>
>
> This is why indiscriminately borrowing stuff from LSP should really
> be frowned upon. Doesn't mean flat-out reject it, but scrutinized
> because tying ourselves down to LSP's inherent impotence is not
> something we want to do in an editor with our time-proven strengths.
>
> Instead, what we should do is lobby LSP to become more powerful.
> We won't get it to run Elisp, but a lot of things could be done to
> make Emacs/LSP integration even better. Just one example, be able
> to pass an arbitrary identifier to LSP's `textDocument/findFoo`.
>
> But I'm the first one who should be doing that, and I'm not, because
> I just don't have time, and the sad truth is that Emacs doesn't
> carry that much weight over there, unfortunately.
>
> So what we should do in the long IMO is take advantage of Emacs
> inherent advantage for language integrations so undeniably good
> that more users come use it and then we have more negotiating
> power.
>
> So yes, c++-ts-mode can and should define, and possibly bind, all those
> xref.el and refactor.el things that make sense for C++. And if binding
> consistency is a goal, then major mode authors should coordinate. And we
> can even have Elisp constructs that help this coordination and make
> uncoordination difficult.
Oh, this is very convincing. In fact, I am fully convinced.
Major modes should define their own commands for the functionality
supported by that language. So e.g. c-ts-mode could define
c-find-signature, which has a clear meaning for C. And likewise for
refactorings which only make sense in a given language.
And we could reserve single-character bindings under M-' (or something)
for the major mode. For example:
(keymap-set emacs-lisp-mode-map "M-' g" emacs-lisp-find-generic)
(keymap-set c-mode-map "M-' s" c-find-signature)
Reliably using bindings under M-' even if those bindings point to
mode-specific commands is enough consistency for me. Using literally
the same command in each major-mode is not necessary.
That's everything that I wanted from adding xref-find-declaration and so
on in the core, so I agree, actually, we don't need standard kinds in
the core or anything, as long as we actually do something to encourage
common bindings.
(And maybe we could use M-' M-r as a prefix for mode-specific
refactoring commands. Perhaps if we use this M-' prefix it can be the
start of encouraging more binding consistency between programming
language major modes, which I find is something sadly lacking. Maybe at
first there could be a customization which changes M-', and we could
hope to change it by default in a subsequent release.)
next prev parent reply other threads:[~2023-11-11 12:38 UTC|newest]
Thread overview: 204+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-24 19:56 Adding support for xref jumping to headers/interfaces Spencer Baugh
2023-02-24 20:04 ` Eli Zaretskii
2023-02-24 21:29 ` Dmitry Gutov
2023-02-27 23:12 ` Stephen Leake
2023-02-27 23:34 ` Dmitry Gutov
2023-02-28 0:18 ` Yuan Fu
2023-02-28 16:05 ` Filipp Gunbin
2023-03-01 4:33 ` Richard Stallman
2023-03-01 12:50 ` Eli Zaretskii
2023-03-01 17:51 ` John Yates
2023-03-04 18:54 ` Stephen Leake
2023-03-04 22:24 ` Dmitry Gutov
2023-03-05 6:11 ` Eli Zaretskii
2023-03-05 12:06 ` Dmitry Gutov
2023-03-07 22:41 ` Dmitry Gutov
2023-03-08 14:58 ` Eli Zaretskii
2023-03-08 18:23 ` Dmitry Gutov
2023-03-08 19:49 ` Eli Zaretskii
2023-03-08 20:15 ` Dmitry Gutov
2023-03-09 6:13 ` Eli Zaretskii
2023-03-09 13:04 ` Dmitry Gutov
2023-03-09 15:36 ` Eli Zaretskii
2023-03-09 16:53 ` Dmitry Gutov
2023-03-09 17:31 ` Eli Zaretskii
2023-03-09 17:37 ` Dmitry Gutov
2023-05-16 21:10 ` Spencer Baugh
2023-05-17 11:46 ` Eli Zaretskii
2023-06-17 1:53 ` Dmitry Gutov
2023-06-20 15:31 ` João Távora
2023-06-22 19:22 ` Spencer Baugh
2023-06-23 5:52 ` Eli Zaretskii
2023-06-23 14:37 ` Spencer Baugh
2023-06-23 14:53 ` Eli Zaretskii
2023-06-23 15:03 ` João Távora
2023-06-28 13:31 ` Spencer Baugh
2023-11-04 22:43 ` Dmitry Gutov
2023-11-04 22:00 ` Dmitry Gutov
2023-11-04 22:24 ` João Távora
2023-11-04 22:29 ` Dmitry Gutov
2023-11-04 22:36 ` João Távora
2023-11-04 23:20 ` Dmitry Gutov
2023-11-04 23:16 ` Dmitry Gutov
2023-11-04 23:21 ` Dmitry Gutov
2023-11-04 23:24 ` João Távora
2023-11-04 23:27 ` Dmitry Gutov
[not found] ` <CALDnm51sWvw4wiipYkJRB8za_8zpWg2-0jpoJDy_5urEa5okzQ@mail.gmail.com>
[not found] ` <2752892c-4d27-1249-ca0a-6c24abbf1078@yandex.ru>
[not found] ` <CALDnm51P5kfWNofybvxbzVZNnF9DwV5f2ZDGx9ziToBF7cJR6w@mail.gmail.com>
[not found] ` <e043f63b-e997-805b-7f9a-64dcc0a9062e@yandex.ru>
[not found] ` <87zfzrybl1.fsf@gmail.com>
[not found] ` <57e53aae-bef9-d267-f7da-d4936fc37153@yandex.ru>
2023-11-07 9:36 ` João Távora
2023-11-07 22:56 ` Dmitry Gutov
2023-11-08 0:14 ` João Távora
2023-11-05 8:16 ` Eshel Yaron
2023-11-07 2:12 ` Dmitry Gutov
2023-11-07 17:09 ` Spencer Baugh
2023-11-07 23:02 ` Dmitry Gutov
2023-11-07 21:30 ` Eshel Yaron
2023-11-07 23:17 ` Dmitry Gutov
2023-11-08 0:21 ` João Távora
2023-11-08 0:33 ` Dmitry Gutov
2023-11-08 1:19 ` João Távora
2023-11-08 22:58 ` Dmitry Gutov
2023-11-08 23:22 ` João Távora
2023-11-08 23:34 ` Dmitry Gutov
2023-11-09 0:50 ` João Távora
2023-11-09 16:59 ` Spencer Baugh
2023-11-09 20:44 ` João Távora
2023-11-09 21:11 ` Spencer Baugh
2023-11-10 10:06 ` João Távora
2023-11-10 12:02 ` Spencer Baugh
2023-11-10 13:59 ` João Távora
2023-11-10 17:36 ` Spencer Baugh
2023-11-11 10:45 ` Dmitry Gutov
2023-11-11 11:17 ` João Távora
2023-11-11 12:38 ` Spencer Baugh [this message]
2023-11-11 20:49 ` Dmitry Gutov
2023-11-15 21:32 ` Spencer Baugh
2023-11-24 1:37 ` Dmitry Gutov
2023-11-24 21:43 ` Felician Nemeth
2023-11-25 2:20 ` Dmitry Gutov
2023-11-26 16:08 ` Felician Nemeth
2023-11-26 20:15 ` Dmitry Gutov
2023-11-26 20:37 ` João Távora
2023-11-27 14:35 ` Dmitry Gutov
2023-11-27 15:03 ` João Távora
2023-11-27 15:45 ` Dmitry Gutov
2023-11-27 16:04 ` João Távora
2023-11-27 16:23 ` Dmitry Gutov
2023-11-27 16:41 ` João Távora
2023-11-27 17:05 ` Dmitry Gutov
2023-11-27 17:09 ` João Távora
2023-11-26 20:40 ` João Távora
2023-11-27 14:43 ` Dmitry Gutov
2023-11-27 14:49 ` João Távora
2023-11-27 15:01 ` Dmitry Gutov
2023-11-27 15:19 ` João Távora
2023-11-28 0:18 ` Dmitry Gutov
2023-11-28 9:51 ` João Távora
2023-11-28 12:45 ` Dmitry Gutov
2023-11-28 15:02 ` João Távora
2023-11-28 16:32 ` Dmitry Gutov
2023-11-28 17:16 ` João Távora
2023-11-28 17:25 ` Dmitry Gutov
2023-11-28 18:38 ` João Távora
2023-11-27 15:28 ` Eli Zaretskii
2023-11-27 16:37 ` Dmitry Gutov
2023-11-27 16:45 ` João Távora
2023-11-27 17:40 ` Eli Zaretskii
2023-11-27 18:26 ` Dmitry Gutov
2023-11-27 20:50 ` Eli Zaretskii
2023-11-27 20:53 ` Dmitry Gutov
2023-11-26 20:30 ` João Távora
2023-11-27 15:17 ` Dmitry Gutov
2023-11-27 15:45 ` João Távora
2023-11-27 16:04 ` Dmitry Gutov
2023-11-27 16:27 ` João Távora
2023-11-27 17:22 ` Dmitry Gutov
2023-11-27 17:46 ` João Távora
2023-11-27 18:12 ` Dmitry Gutov
2023-11-27 23:25 ` João Távora
2023-11-28 0:30 ` Dmitry Gutov
2023-11-28 0:43 ` João Távora
2023-11-11 1:01 ` Dmitry Gutov
2023-11-11 1:04 ` Dmitry Gutov
2023-11-11 11:30 ` João Távora
2023-11-11 21:01 ` Dmitry Gutov
2023-11-12 18:40 ` João Távora
2023-11-13 0:27 ` Dmitry Gutov
2023-11-13 1:03 ` João Távora
2023-11-13 1:05 ` Dmitry Gutov
2023-11-13 1:16 ` João Távora
2023-11-13 1:41 ` electric-pair-mode vs paredit, was: " Dmitry Gutov
2023-11-13 1:53 ` João Távora
2023-11-11 0:58 ` Dmitry Gutov
2023-11-11 11:44 ` João Távora
2023-11-11 21:37 ` Dmitry Gutov
2023-11-12 18:59 ` João Távora
2023-11-13 1:37 ` Dmitry Gutov
2023-11-11 1:08 ` Dmitry Gutov
2023-11-11 11:22 ` João Távora
2023-11-11 20:54 ` Dmitry Gutov
2023-11-08 16:11 ` Spencer Baugh
2023-11-08 17:20 ` João Távora
2023-11-08 17:40 ` Spencer Baugh
2023-11-08 23:08 ` João Távora
2023-11-09 16:52 ` CCing thread participants through gnus+gmane Spencer Baugh
2023-11-10 15:51 ` Eric Abrahamsen
2023-11-10 16:18 ` Visuwesh
2023-11-09 17:07 ` Adding support for xref jumping to headers/interfaces Spencer Baugh
2023-11-11 0:07 ` Dmitry Gutov
2023-11-11 12:39 ` Spencer Baugh
2023-11-11 20:45 ` Dmitry Gutov
2023-11-08 23:06 ` Dmitry Gutov
2023-11-07 16:51 ` Spencer Baugh
2023-11-07 23:30 ` Dmitry Gutov
2023-11-08 17:25 ` Spencer Baugh
2023-11-09 0:08 ` Dmitry Gutov
2023-11-09 0:26 ` Dmitry Gutov
2023-11-09 1:06 ` João Távora
2023-11-11 0:16 ` Dmitry Gutov
2023-11-09 17:57 ` Spencer Baugh
2023-11-11 0:42 ` Dmitry Gutov
2023-11-11 13:00 ` Spencer Baugh
2023-11-12 1:50 ` Dmitry Gutov
2023-11-12 2:08 ` João Távora
2023-11-12 2:09 ` Dmitry Gutov
2023-11-12 2:25 ` João Távora
2023-11-13 1:02 ` Dmitry Gutov
2023-11-13 1:24 ` João Távora
2023-03-01 15:00 ` [External] : " Drew Adams
2023-02-28 21:40 ` John Yates
2023-02-28 21:53 ` Dmitry Gutov
2023-02-28 22:44 ` Konstantin Kharlamov
2023-03-05 9:59 ` Helmut Eller
2023-03-05 12:03 ` Dmitry Gutov
2023-03-05 15:57 ` Helmut Eller
2023-03-05 16:33 ` Dmitry Gutov
2023-03-05 17:19 ` Stephen Leake
2023-03-05 20:10 ` João Távora
2023-03-05 20:32 ` João Távora
2023-03-05 20:40 ` Dmitry Gutov
2023-03-05 21:04 ` João Távora
2023-03-05 21:21 ` Dmitry Gutov
2023-03-05 21:48 ` João Távora
2023-03-05 22:08 ` Dmitry Gutov
2023-03-05 23:00 ` João Távora
2023-03-05 23:40 ` John Yates
2023-03-06 12:22 ` Felician Nemeth
2023-03-06 13:15 ` João Távora
2023-03-06 13:23 ` Dmitry Gutov
2023-03-06 13:38 ` João Távora
2023-03-06 13:46 ` Dmitry Gutov
2023-03-06 13:52 ` João Távora
2023-03-06 13:50 ` Dmitry Gutov
2023-03-07 7:15 ` Yuan Fu
2023-03-07 19:58 ` Felician Nemeth
2023-03-07 20:44 ` Yuan Fu
2023-03-07 21:03 ` Dmitry Gutov
2023-03-06 14:09 ` Dmitry Gutov
2023-03-06 14:15 ` John Yates
2023-03-06 14:23 ` Dmitry Gutov
2023-03-06 14:43 ` John Yates
2023-03-10 0:57 ` Ergus
2023-03-10 21:55 ` Dmitry Gutov
2023-03-10 22:18 ` João Távora
2023-03-10 22:25 ` Dmitry Gutov
2023-03-11 11:50 ` João Távora
2023-03-10 23:45 ` Ergus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87r0kw8nxu.fsf@catern.com \
--to=sbaugh@catern.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.