Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vim After 15 Years (2017)

blog.langworth.com

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Vim After 15 Years (2017)

#31

Post by lelandfe »

pmoriarty wrote: post #21
Trufa wrote: post #9

It's alway pretty fascinating to me that people can actually be productive without an IDE. I've tried several times Vim and I just don't get it how you can live without certain functionalities, I'm sure that with enough tinkering you can get pretty close but, for example, search seems to always be kind of a pain in the ass for the complex queries with regex through many files and stuff like that, specially the presen…

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.

Re: Vim After 15 Years (2017)

#32

Post by Jorengarenar »

aidos wrote: post #22
brian_cloutier wrote: post #19

Earlier quoted context omitted.

I've used vim for a while now and using it isn't a point of pride, it's more that whenever I try an IDE I wonder how anybody could be productive using it. I've rarely had a problem with search, I can type `:grep [some regex]` and I'm quickly shown all matches for that regex in the entire project. I admit I'm not sure how I would do a more complicated query, but this is almost always enough, what kinds of queries do y…

I don’t use debuggers myself, but I think they’re pretty well supported within vim (neovim at least) these days https://github.com/mfussenegger/nvim-dap

Vimspector: https://github.com/puremourning/vimspector

Re: Vim After 15 Years (2017)

#33

Post by kazinator »

Vim has an "autochdir" mode whereby the current directory of each buffer is the working directory of the file.

It sucks. For instance, when you're editing a .git/COMMIT_EDITMSG, it makes the directory .git/. It has no concept of intelligent exceptions.

I made myself a better one:

On startup, we save the current (i.e. project top) directory in the `$top` variable:

  :let $top=getcwd()
When entering new buffer, we lcd to the directory of the path:

  :au BufWinEnter * exec "lcd " . expand('%:h')
But if the buffer is new, without a name, we change to the top.

  :au BufWinEnter * if expand("%") == "" | exec "lcd $top" | endif
If we are in .git, go to top.

  :au BufWinEnter *.git/* exec "lcd $top"
Why is the variable $top and not top? The dollar sign makes it an environment variable, exported to child processes. Why on earth would we do that?

Because Vim interpolates $-sigiled environment variables in more contexts than regular variables! I can use $top pretty much anywhere.

Re: Vim After 15 Years (2017)

#34

Post by statico »

statico wrote: 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 to Fastmail someday)

- The eight billion other chat apps I use — I dropped IRC many years ago but used IRCCloud to ask NetHack questions recently

- CyberChef for exploring binary data

- Pixlr for image tweaking

- Google Sheets, Airtable, and Notion for notes & databases

- A password manager for passwords

- Pinboard for bookmarks

- NextDNS & PiHole for DNS settings

- Postico for Postgres (not web-based, but massively I'm tremendously more productive with it than with psql)

Re: Vim After 15 Years (2017)

#35

Post by Jorengarenar »

aidos wrote: post #18
mixedmath wrote: post #8

This seems to hold pretty well. I've been using vim for approximately 15 years now too and my current setup and preferences are surprisingly similar to those in this post. There is a certain organizational aspect here that I think is important to emphasize: the given paradigm is that vim is a text editor forming one part of the design environment. Assembling this environment inside a tmux session is particularly easy…

I’d say that vim will never be an IDE as such, because the focus is on personal configuration. Personal Development Environment is how one of the neovim contributors is half rebranding it. The things that make modern IDEs good (like LSP) at all available but you get to shape them how you want, rather than being forced into your IDE of choices way of doing things. (I imagine from your comment that you are probably awa…

Vim will never be an IDE because it does not aim to be one. It's a text editor - a central component of development environment, but only a component.

I really like the "PDE" term - it gives us a simple division: IDE is when program ships all components by default (hence the "integrated" in the name), PDE is when you yourself attach components of your liking (hence "personalized").

Re: Vim After 15 Years (2017)

#36

Post by kazinator »

Another Vim tip: I use a plugin called bufexplorer.

I patched bufexplorer.vim with this:

  if !hasmapto('BufExplorer') && g:bufExplorerDisableDefaultKeyMapping == 0
    nnoremap    \ :BufExplorer
  endif
What that does is make the buffer explorer's window accessible just by hitting backslash twice. The \ key is the default key in Vim. So \ means \\.

Bufexplorer lists the open buffers one per line in a window that is searchable. The window can be sorted by recently used.

Switching among buffers with plain Vim is a paint: using :ls to list buffers, and :b and such. A more ergonomic buffer switcher is a must.

Re: Vim After 15 Years (2017)

#37

Post by brian_cloutier »

kazinator wrote: post #25
brian_cloutier wrote: post #19

Earlier quoted context omitted.

I've used vim for a while now and using it isn't a point of pride, it's more that whenever I try an IDE I wonder how anybody could be productive using it. I've rarely had a problem with search, I can type `:grep [some regex]` and I'm quickly shown all matches for that regex in the entire project. I admit I'm not sure how I would do a more complicated query, but this is almost always enough, what kinds of queries do y…

About :grep, try integrating GNU id-utils with Vim. GNU id-utils provides a mkid command which scans a directory of files to build a binary index file called ID . The lid tool is used to query this and provides a grep-compatible mode. lid sometimes puts out things in a funny order, so I sort the output. :set grepprg=lid\ --word\ --result=grep\ '$*'\ \\\|\ sort\ -n\ -t\ :\ -k\ 2 This is basically instant even on huge…

What do either of these `grepprg` options win me? Currently my `grepprg` calls `ag` which is plenty fast for me, and it sounds like `lid` is a slightly more general ctags?

Re: Vim After 15 Years (2017)

#38

Post by statico »

statico wrote: post #34
statico wrote: 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…

I do miss the terminal in a lot of ways. I feel a lot of nostalgia for the days when I got all my work done with just 2x2 terminals taking up the entire screen. (You could just fit them in with 1024x768 and the 8px high Tixus font.) But in 2022 it feels impossible to live entirely in a terminal unless you're in very specific areas of work.

Re: Vim After 15 Years (2017)

#39

Post by kazinator »

Another Vim tip: use sessions.

  vim -S
will recover a session file.

I set up these items in my .vimrc to make sessions a little easier to work with:

The + key (which has a useless default role of moving to the next line) is mapped to save the current session:

  :nmap + :waexe "mksession! " . v:this_session
Then, a :S command for creating a new session, e.g. :S foo.

  :command -nargs=1 S exec "mksession! " . expand('$top/') . expand('')
This relies on a $top variable which I set like this:

  :let $top=getcwd()
that has to do with https://news.ycombinator.com/item?id=33351155

I want sessions to be created in the top directory, rather than the directory of the current buffer.

Re: Vim After 15 Years (2017)

#40

Post by cassepipe »

lelandfe wrote: post #31
pmoriarty wrote: post #21

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.

The gdb TUI with a simple config and a simple readline config from a terminal has personally done wonders for me. I get vi mode, tab completion, syntax coloring, a colored prompt and really all I could ask for. I have aliased gdb to "gdb - q -ex start --args" and the experience is very nice.
Post reply on HN