4 ms·
As you note E-lisp is very hard to write correctly when everything has to work together, but even just the dynamic typing and dynamic scope often gets in the wa
by lomnakkus 10y ago
As you note E-lisp is very hard to write correctly when everything has to work together, but even just the dynamic typing and dynamic scope often gets in the way of correctness. It's only through Herculean effort on the part of the maintainers that these things even work -- it's pretty instructive to look at the issue trackers for some of the larger e-lisp projects, e.g. magit.
It remains to be seen whether this editor can change that, but if the API/Plugin boundaries are strongly typed, I'd be reasonably optimistic that it's at least plausible that it could :).
- barrkel 10y agoDynamic scoping and typing is what makes Emacs easier to extend, rather than harder. It's not unusual for users to fix bugs and performance problems in Emacs packages with some choice redefinitions, global or scoped. A typed API on the other hand will prescribe interactions between extensions. It's still possible with the right design to make things flexible - eg getting extensions to describe their logic in the form of data that can be modified by other extensions - but I think the axis will be between Emacs style flexibility vs rigidity of extension.
- progman 10y agoInterestingly, Emacs is probably the most reliable editor ever. I had not a single crash in 25+ years in daily use in Linux!
- lomnakkus 10y ago> Dynamic scoping and typing is what makes Emacs easier to extend, rather than harder. I think that's what this new editor is trying to test. I'm certainly not convinced that that's true. :) > It's not unusual for users to fix bugs and performance problems in Emacs packages with some choice redefinitions, global or scoped. Maybe those bugs shouldn't have existed in the first place? I'm don't want to be fixing bugs in my editor -- I just want it work properly. While outright crashes (as in SEGV) have been rare, there have been loads of times emacs has just gone into an infinite loop, times where functions get the wrong type (or number of) arguments and you just get some weird "argp" (or whatever) error message in the status bar. I don't think I'm an anomaly -- especially since I use very few extensions (at least AFAICT compared to what some real power-users do). > A typed API on the other hand will prescribe interactions between extensions. It's still possible with the right design to make things flexible - eg getting extensions to describe their logic in the form of data that can be modified by other extensions - but I think the axis will be between Emacs style flexibility vs rigidity of extension. The thing is: The API exists has some restrictions whether one formalizes them or not -- the difference is that in one case you'll just get weird/buggy behavior whereas in the other you'll get a compilation error. If it's possible to formalize something "generic enough" is an interesting question.