> You clearly are not willing to deal with that, and as such are not ever going to be happy.
I'm pretty happy in Emacs. I'm not happy with false dichotomies, like this features/speed tradeoff. There is a real tradeoff to be made between those, but nowhere near the level I've seen in IDEs.
Many problems seem to depend on the way modules/extensions are implemented.
For example, we could implement plugins by allowing event listeners which can run arbitrary, imperative code. However, this leads to redundant computation (multiple "get(foo);" and "set(foo, bar)" calls spread across listeners), increases the chance of plugins conflicting due to race conditions, requiring very conservative scheduling, etc.
An alternative, like a hook/advice system, would have the core performing gets/sets exactly when they're needed, but give plugins the ability to override the return values using hooks (like a dynamic form of decorators). This avoids the redundancy, race conditions and scheduling issues.
I'm pretty happy in Emacs. I'm not happy with false dichotomies, like this features/speed tradeoff. There is a real tradeoff to be made between those, but nowhere near the level I've seen in IDEs.
Many problems seem to depend on the way modules/extensions are implemented.
For example, we could implement plugins by allowing event listeners which can run arbitrary, imperative code. However, this leads to redundant computation (multiple "get(foo);" and "set(foo, bar)" calls spread across listeners), increases the chance of plugins conflicting due to race conditions, requiring very conservative scheduling, etc.
An alternative, like a hook/advice system, would have the core performing gets/sets exactly when they're needed, but give plugins the ability to override the return values using hooks (like a dynamic form of decorators). This avoids the redundancy, race conditions and scheduling issues.