philosophy of complexity, was Re: [9fans] parm server: user interaction

philosophy of complexity, was Re: [9fans] parm server: user interaction

[Dworkin Muller]

On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com> 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

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[tlaronde]

On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
> On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com> 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

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 5014 bytes --]

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 <tlaronde@kergis.com> wrote:

> On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
> > On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com> 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-Mcda51d76b8c34828dc32856b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: Type: text/html, Size: 7312 bytes --]

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[Dworkin Muller]

On Sat, 9 Aug 2025 15:08:21 -0700, ron minnich <rminnich@gmail.com> wrote:
rminnich> Just a reminder, if you get too stuck in an emacs frame of mind, you're
rminnich> really going to miss the full power of acme specifically, and plan 9 in
rminnich> general.

For the record, I'm not advocating one or the other, just trying to
work out where the dividing line is for `do it in a bunch of other
processes' versus `do it in a single process'.  I have a fair idea of
where that line is for TOPS-20, RT-11, early Unix, and current
Unices.  My belief is that for Plan 9, it's about the same as for
early Unix - processes are cheap, so it's better to throw lots of
existing ones at a problem than to try to do more in a single one.

In the early Unix case, this was at least partly driven by hardware
considerations.  You didn't have a lot of memory, so no single process
really *could* do a lot.  So make it cheap to create them, and then to
chain them (as opposed to using temporary files).  Plan 9 appears to
have the same basic philosophy, even if the original hardware
constraints no longer apply.

rminnich> It's not that acme does less. It does things on an orthogonal axis to
rminnich> emacs. In emacs, to get more capabilities, people tend to resort to lisp.
rminnich> In acme, to get more capabilities, people resort to building tool pipelines
rminnich> that *they can also use outside acme*. To me, that's very important. Emacs
rminnich> solutions typically only work in emacs (true for vim and zed and on and on
rminnich> ...) whereas acme can be a way to prototype things that can be used outside
rminnich> acme.
rminnich>
rminnich> That's kind of plan 9 (to me) in a nutshell: not special purpose solutions
rminnich> for single tools, but solutions that work across a wide range of tools.

That's kind of separate from my original question (using it as a
display engine), but equally relevant.

Thanks for the perspective.

Dworkin

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-Mb2a2bcc6c51f3681891f0104
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[sirjofri via 9fans]

10.08.2025 00:20:45 ron minnich <rminnich@gmail.com>:
> 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. 

I can give you another acme example. Some time ago I ported part of the writer's workbench (wwb) to plan 9, just because I was curious. Because I'm mainly using acme, I wrote some very small helper scripts that can call the wwb tools from within acme, and transform the output to something that suits plan 9 world (plumbable text).

The thing is, wwb knows nothing about plan 9, or acme. It was built for Unix and has probably never seen a plan 9 system before. Making it work in acme is just a standard rc script (and rc doesn't care about acme), and is only a matter of calling the program and piping it's output through sed for some processing.

Looking at the code of wwb, I assume it was written in a time where everything on Unix was written with ed. I guess they'd print out the issues wwb found, then run ed to fix them. They probably had no other editor, or at least no visual one.

Btw, I occasionally use those tools when writing. Since I'm not a native English speaker, they sometimes help a lot. There are more modern tools out there, but they probably won't work on plan 9.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T9209adeaba1b3a8a-M917c97458209424cf48036ea
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[tlaronde]

On Sat, Aug 09, 2025 at 03:08:21PM -0700, 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.
> 
>[...] 
> 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.

This is exactly my inclination (mathematical "partition") [Note: I'm
not an emacs user.]

But I made an interesting exercise this week-end. I was on the train,
again, and brought with me Vita Nuova printed volume of "Plan9 3rd
Edition, Programmer's Manual [Documents]" to re-read "Plan 9 from Bell
Labs" by Rob Pike and al.

And I asked myself: if I was to "edit" or "update" the document,
considering Nix primilarily but not only:

        a) Would Nix mandates so huge modifications that it would be
regarding Plan9 as a big departure that Plan9 is regarding Unix?

        b) Would a policy of allocation of resources, taking into
account building a special environment and tying some programs to some
kernel-cores fit in the plan 9 namespace scheme?

        c) Is there specific points that I would date to judge having
not hit on the nail?

The answer for a) is No: Nix fits quite well in the whole scheme, it
is a mandatory refinement, it imposes only to add something to the
scheme, not to modify things---The key point being that a "system" has
to be regarded as whatever processors tightly tied and sharing memory
with a MMU, and that inside such a system one will have to refine more
the species, because, for example, "riscv" doesn't mean a lot by
itself: the ISA is modular so not every riscv processor can interprete
every instruction.

The answer for b) is Yes: the way Plan9 builds namespace can be
extended, in this case once more by adding possibilities, not by
modifying the scheme. The questions that arise (expressed in another
thread) concerning setuid and setting an environment have all to do
with "what has to be definitively attached to a file?": the rwx
permissions? Is is a way of modifying the namespace, so it is not
"definitively attached". The user having authority (to modify it and
to propose it)? This one yes. The true nature of the file? This one
yes, it should: in plan9 this nature is given by the file hierarchy
(compatible binary under amd64/; scripts under rc/ etc.); should it be
explicitely set on the file level? Are the binaries so encoded that
the ISA (including for riscv the optional) can be retrieved from some
defined place in the file?
        => ACS and variants are, for me, a nightmare. And they are
generally attached to file systems. Tying some programs to some cores
in the namespace seems more simple, because "The file system model is
well-understood, both by system builders and general users, so
services that present file-like interfaces are easy to build, easy to
understand, and easy to use." I would not change one word to this...

The answer for c) is Yes: the part that I would alter the most are
"The Command-Level View". The so-called GUI and the "windows" are
red-herrings. The difference is that you have whether a 1D interface
(you can interact and see only a line) or a 2D interface (you can see
simultaneously several different rows).

With 1D, you have no choice: you are echoing what you enters at the
very same place where what the program generates is displayed
intermixed with what the program spits about errors.

If you have the opportunity to display simultaneously different rows,
you will echo your input in one place, the output in another one, and
the errors still elsewhere.

The "window" is not key: it is an implementation detail (a subset of
rows). The important thing is 2D versus 1D.

Once this is understood, you realize that even with 1D, you could use
ed(1) to write and edit your commands before sending them (w!rc), giving
you edition, history and scripting! Trying, at least, to use the one
line of display you have at disposal to at least separate in a timely
manner when it is used for stdin, when it is used for stdout, and when
it is used for stderr (I personnally think there should be a stdstat
to send messages about progression of processing or help messages,
that are not errors).

To come back to the beginning: I do suggest to you guys to take "Plan
9 from Bell Labs" and to "edit" it, to think about what to change,
what to add, what to remove. The main structure holds; this doesn't
mean that everything has to stay the same. It can be even more Plan9ish ;-)
-- 
        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-M4a6f727e8245add071eca1d7
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[Steve Simon]

i wrote suggest(1) a spelling suggestion tool.
spell is good for finding mistakes but i am dyslectic which means i can see the spelling is wrong but i cannot work out how to correct it.

this works on the command line or could be wrapped to work in acme.

-Steve
  

> On 10 Aug 2025, at 2:11 pm, sirjofri via 9fans <9fans@9fans.net> wrote:
> 

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tef913feab2540fb4-M7e62e60bb93d04a621037231
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[sirjofri via 9fans]

10.08.2025 18:25:04 Steve Simon <steve@quintile.net>:

> i wrote suggest(1) a spelling suggestion tool.
> spell is good for finding mistakes but i am dyslectic which means i can see the spelling is wrong but i cannot work out how to correct it.
>
> this works on the command line or could be wrapped to work in acme.

Nice!

In general, I like to refer to editors like acme as an IDE, but not an "integrated development environment". I refer to it as an "integrating development environment" instead, as it doesn't provide a fully integrated solution to certain problems, but is constructed in a way that makes it easy to integrate other tools of the environment (like the active version of "integrate") and be integrated (passive) into an existing environment.

Like, instead of using the IDE to never touch any other tool, it provides enough surface for the developer to actually use the other tools directly in an integrated way.

What would still be nice is a better integration between acid and acme. Like, setting breakpoints on the editor line, printing the value of the selected variable and stuff like that. I want to work on it, but I have a few other projects before that.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tef913feab2540fb4-Mc4a3cb6fde02e52a8b2e636e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: philosophy of complexity, was Re: [9fans] parm server: user interaction

[Willow Liquorice]

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 <tlaronde@kergis.com 
> <mailto:tlaronde@kergis.com>> wrote:
> 
>     On Fri, Aug 08, 2025 at 10:53:31PM -0600, Dworkin Muller wrote:
>      > On Fri, 8 Aug 2025 15:15:50 +0200, <tlaronde@kergis.com
>     <mailto:tlaronde@kergis.com>> 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