Chiming in to say Ron hits the nail on the head here: Plan 9 can take a
very pure approach to the Unix design philosophy, of composable,
reusable, programs that do one thing well, because it gets a lot of
fundamentals right (looking at namespaces).
Emacs has its own lisp because its original host OSes got those
fundamentals wrong. Processes have much less control over their own
environments on other Unix-likes. It's much harder to throw up a file
server and have it Just Work™.
On Plan 9, emacs could expose its editor state as a 9P server, and let
other programs, written in *whatever*, do the heavy lifting. The program
and the overall system both shrink, reducing complexity and the
cognitive burden of the system as a whole.
And hey, that's exactly what Acme does.
/begin tangential rant, on getting fundamentals wrong
I'm of the belief that the widget-oriented GUIs most people use comprise
a severe misfeature. They encourage immutable and compiled-in
functionality which, in turn, beget bespoke scripting and plugins to get
around the resulting limitations. Code and system complexity then
increase, weighing the mind down and fragmenting development ecosystems.
I reckon the volume of characters made available by Unicode is vast
enough, and Plan 9's plumbing and namespacing are versatile enough, that
complex graphical shells can be based purely upon text buffers. Users
could then write their own interfaces, suited to their needs.
One piece of Plan 9 orthodoxy holds this back: centralisation of the
plumber. There is no trivial way of determining the optimal ordering of
context-specific rules in a single plumbing file, nor a way of
communicating that context without introducing additional conventions
that *all* programs that plumb must obey.
A centralised plumber is, as a result, a fragile plumber. Different
contexts should have different plumbers.
/end tangential rant
- Willow
On 09/08/2025 23:08, ron minnich wrote:
Just a reminder, if you get too stuck in an emacs frame of mind, you're
really going to miss the full power of acme specifically, and plan 9 in
general.
Back in my LANL days, I had a need to edit around 30 assembly files all
at once, to change a common thing. It was not going to be fun with sed.
So I:
acme *.s
and in the top bar, do something like this:
Edit X/*.s/,s/blah bla/blue lue/g # memory is almost certainly wrong here.
But it let me do a sequence of commands, across all those assembly
files, and see the results on them instantly, as well as undo anything
wrong.
If I needed, part of that could include piping all the files through a
command line and replacing what was there.
And it was fast. And it was visual. I could see it all happen with no
apparent delay.
It's not that acme does less. It does things on an orthogonal axis to
emacs. In emacs, to get more capabilities, people tend to resort to
lisp. In acme, to get more capabilities, people resort to building tool
pipelines that *they can also use outside acme*. To me, that's very
important. Emacs solutions typically only work in emacs (true for vim
and zed and on and on ...) whereas acme can be a way to prototype things
that can be used outside acme.
That's kind of plan 9 (to me) in a nutshell: not special purpose
solutions for single tools, but solutions that work across a wide range
of tools.
On Sat, Aug 9, 2025 at 12:53 AM <[email protected]
<mailto:[email protected]>> wrote:
On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
> On Fri, 8 Aug 2025 15:15:50 +0200, <[email protected]
<mailto:[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://www.kergis.com/>
http://kertex.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
<https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-
Delivery options: https://9fans.topicbox.com/groups/9fans/
subscription <https://9fans.topicbox.com/groups/9fans/subscription>
*9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions
<https://9fans.topicbox.com/groups/9fans> + participants
<https://9fans.topicbox.com/groups/9fans/members> + delivery options
<https://9fans.topicbox.com/groups/9fans/subscription> Permalink
<https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-Mff7b8ff811c591ee129b6f06
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
