On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
> 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.
>
Concerning the "frame of mind", I'm exactly in the same one: when it
comes to software and a system, I want a mathematical partition: code
that does not overlap and that covers the whole need but keeping it a
whole i.e. a unit because the pieces can be combined to work together.
Indeed, when there is an interface that is not line limited, why try
to put pieces of editing capabilities in the window from which one
tries to send commands, and not an editor running in a panel dedicated
for commands (this gives the immediate possibility too to have the
equivalent of the Unix script(1): simply save your editing session),
with the output sent in another read-only panel, while "comments"
(stderr) appear in another one?
This way of organizing the interface being, contrary to emacs, simply
a way of letting external utilities use some panel and being able to
combine their results.
Emacs makes sense as the way to have full editing capabilities to also
edit commands. But I think also that it duplicates too much, and that
such an interface could be just a graphical 2D way of combining other
utilities and organizing their output.
I do think that this is totally in the Plan9 spirit and that when it comes
to the GUI, things can be reworked and in fact simplified.
--
Thierry Laronde <tlaronde +AT+ kergis +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M016e350dd527c8da4693f685
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
