Hacker News Reader

Not to detract from your general point - I definitely see the value in using an IDE with a Vim plugin, and often do so myself.

> Vertical scrollbar? Plugin

If you want scrollbars, the right solution is IMO to use a GUI Vim. I often use MacVim which is great, GVim is the obvious alternative on Linux/Windows, and NeoVim has lots of options (including, arguably, VSCode-NeoVim which is also great).

With MacVim, I can pop around randomly in a terminal and open Vim instances that run in the terminal as usual - and if I start editing something for long, I can type :gui to pop up an actual MacVim GUI window. I believe the same works in GVim.

> * Autocomplete code using lsp? Dance with plugins or copy paste literal screens of configs for nvim

I was annoyed by this as well. I then discovered that ALE (the venerable pre-LSP plugin for async linting) now has full LSP support, and it all “just works”. Doesn’t require NeoVim either. Just install the ALE plugin and put LSP servers in $PATH. ALE will find and use them. (By default, it uses standard Vim bindings like C-x C-o for completion, but you can change it.)

> * Want nice looking theme? Plugin! (Gruvbox in my case)

Vim 9.x (not NeoVim) has added a built-in Gruvbox theme named “retrobox” (both light and dark variants based on your background setting). If you don’t have it yet, you can get it as a plugin from here until your Vim updates: https://github.com/vim/colorschemes

> * Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too.

There are built-in settings for this, but yeah it requires some initial fiddling to get it nice. (After that initial fiddling, I’ve been annoyed by how word wrap works in any other editor.)

That’s mostly true, but then one day you want to use an external filter, or a custom set of snippets that doesn’t suck at editing them, or make the next line align correctly after “(“ and there’s no plugin for that in your ide. And, more importantly, it’s a pita to create and publish one. It’s not better or worse, some people like off the shelf availability, some like local fine tuning. Would be nice to have a full union, but ides suck at local customization that wasn’t trivial or planned in advance.

Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?

The last great effort with resources, experts, etc. was VSCode. If they can't nail it, can it be done?

VSCode seem to have a lot of things done very right, but i don’t want to focus too much on it in vim topic.

Emacs

v29 looks promising :)

Maybe 10x, but I’m not willing to switch yet myself, I need C-[ for Esc.

https://10xeditor.com/

Given amount of the extensions that vscode has I feel that local customization is solved problem for it. But it is rather exception

VSCode plugins still take a massive effort to write in comparison to vim/neovim where you could basically do everything in your vimrc.

> Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?

An IDE plugin for Vim rather than a Vim plugin for IDEs?

> Added: I hate both worlds now. Where’s an editor that is full of modern features and at the same time easily programmable?

What about an editor with

- LSP and treesitter support built-in

- Scriptable with Lua, a common and well-supported embedded language

- Regular and remote plugins can be written in NodeJS, Python and Ruby for starters

- Built-in terminal emulator

- Uses XDG directory layout

- Plugins run as separate processes

- API for accessing core editor features

- UI and core editor are decoupled; all UIs are plugins

- Multiple UI clients can connect to the same editor server

This and a lot more is on the Neovim page [1].

[1]: https://neovim.io/doc/user/vim_diff.html#nvim-features

nvim is in my setup scripts with dotfiles and is picking up my vim config per my init.vim. But still - look about actual setting up it [1], [2], where [1] stragight says "if you need autocomplete, you need plugin for that". I obviously can do it, but I just don't want to... Batteries should be included in $CURRENT_YEAR.

It is probably missed, but I use vim everyday, as text editor for many years. My .vimrc on github is 3 years old, and only because I moved it there from bitbucket and didn't bothered to preserve history. I'm not against it.

It was that original comment that I answered, was saying that vim is effective/better for IDE specific tasks (e.g. large refactorings, that inititial comment that I've replied), and after many years of using vim I strongly believe is rather ignorant and shows not understanding of power and features of modern IDEs.

[1]: https://github.com/neovim/nvim-lspconfig

[2]: https://alpha2phi.medium.com/neovim-for-beginners-lsp-part-1...

Guilty as charged but complaints about "tinkering with Vim" kind of miss the point to me. Tinkering isn't a bug, it's a feature. Vim was designed in the UNIX philosophy of small tools that allow you to modify them to your needs.

Also, modern IDE layers for Neovim such as LunarVim or AstroVim make managing plugins trivial.

Nothing about vim is “small tool”. Maybe it was 40 years ago, but now it feels much more bloated and with too much tech debt accumulated during the years.

In what way is it bloated? IIRC, the executable is less than 2MB, and without plugins it uses about that much memory too.

GP mixed up vim with emacs.

You forgot vim-runtime that is another 35mb and hard dependency on Debian.

But I was rather saying that if a program has 600 pages dense manual (vimbook) it is certainly far from Unix philosophy of small utility doing one thing.

Damn, it has built in file explorer and remote editor (netrw).

It strikes me that that’s roughly 0.05% of the RAM on my desktop.

You can install vim-tiny on Debian, which I believe doesn't install the runtime files.

Size is not really a good indication of "bloat" IMO. There are 683 syntax highlight files, 7.8M in total, but you don't load most of that and it's just "idle" bytes on disk. Same for indent files, ftplugins, etc.

You could also save ~5M by not shipping translations, but is that "bloat"?

It's useful these things are shipped, and in the scenarios where you care about 35M of diskspace you probably don't want a full Vim anyway (and you can use vim-tiny).

I wasn't speaking about binary size, it was the answer to message that vim is 2mb binary. Bloat is that vim, even without scripting, is huge, and, at the same time, a lot of standard things are suprisingly missing. Even author of neovim felt that

> But I was rather saying that if a program has 600 pages dense manual (vimbook) it is certainly far from Unix philosophy of small utility doing one thing.

Sorry but I think you're confusing Vim with Emacs, the editor with the unofficial motto of "a great operating system, lacking only a decent editor" because of the tendency for users to do many computing tasks inside of Emacs (like playing MP3s) that had nothing to do with editing text.

Neovim is a refactor of Vim with 30% less code. They got rid of obsolete platforms (sorry Amiga and OS/2 users) and many features that no longer made sense or were replaced with newer/better functionality [1].

[1]: https://neovim.io/doc/user/vim_diff.html#nvim-missing

Well, that's what the Neovim project is all about...stripping Vim down and removing the bloat and old technical debt. Have you tried Neovim? It sounds like it would be perfect for someone with those concerns.

vim itself isn't a "small tool", but its command-driven nature and plugin ecosystem is very much in the spirit of composing small tools to get things done. Emacs, imo, is even more so.

It still starts a thousand times faster than any IDE.

Additionally, it still uses less resources. VS Code consumes at least 1 GB of memory for just a simple project. I am not even mentioning other IDEs

Correction: AstroNvim.

Vim (Or rather neovim) now is that tool that grows with you as you age. So, as you mentioned, even I have small small things I've added and removed from my vim/neovim setup over the years as I have changed with the code.

For me personally, the benefits are worth it, because the neovim approach really works well with my way of working with editors. And the "personally" part is really important.

In my early years I have used IDEs and I was never really interested in using Vim in the first place. (I thought it was not very nice looking when I first looked at the empty screen). I only started using it because I found other IDEs (CLion, Visual Studio) and so on not very comfortable. Even now, I have tried quite hard to use VSCode due to its support for remote development which I really like as a feature. However, I keep coming back to Vim it seems.

So, for me, vim is an appropriate tool, but it might not be for you, because we might be thinking about text editing in fundamentally different ways.

I don't feel that we thinking about it differntly. It is that editing source code is much more than just editing text. And vim severely lacking as an IDE.

We don't need to associate motion style navigating and separation of command and insertion modes as something very vim specific. It is that vim is installed on every machine that I work on in like 99% of cases, and it made sense to me to learn something that is always available. But the shortcomings are very clear.

I can give an analogy of gdb. I feel that anyone who says that text mode gdb is anywhere near convenience that you get using modern IDE is suffering from stockholm syndrome. Yes, obviously it is more powerful in some circumstances, but for day to day use it is just plain inconvenient.

And that's why I said in my first post - I settle on vim as text editor, but I gave up trying to set it as an IDE, so I will never code in it, unless I'm forced to (who knows, weird job that requires vim use etc). Life is too short for that amount of tinkering.

Text mode GDB is very clunky, but it is better than any frontend I have tried. Whatever pain points it has, I can mostly work around with scripts, which isn't possible with a GUI. The worst part is that it's awfully slow for programs with a plugin architecture. If I set a pending breakpoint before starting the program, I can wait ten minutes until all plugins are loaded. I really wish I could tell it to preload some debug information at the start.

> Do you want autodetect indent and tab rule in file? Install plugin.

https://www.kylheku.com/cgit/c-snippets/tree/autotab.c

Nice, it works well!

Some see having to install and configure a plugin as a bug, but I see it as a feature.

You can also get modern IDE features such as LSP supported renames in Vim, so it's not an either fast typing or good refactoring support, you can get both.

> * Wrap long lines by whole words if possible? No default setting, I guess I need to search for plugin for that too.

Shift-V:!fmt

Works on all blocks, not only lines.

I didn't mean formatting, but just "wrap lines in editor". So long lines always fit screen, without actually inserting line separators.

I was speaking about

    set wrap

but because I turn on display invisible symbols,

    set linebreak

doesn't work. Why? I don't know. Somehow IDEs can do that without issues, but the technology isn't there yet for vim, seems like.

I don't see any of those features as improvements. Even when I had to use an IDE (java...) I never enabled any of that.