Quote:
Originally Posted by thirdm
I'd argue that anyone who thinks chucking an interpreter into a text editor makes it an emacs alternative doesn't get emacs. I suspect most of them would never want to and that's fine, but the truth of it is that all the so called bloat is what emacs is all about.
|
I agree, & I suspect the interested developers do too. My suspicion is that a number of people would find
mg(1) more attractive if their favorite third-party Emacs modes could be integrated. I use Emacs nearly exclusively now, but I don't use Emacs for mail or its other kitchen-sink features. I don't live in Emacs, & I don't want to do so. I would drop Emacs entirely on OpenBSD if I could get a C-mode, Perl-mode, & Python-mode-like features
(along with split windowing...) on
mg(1). If the exact same extensions could be integrated
(warts & all...), this would be a plus. I suspect this is the demographic targeted by the current developer mindset from what I read -- at least this is what I walked away with from the discussion a year or so ago.
The flip side of this discussion is what are the ill-effects which comes with growing
mg(1) from a small compiled application to a run-time interpreted environment.
mg(1) as it is now is refreshing small & fast in comparison to Emacs. Unfortunately, Emacs has some
(not all...) features I would like in a replacement. If
mg(1) could retain some of its original agility after having a script engine added, that would be the bomb
(
), but this would not be known until the work was finished.