On Fri, 8 Aug 2025 15:15:50 +0200, <[email protected]> wrote: tlaronde> "panels" of a main window). [Am I not re-inventing Acme?]
Which brings to mind something that's been niggling at me for a while. There seems to be a bit of a bias against all-singing, all-dancing editors (cf emacs(1) and the lack of any variant of emacs in the various Plan 9 distributions). On the other hand, acme's an editor, and it's used to read mail. In other words, from the user's perspective, the exact same functionality is present in acme as in emacs - I can write macros, I can read mail, and I can edit files. I can even run a process under either of them interactively or simply for the output, with the results in an editing buffer. I can visit a directory in either, etc (these are, in fact, exactly what I use emacs for in my usual environments). So, the ability to do lots of things via the editor per se does not appear to be the problem. Even having a fair amount of built-in capability seems acceptable. Rather, the objection appears to be that emacs does everything itself, instead of providing some degree of internal abilities plus an interface to let other programs use it simply as a user-interaction medium (essentially, the textual equivalent of rio). Have I got that right? We'll ignore GNU emacs' client/server feature for the moment, of course. I'm just trying to figure out where the boundaries are for what's considered reasonable for base Plan 9 programs, as opposed to things that compose new abilities on top of that base. Thanks. Dworkin ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M03fa740bb1723198f2335e47 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
