In the editor wars between Emacs and Vim I have always disliked both strongly. Although the first real editor I used was Emacs, and I usually use Vim when in a terminal, I despise both as outdated, hard to use relics of the 1970's. They require an enormous effort to learn to use, and they work completely differently from any modern user interface.
This document explains my dogmas about how an editor should work.
An editor must not have any modes or mini-modes.
Vim's design with a specific edit mode is an effect of having to run on systems and terminals from the 60's that doesn't have any modifier keys. This is not an issue any more, and still having the user interface be crippled and hard to use because of that is ridicolous.
Emacs mini-modes where you get into under modes of under modes in a little edit bar is a little bit better, but only a little. It's however infinitely compounded by the major problem that pressing Escape does in fact not get you out of these modes, it instead enters a mini mode, making you absolutely stuck and unable to to do anything including exit Emacs.
Now obviously, completely getting rid of modes is impossible for an IDE. This is because they have an integrated debugger, and debugging must be a mode, as the debugger is either running or not running, which is modal. That said, an IDE should aim to still have the editor working during debugging as usual. This minimizes the negative effects of having a mode. This mode should also be marked in a prominent visual fashion, for example by having the editors background colors change.
Another "mode" is an auto-completion popup. Here it's choosable how modal you want to be. You can have special keys for auto-complete selection and hence not being modal at all, or you can be semi-modal and use arrow down to select, and tab to insert. What you use depends partly on how the auto-complete is done. If it is a drop-down (common in GUI environments) it's very visual and non-intrusive. If a terminal environment autocomplete can be done by proposing a complete in a different color, and in that case it's probably better to use special keys.
Any other modes must be handled by dialog boxes or drop-down menues so that they are obvious.
Much of usability comes from things working as you expect them to. This is usually called "intuituive", although that's a misnomer, it's about behaving the same as other software, so you can reuse that knowledge. And you expect Escape to cancels whatever you are doing and close dialogboxes, exit modes and menus. Ctrl-C should cut and Ctrl-V paste, etc.
Having the configuration file executable is a bad idea. Not only is it a security issue if you copy configuration from somebody else, it makes configuration needlessly complicated. And it also requires users to learn a programming language, a language they might not want to learn. Especially if that is some weird and obscure language whose main usage is that editor.
INI-files is a good configuration syntax. JSON is acceptable if you require hierarchies. "Configuration syntax" that are actually mini-languages that are executed rather than parsed counts as programming languages even if they are not Turing-complete. Yes, I'm looking at you Ansible.
As a result of the above, extensions should be done by writing separate extensions, not by sticking code into a config-file.