In case anyone’s wondering for Emacs with xref via Eglot (since I just checked):
M-. is the usual xref-find-definitions, i.e., in-place. (This one I use all the time.)
C-x 4 . is xref-find-definitions-other-window which will make a split if needed or reuse an existing one, then move the cursor to the new split. (This one was new to me.)
I wasn’t aware that this was a default action in VSCode! I’ve fiddled with manually setting up my splits and jumping around code before, so this’ll be a nice little time save
For those curious, the default binding is “Ctrl-K F12” (I had trouble finding it, the command name is “Open Definition to the Side” in the command palette). I might try to find a better binding, but I don’t think I can sacrifice my comma key for it!
I can’t imagine not having some sort of “go to … in split”. Navigation around a complex codebase is always extremely disorienting for me.
There is another feature I really miss from Emacs and can’t quite find a replacement of in vs code: narrowing. I want to be able to visually remove everything from a file except for the function/class/arbitrary region of interest. Otherwise, again, it feels disorienting to not be able to see boundaries of code elements clearly.
Never used narrowing specifically even while I used Emacs exclusively, but one absolutely massive thing that is missing from VS Code (and, by unfortunate extension, from LSP) is the ability to always keep function bodies folded, the “fold method bodies by default” checkbox from IntelliJ. That is, not to fold a specific “level”, but rather fold functions specifically, leaving their headers intact, and keep this folding by default while you are navigating across the files.
Hopefully this kind of UI now becomes more mainstream now that any editor can just use tree sitter to find out which regions are bodies.
I just came across this VSCode-based editor called Haystack, which among other things allows to “focus” on a portion of a file! https://haystackeditor.com/
Oh yeah, narrowing is really great and I miss that workflow a lot. There’s also the Smalltalk class browser, where you had your Miller columns of code structure, and ended up with a single method in your editing window. (I think Eclipse had something similar for Java, but I don’t see that in contemporary IDEs a lot, never mind the absence of sub-class/-module organizational structures).
And of course narrow-to-region goes beyond just functions & methods, when you really want to look just at a single part of this. And no, I don’t think XP-style overuse of method extraction is the solution here, that’s basically a permanently narrowed view without a good option of getting the context (and inner-procedural refinements or literate programming seem to be way out of the computing mainstream, too).
In vim and neovim<C-w>] will go to the definition of the symbol under the cursor. Like most editors (including VS Code?), they rely on another tool to tell them where to go. So you need either ctags or an LSP to make this effective. I find <C-w>] most powerful with an LSP, so in that context I map it to something easier to type (gs, mnemonic “Go to…in Split”). (Neovim has been adding a lot of helpful LSP defaults lately, but I don’t think that there is a default mapping for <C-w>] yet. But I may be wrong.)
vim.api.nvim_create_autocmd("LspAttach", {
callback = function(ev)
-- ...
local keymap_opts = { remap = false, silent = true, buffer = ev.buf }
-- ...
-- Jump to definition of item under cursor, but in a split.
vim.keymap.set("n", "gs", "<C-w>]", keymap_opts)
-- ...
end,
})
(Edit: apologies to sluongng. I started this comment last night and didn’t see their comment until after I hit submit.)
This made me want to check how to do “Go to definition” in a separate split in Neovim and it’s built-in lsp client:
Crtl-W ]will open up the definition in a new split and place your cursor onto the new split.Ctrl-W }will open up the definition in a new split but keep your cursor where it is currently.In case anyone’s wondering for Emacs with xref via Eglot (since I just checked):
M-.is the usualxref-find-definitions, i.e., in-place. (This one I use all the time.)C-x 4 .isxref-find-definitions-other-windowwhich will make a split if needed or reuse an existing one, then move the cursor to the new split. (This one was new to me.)I wasn’t aware that this was a default action in VSCode! I’ve fiddled with manually setting up my splits and jumping around code before, so this’ll be a nice little time save
For those curious, the default binding is “Ctrl-K F12” (I had trouble finding it, the command name is “Open Definition to the Side” in the command palette). I might try to find a better binding, but I don’t think I can sacrifice my comma key for it!
Oh this is quite helpful. Command Palette + “defside” uniquely identifies this command, and I’ll probably use that rather than set a new binding.
I can’t imagine not having some sort of “go to … in split”. Navigation around a complex codebase is always extremely disorienting for me.
There is another feature I really miss from Emacs and can’t quite find a replacement of in vs code: narrowing. I want to be able to visually remove everything from a file except for the function/class/arbitrary region of interest. Otherwise, again, it feels disorienting to not be able to see boundaries of code elements clearly.
Never used narrowing specifically even while I used Emacs exclusively, but one absolutely massive thing that is missing from VS Code (and, by unfortunate extension, from LSP) is the ability to always keep function bodies folded, the “fold method bodies by default” checkbox from IntelliJ. That is, not to fold a specific “level”, but rather fold functions specifically, leaving their headers intact, and keep this folding by default while you are navigating across the files.
Hopefully this kind of UI now becomes more mainstream now that any editor can just use tree sitter to find out which regions are bodies.
I just came across this VSCode-based editor called Haystack, which among other things allows to “focus” on a portion of a file! https://haystackeditor.com/
Oh yeah, narrowing is really great and I miss that workflow a lot. There’s also the Smalltalk class browser, where you had your Miller columns of code structure, and ended up with a single method in your editing window. (I think Eclipse had something similar for Java, but I don’t see that in contemporary IDEs a lot, never mind the absence of sub-class/-module organizational structures).
And of course narrow-to-region goes beyond just functions & methods, when you really want to look just at a single part of this. And no, I don’t think XP-style overuse of method extraction is the solution here, that’s basically a permanently narrowed view without a good option of getting the context (and inner-procedural refinements or literate programming seem to be way out of the computing mainstream, too).
In vim and neovim
<C-w>]will go to the definition of the symbol under the cursor. Like most editors (including VS Code?), they rely on another tool to tell them where to go. So you need either ctags or an LSP to make this effective. I find<C-w>]most powerful with an LSP, so in that context I map it to something easier to type (gs, mnemonic “Go to…in Split”). (Neovim has been adding a lot of helpful LSP defaults lately, but I don’t think that there is a default mapping for<C-w>]yet. But I may be wrong.)(Edit: apologies to sluongng. I started this comment last night and didn’t see their comment until after I hit submit.)