>Although I have to say fvim looks tempting as well

Visited its page to have a look... I'm not sure why they'd put a screenshot with a variable width font, which automatically puts lots of people off when it comes to coding...

It's like having a screenshot of your bitmap editor, and showing it editing goatse.cx...

The option to use proportional fonts is a very rare feature in vim-like text editors (the only other way I know of is to use terminal vim in mlterm), so for people who want this the screenshot is good advertisement.

In fact, after reading you comment, I promptly startet to install it (still compiling as I type this). My use-case is creative writing: I'm very used to vim keybindings from coding, but prefer to have a variable-width fonts for writing.

fvim author here. The font in the screenshot is `Iosevka Slab` which _is_ monospace -- `fvim` currently syncs with the neovim grid system and doesn't support proportional fonts well.

Sorry about the confusion -- I think you've already discovered that (after 46 minutes)!

>The font in the screenshot is `Iosevka Slab` which _is_ monospace -- `fvim` currently syncs with the neovim grid system and doesn't support proportional fonts well.

Aha, looked like a proportional font was used to me. I'd use a more well designed monospace font for the first impression!

Wow, I was completely fooled by the serifs and my excitement. Thank you for clearing that up!

> For those people mocking vim users and bragging about their IDE's.

Haven't seen this, -it usually goes the other way:

You're doing it wrong, you should use vim!

(I know enough vim to effectively use it to edit configs etc, but I just prefer my IDEs.)

Use vim plugins for your favorite ide and enjoy both! (or not all, we all have preferences:))

I'm not going to mock you, but why not just use an IDE with a vi(m) mode or plugin in the first place, if you really want all those features?

Modern IDEs are following a platform + plugins architecture that is probably as flexible but more robust than whatever you can tape together around vim.

vim modes in IDEs are often inadequate (if this is not immediately obvious, you probably just don't use vim as fully as possible). The IDEs are often (too) complex in the sense of a hodgepodge of GUI options and menus which are hard to navigate. You often can't put the IDE configuration in a version control system easily. IDEs are often sluggish. The plugin system for vim is superior to most IDEs.

It's not that using an IDE with a vim mode is not a possible viable alternative, but it's a game of trade-offs, as usual.

I agree completely. For me, for now, I have vscode with vim emulation. I find that it's more convenient to have everything vscode has + vim keys for a lot of things, than have all of vim + try to make vim do what I like from vscode.

I really hope in the future I'll find the time to do that, but for now I am content. It's always a trade-off.

Have you noticed any sluggishness when using Vim commands in VS Code? I use nvim + tmux as my go to and it's pretty responsive (still has trouble catching up to me sometimes) but I often have to wait for VS Code.

I have to wait sometimes, but normally it's fast. It's only when (I think) somehow the vim emulation bugs out that I need to wait a couple of seconds or just hit esc 5 times. Thankfully it's not often.

Because Vim modes usually don't support more than a handful of basic features, let alone plugins and custom keybindings.

Vim also starts up without any noticable delay and can be used for every text file, no matter in what context.

>Vim also starts up without any noticable delay

Only if you run it without any plugins. Unfortunately if you have a lot of third party packages, vim startup times start to get closer to emacs startup times (both of which are still better than any IDE I have used, of course). I keep a vim.norc alias in my alias file which launches vim with an empty .vimrc for this very reason.

Strange. I use 15 plugins and according to the --startuptime flag NeoVim takes 32ms to start. Vim takes about twice as long, but that's still so incredibly fast I'd call it instant. I guess when it comes to plugins there are some real heavy-hitters out there that I somehow managed to never try.

You could use autocmd for filetypes that require plugins, so they don’t load for configs/texts. If your pm of choice allows this separation, ofc.

I’m not very experienced with complex plugins, but most of what I’ve seen did nothing unless explicitly initiated. Maybe there are global variables to control that.

I've found that profiling startup time and lazy loading plugins could reduce your startup time to 100~200ms even if you have more than 50 plugins.

Vim has a plugin architecture. The built in language sucks balls but it does work.

> With languageserver and the other kind of refactoring daemons available for a whole host of languages nowadays these editors are much closer to IDE's than ever before.

Most likely true, though i think the "I" part of "IDE" is woefully ignored and (at least to me) is much more important than a hodgepodge of barely related programs strung together with duct tape.

That's precisely what every single python IDE does. They take isort, black, jedi or whatever other engine together and stitch them together in a user transparent way.

Omnisharp was literally the attempt of MonoDevelop to create an open source alternative to the Resharper engine.

The completion agents for VIM or VSCode do the presentation layer for the lower layer(the language server daemons, or custom completion agents. YouCompleteMe however is all that together in one not as fancy but I like it).

I get where you're coming from, but basically the difference is that vim by itself is a raw editor and until neovim came along never made an effort to merge the functionality that was required for something like this to happen in a nice fashion.

Editors like Oni are basically distributions like VSCode with defaults that are more inline with what you say plus a nicer presentation layer.

Yeah well, it isn't like Python IDE are much better :-P. I think in general most languages with unix-ish background do not tend to have truly integrated development environments as unix was always about stitching together stuff. Only Borland somewhat managed to make real integrated environments for their C/C++ tools and even then it wasn't as good as the stuff they had better control over (turbo pascal, delphi, etc).

Java and NetBeans is (or was, before Oracle botched it) probably the best IDE (in terms of integration) for a toolset with a unixy background.

Though none of those compare to something like Smalltalk, Lisp or even Microsoft's QBasic and (pre-.NET) Visual Basic.

Note that i'm talking about how integrated the IDE is with the language and its tools, not about how good or bad the language is.

I think this isn't about unix tools or philosophies. It's about the fact that for a very long time these big monolithic projects didn't really allow any integrations.

Vim didn't allow integration because there was no way interface to it, and it's not an easy codebase. Neovims work is proof of that. C++ compilers didn't allow integration because they were big monstrous projects and when you need to do proper c++ indexing you basically need to compile the whole project.

For C++ this changed with clang and even for clang it took a lot of iterations and bugs inside of libclang to allow for this capability.

Naturally one of the best C++ IDE's was therefore also by the producer of their own compiler (Visual Studio).

These boundaries are slowly fading, so these arguments are kinda moot. A few examples:

https://clang.llvm.org/extra/clangd/

https://github.com/Andersbakken/rtags

https://github.com/cquery-project/cquery

No i think it is actually about philosophies (or at least a way of looking at how software should be made) - again, i point out to Borland (whose IDEs were always provided a way more integrated environment than anything Microsoft ever did - e.g. for C++ MSVC always called out to a separate compiler program that had to reparse/restart its state for each file whereas BCC had the compiler as part of the IDE executable that would keep state across compilation in memory and even use the editor text buffer for 'input' if there was one instead of loading a file from disk) and Smalltalk (where the IDE and runtime are the same thing, you are modifying a live environment with tools written in that same environment instead of cold-running everything from start).

libclang might be a bit closer but it still is something separate from whatever IDE it is used for.

Honestly i do not believe it is even possible to what the sort of integration i'm talking about by stitching together separate projects no matter how many extension points and hooks those projects provide - by definition they aren't made with a singular coherent vision where everything is meant to work together, instead each project has its own idea of how it should work.

MSVC could in theory be able to do that since the IDE is made by the same company as the compiler, but in practice the teams behind it are probably acting as separate "sub-companies" inside the bigger organization. They're not seen as a single "C++ development environment" project but as two separate projects that happen to communicate with each other.

I'm not sure if 'philosophy' is the proper term here, but it is certainly about how you believe that software should be made and having that in mind at all times when designing it at all levels - be it the functionality to provide or how that will be implemented (e.g. a compiler that runs as a simple standalone application can just use globals for the state and perhaps not even free memory at shutdown - see dlang as an example - whereas a compiler meant to be integrated as a library cannot do that).

As an example, for a Borland-like approach (at least based on my understanding of it), adding a language extension to -say- provide meta-data for classes wouldn't be something that only the compiler developers cared about, but something that the developers of the compiler, the debugger (for being able to display the meta-data), the IDE (for editor auto-completion and automatic code editing - later Borland IDEs could modify the code - and debugger UI), the framework library (for taking advantage of it and providing a 'best use' scenario), etc. And all of those would influence the new functionality instead of being something that was added by the compiler team and then the rest would have to support (as it is done by pretty much every language that only exists as a standalone compiler or interpreter without any concern for IDEs, debuggers, UIs, etc nowadays).

> I get rendering artifacts when scrolling.

If you're using pango 1.44, that is a known issue and there really isn't a proper workaround yet. Quite a few applications using grid based applications are currently broken with pango 1.44.

Using NeoVim with nvim-qt should not result in any rendering artifacts.

I am happy with Neovim in a terminal too. But I wanted I wanted it running as a separate application that I could launch and switch to, so I downloaded the iTerm2 source code and changed the icon and application name and created a profile that just runs Neovim. I find this works well, but maybe someone knows a simpler way, or a generic way, to do this on OS X?

I think you can use an applescript for that. I think you can compile the applescript to a .app and then run it. But it's been a while since I was in OSX

https://www.iterm2.com/documentation-scripting.html

I just wish vim+languageserver would catch up to where vim+mlcscope was fifteen years ago. (Specifically, finer-grained distinctions that just references to a symbol, e.g. assignments and calls.)

Have you tried rtags?