Live data from Hacker News

Vim After 15 Years (2017)

blog.langworth.com

91–100 of 116 posts

Re: Vim After 15 Years (2017)

#91

Earlier quoted context omitted.

I also use kitty + neovim. I highly agree.

I've been a heavy vim user for I don't even know how long. What does neovim get me over vim? Looking at the charter page on the website, the only thing that really stands out to me is Lua. "Deliver a first-class Lua/LuaJIT scripting alternative to Vimscript." The rest seem fine but not really a reason to switch, and I don't know Lua so I'm not sure that's a reason either. Is this the main reason? Are there other good…

You could script plain old vim in Lua long before NeoVim existed.

Re: Vim After 15 Years (2017)

#92

Earlier quoted context omitted.

I feel pretty much the opposite. IDE's seem incredibly limiting and feature-poor compared to editors like vim and emacs, which can do just about anything. Regarding your specific examples, both vim and emacs have file histories and if your files are under version control it's easy to get diffs. Searches are super powerful in both vim and emacs, and it's easy to search across multiple files as well using various scrip…

Can vim and/or emacs do refactoring? That is a feature that I use daily and couldn’t live without

Note that refactoring only exist for some language: for Java it exists in some IDE, for C++ no.

Re: Vim After 15 Years (2017)

#93
post #29

Author here. Many will be disappointed to know that I've been using VS Code almost exclusively since 2019 (with the Vim plugin of course). I've been meaning to write a follow-up article, but unfortunately writing is low on the priority list. The main reason is that these days, when I _am_ coding, I mostly write TypeScript and React on my local machine (not much SSH these days), and VS Code Just Works™. I tried twice…

what's your vscode setup ? people at work use it in an ad-hoc fashion and it's surprisingly messy (tabs disappearing, git interface confused), we're also looking for partial reformat and on save fixes (whitespace and such)

in any case, thanks for your comment

Re: Vim After 15 Years (2017)

#94
post #34
post #29

Author here. Many will be disappointed to know that I've been using VS Code almost exclusively since 2019 (with the Vim plugin of course). I've been meaning to write a follow-up article, but unfortunately writing is low on the priority list. The main reason is that these days, when I _am_ coding, I mostly write TypeScript and React on my local machine (not much SSH these days), and VS Code Just Works™. I tried twice…

Another thing: I think I use VS Code more because I spend much less time in the terminal than I did 5, 10, or 20 years ago. Everything happens in the browser now. I used to write lots of tools and services and commands for myself based in the terminal, but now web-based tools have replaced most of them. Some notable examples of things I would have used the command line for a decade ago: - Gmail for email (I'll switch…

never tried self-hosted cryptpad for collaborative docs (not as featured as gdocs or ms office but still) ?

Re: Vim After 15 Years (2017)

#95
post #55

This is the list of features (in Eclipse) that I'd like to use in Vim: - Show in Breadcrumb to show the package name > class > function in the top of the editor - Open Call Hierarchy to show all places where a class/variable is used. - Show Type Hierarchy to show how a given class is derived from Object. - Debug Shell for running snippets in the debugger. I know that I can use grep or ag for some of them, but I rathe…

I think you can get most of the first three of your requirements from TreeSitter and LSP.

The treesitter context plugin (https://github.com/nvim-treesitter/nvim-treesitter-context) provides the package/class/function info at the top and the LSP gives you features like 'find-references' and 'go-to-definition' you can bind to the keys of your choice.

I use 'gr' for 'find-references' and 'gd' for 'go-to-definition.

I don't use a debug shell (I use a tmux pane and a repl usually) but I'm certain there are options.

Re: Vim After 15 Years (2017)

#96
post #29

Author here. Many will be disappointed to know that I've been using VS Code almost exclusively since 2019 (with the Vim plugin of course). I've been meaning to write a follow-up article, but unfortunately writing is low on the priority list. The main reason is that these days, when I _am_ coding, I mostly write TypeScript and React on my local machine (not much SSH these days), and VS Code Just Works™. I tried twice…

Interesting, I just switched from vs code BACK to (neo)vim. For me the killer feature of vscode was remote, but imagine my surprise to see that was one of many proprietary things in the platform. And then I discovered mutagen, and that opened up my avenue for thinking about neovim again. The neovim lsp story with lspzero is as pain free as I can imagine things to be, so that also helps. In this day and age for the la…

oh wow, lspzero. I didnt know about this before. I love neovim, but I dont like spending time trying to make LSP features work.

Re: Vim After 15 Years (2017)

#97
post #92

Earlier quoted context omitted.

Can vim and/or emacs do refactoring? That is a feature that I use daily and couldn’t live without

Note that refactoring only exist for some language: for Java it exists in some IDE, for C++ no.

CLion absolutely has refactoring for C++ (perhaps not as powerful as for Java, but there is plenty).

Re: Vim After 15 Years (2017)

#99

I would like to add my perspective to the mix, as it seems Vim pops up here every so often and commonly the discussion becomes one of Text Editor Vs. IDE capabilities. As I get older (33 now), I feel more and more annoyed by Things That Just Work TM changing on me for (IMO) no good reason. There are very few applications that I update as soon as I'm notified, because more often than not, something changes which at be…

Feels like you robbed me of my words and made it better.

Re: Vim After 15 Years (2017)

#100

Earlier quoted context omitted.

I feel pretty much the opposite. IDE's seem incredibly limiting and feature-poor compared to editors like vim and emacs, which can do just about anything. Regarding your specific examples, both vim and emacs have file histories and if your files are under version control it's easy to get diffs. Searches are super powerful in both vim and emacs, and it's easy to search across multiple files as well using various scrip…

Worth noting that debuggers, which frequently have complex interfaces, are generally much better suited to GUI applications. Having a good debugger integrated with my code editor is basically the reason I use an IDE instead of vim. Stuff like Vimspector exist but are way more work to use vs. a GUI equivalent.

Eh, I'm pretty good w/ both gdb and pdb (python's debugger) and whenever confronted with an IDE's debugger (or Firefox/Chrome) I instantly feel like I do when confronted with an IDE: I'm at the mercy of whatever UX this thing will grant me. Scripting will be nonexistent/unfamiliar, specific information will be hard to find, etc.

I have a (maybe overbroad) critique of GUI software which is that it mostly brought us pixel-level graphics at the cost of extremely restrictive UX. Or said a different way, GUI apps look better but they're usually harder to get work done in.

Part of that is toolkits, part of that is you're using a mouse which is like driving a space ship with a single finger, part of it is the expanding user base of computing (to people who don't necessarily want to learn say, regular expressions). But like, I script GDB. If your IDE debugger won't easily let me do that (or it will but it's a painfully convoluted UX), it doesn't really matter to me that it (subjectively) looks nicer.

Post reply on HN