I'd arvise you to try vim again. Carve out two days, take your time, dive in and build the ide you want.

I tried all modern ides, and while vscode is certainly awesome, i always go back to my vim :-)

Discoverability certainly is an issue with vim – but it isn't really with Premiere. What I was alluding to with vim was more the combinatoric aspect of powerful tools. Creating software that solves one specific problem with a beautiful UI isn't that hard – creating something that solves a very broad range of problems is infinitly harder, because you need to give the users a language in which they can tell the machine what they want. That "language" can be shortcuts and chainable commands like in vim or it could be graphical, using a timeline, context menues, drop downs, symbols etc.

However: the more expressive this language has to be and the more problems you should be able to solve with it in precision, the steeper the learning curve will get. And as with spoken language, there are hard to learn languages that let you express certain aspects very precisely and there are simpler languages that might be easier to learn but make it harder to express certain things (e.g. "You" in English vs "Du"/"Sie" in German vs. all the formal variablity of Japanese).

I use IntelliJ with IdeaVim plugin, that makes it's editor behave like a vim editor (at least pretty close). It is the best of two worlds: real IDE with a powerful and efficient text editor.

As for learning VIM, it is a complex professional editor, and I personally recommend just reading a book about it.

Autocomplete with control-p, error reporting from your compiler, outside of vim, although there are plugins for it if you wish (I consider it something of an antifeature, as it distracts me from finishing the code I'm trying to write).

>you have to trudge through two decades of websites to discover anything

>type :help<Enter> or <F1> for on-line help

This is not for show!

>I've been unable to find out (actually I haven't really looked) how to use vim as a software developing tool (with basic features like autocomplete/suggest and error reporting)

Vi is a text editor with an incredibly powerful language to edit text tied to keyboard keys.

Emacs is a lisp interpreter that's optimized for text editing.

They are not IDEs.

GNU Emacs comes with a Lisp IDE. Compiler, Interpreter, interactive read-eval-print-loop, backtrace, stepper, code formatting, profiling, source-level debugger, ...

What do you consider to be the defining set of features for an IDE, and what do you think Vim and Emacs are lacking from that list?

They are not integrated.

That said, vim and emacs can be in a way a component of a DIY IDE - you just need to put the work in and build it yourself. I exclusively use vim with a handful of useful plugins, scripts, and additional CLI tools in other terminal splits.

The terminal is my IDE.

The standard way to use Emacs is as an IDE; you use M-x compile to run the compiler in a window under Emacs and M-x gdb to run the debugger in a window under Emacs, in both cases with hypertext capabilities. These are standard packages included in a default Emacs install, although you may want to bind them to more convenient keys. (I bind [f5] to recompile.) You do not need to run Emacs in a terminal, and copy and paste to and from Emacs (not to mention things like viewing SVGs you're editing) works better if you run it in a window on its own. You do not need to "put the work in and build [an IDE] yourself" if you are using Emacs.

(Of course if you're writing programs in Elisp, Emacs is a more tightly integrated IDE, but the success of Emacs, org-mode, Magit, and Amazon notwithstanding, Elisp is not a very good programming language. Also, if you run Emacs in a terminal, you can quite reasonably use it over a low-bandwidth, high-latency ssh -C connection, and it becomes good for remote pair programming, which is not true of running Emacs in VNC. I haven't tried running it in Xpra.)

Historically Emacs started up far too slowly and used far too much RAM to be convenient to use it in the way you're describing, as a text editor invoked by a larger IDE; I remember waiting over a minute for a new Emacs process to start up in the mid-90s. Nowadays it might be reasonable, but it still takes almost 4 seconds on this laptop, which I find to be a painfully long wait for opening a file. Also, Emacs's language-agnostic autocomplete M-/ works a lot better if you have a lot of files open in the same Emacs session.

Although there are packages that configure Vim to work the same way, it is more common to use Vim in the way you describe, as a component of the IDE rather than an IDE in its own right. And Vim has the great advantage that it starts up instantly, and the advantage or disadvantage that its equivalent of M-/ (^P and ^N) is buffer-scoped, so it doesn't matter if you have more files open.

> Nowadays it might be reasonable, but it still takes almost 4 seconds on this laptop, which I find to be a painfully long wait for opening a file.

That is one of the use cases for emacsclient/Emacs server.

Yes! I should have mentioned that. I mostly use emacsclient as an $EDITOR for git and similar programs in Emacs shell-mode, but you can also use it as a version of Emacs that you can run quickly in a tmux window, if that's what floats your boat!

They can be interactive development environments if you configure them as such.

They are certainly evangelized as IDEs.