* Re: [9fans] Next Generation Acme
2025-05-13 12:20 [9fans] Next Generation Acme Aram Hăvărneanu
@ 2025-05-13 12:51 ` Mark van Atten
2025-05-13 13:51 ` Aram Hăvărneanu
2025-05-13 13:24 ` [OBORONA-SPAM] " lego12239
` (4 subsequent siblings)
5 siblings, 1 reply; 11+ messages in thread
From: Mark van Atten @ 2025-05-13 12:51 UTC (permalink / raw)
To: 9fans
On Tue, 13 May 2025 at 14:33, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
> 2. Make it multi-process/multi-machine again (like Sam, but better).
For the time being, this may be of interest:
https://9fans.topicbox.com/groups/9fans/T5addc17a0e19cd91-Mcb2e189b0570c6833f195230
(I'm not its author, I just remembered it.)
Mark.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-M474a043f6f18ee4e660a427b
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [OBORONA-SPAM] [9fans] Next Generation Acme
2025-05-13 12:20 [9fans] Next Generation Acme Aram Hăvărneanu
2025-05-13 12:51 ` Mark van Atten
@ 2025-05-13 13:24 ` lego12239
2025-05-13 14:16 ` Aram Hăvărneanu
2025-05-13 14:15 ` Shawn Rutledge
` (3 subsequent siblings)
5 siblings, 1 reply; 11+ messages in thread
From: lego12239 @ 2025-05-13 13:24 UTC (permalink / raw)
To: 9fans
On Tue, May 13, 2025 at 02:20:56PM +0200, Aram Hăvărneanu wrote:
> Here are some of my ideas for the next generation of Acme. Please
> disagree or add more.
Hi. My imho.
> 1. Keep the Acme UI, but add rows, not just columns. Potentially
> make each window a full multiplexor (like rio(1), not 100% sure
> about this).
The today common monitor ratio is 16:9. Thus, creating a some row screen
wide just makes vertical space for other window is too small. As for me, i
never needed this :-).
> 5. Add enough ANSI terminal sequences support to win(1) such that
> workarounds are no longer necessary for common CLI software (git(1),
> grep(2), etc).
This might be good.
> 6. Replace structural regular expression with something based on
> Tree-sitter, but with an actual usable syntax.
Please, no replacing. Structural regexp should stay. Otherwise we
break many scripts.
> 12. Multiple window support, in the sense of multiple operating
> system windows.
Do you mean multiple instances of acme? Multiple windows of one
instance seems inconvenient.
> 14. Elastic tab support, or some better way of dealing with tabular
> data.
What do you mean?
> 15. A better way of dealing with resize, right now acme does really
> bad when moving from a big monitor to a laptop because it preserves
> layout. I'd like a way to globally set layout independent of Dump.
Work with layout between different resolutions is hard. I also run
the same acme instance on different screens (external big and laptop).
But if you save sizes of windows in percents, you got on laptop too small
windows in characters units. I mean, i want all windows be 80 chars wide.
And on big external monitor(16:9) i have 2 such cols with big font. But
on small laptop screen this session can't have 2 80 chars wide cols with
the same font. In this case, we must choose another font. But i dont'
want smaller font :-). This hard to solve automatically, i think.
> 16. No settings, no options, no themes, no syntax highlighting, no
> keyboard based interface (the mouse is king).
As for me, it would be better to have some config, because more features -
more options. And even now my alias for acme looks like this:
alias acme='PATH=~/bin/acme:$PATH acme -a -f /mnt/font/DejaVuSerif/15a/font -F /mnt/font/LiberationMono/15a/font'
On the other side, the alias is working and this is not trouble :-).
But some keyboard shortcuts would be useful. Something for editing adjacent
lines like:
- go to line up/down
- go to word forward/backward
--
Олег Неманов (Oleg Nemanov)
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-M4e4ca477d145bf00b170e74d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [OBORONA-SPAM] [9fans] Next Generation Acme
2025-05-13 13:24 ` [OBORONA-SPAM] " lego12239
@ 2025-05-13 14:16 ` Aram Hăvărneanu
0 siblings, 0 replies; 11+ messages in thread
From: Aram Hăvărneanu @ 2025-05-13 14:16 UTC (permalink / raw)
To: 9fans
> The today common monitor ratio is 16:9. Thus, creating a some row
> screen wide just makes vertical space for other window is too small.
> As for me, i never needed this :-).
I need this all the time because log files are commonly 300+
characters long.
> Please, no replacing. Structural regexp should stay. Otherwise we
> break many scripts.
I am thinking of a completely new editor.
> Do you mean multiple instances of acme? Multiple windows of one
> instance seems inconvenient.
Multiple windows of one instance (note that multiple instances are
possible, but incredibily inconvenient in plan9port).
>> 14. Elastic tab support, or some better way of dealing
>> with tabular data.
>
> What do you mean?
https://nick-gravgaard.com/elastic-tabstops/
But really, probably something like org-mode or similar would be
better.
> Work with layout between different resolutions is hard. I also run
> the same acme instance on different screens (external big and
> laptop). But if you save sizes of windows in percents, you got on
> laptop too small windows in characters units. I mean, i want all
> windows be 80 chars wide. And on big external monitor(16:9) i have
> 2 such cols with big font. But on small laptop screen this session
> can't have 2 80 chars wide cols with the same font. In this case,
> we must choose another font. But i dont' want smaller font :-).
> This hard to solve automatically, i think.
While no solution is perfect, pretty much any popular existing
editor—VS Code, Zed, JetBrains stuff, etc does this better than
acme.
(Also apologies for the double post, it appears that message delivery
on this list is slow, taking more than 10 minute. And this caused
me think my messages were dropped, and I incorrectly assumed that
was because I was using a wrong e-mail address so I tried with
another one. Really, message delivery should be faster.)
--
Aram Hăvărneanu
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-M6bdea593ca27d2e13a9969ad
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Next Generation Acme
2025-05-13 12:20 [9fans] Next Generation Acme Aram Hăvărneanu
2025-05-13 12:51 ` Mark van Atten
2025-05-13 13:24 ` [OBORONA-SPAM] " lego12239
@ 2025-05-13 14:15 ` Shawn Rutledge
2025-05-13 14:32 ` tlaronde
` (2 subsequent siblings)
5 siblings, 0 replies; 11+ messages in thread
From: Shawn Rutledge @ 2025-05-13 14:15 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 8003 bytes --]
> On May 13, 2025, at 14:20, Aram Hăvărneanu <aram.h@mgk.ro> wrote:
>
> 5. Add enough ANSI terminal sequences support to win(1) such that
> workarounds are no longer necessary for common CLI software (git(1),
> grep(2), etc).
...
> 13. Some sort of minimal markup support. Perhaps with colors. Not
> arbitrary colors, just four or five predetermined colors that
> Acme programs could make use of (for example I'd like to see colors
> in my diffs). This should be done by a third party process writing
> in acme(4), acme(1) should not implement native markdown support
> or anything like that.
It seems to be a core design principle that /dev/text is _only_ text. This purism has been espoused in other contexts: for example the Arcan author is another who apparently doesn’t like that writing a terminal requires a complex state machine which is apt to have bugs: https://arcan-fe.com/2017/07/12/the-dawn-of-a-new-command-line-interface/ (and other such articles). There’s some quote I remember seeing somewhere about every Unix terminal (and even Linux itself, since the kernel started out as a terminal emulator) having an ASR-33 at its heart: such an anachronism, such an ad-hoc standard from the electromechanical days, surely we could do better if we started from scratch. But you know, where do you draw the line: even a space character has an effect on alignment of the next character, and we don’t call it evil. A line feed moves the cursor too! What about a tab? What about a vertical tab then? What is FF good for nowadays? If we don’t like using most of the control codes, why are we wasting so much space at the beginning of the ASCII table with them? But at least a control code is only one byte... Could we use them better for just a few more cases, without having to write a state machine for multi-byte escape sequences? But if we start using a few for styling or defining text spans, maybe pretty soon it’s not enough codes anymore.
A core idea that comes out of the Xanadu project is that assuming you can reliably make references to spans of text, in spite of text getting edited over time (changes that you want to track actually), then you can use those links for everything: for two-way hyperlinks stored separately, for transclusions, and perhaps even for tagging text spans with styles. The set of links is then a bit like a fully-normalized database schema: assume that some records already exist, and make a new table just to link the keys in one table to the keys of another. But being able to make unchanging references to changing text is a tall order.
So I would like to apply this principle to that: /dev/text should stay as it is, and we need a way to apply styling to spans of text within the window. So we need a way to define the start and the end of the span, in spite of any editing that occurs. (There would be some edge cases, just as in any word processor: if you put the cursor at the beginning or end of a styled span and start typing, does it get the span's styling applied or not? You can argue about which way is more correct; but this does not stop anyone from writing word processors that deal with it one way or another.) If you insert a newline somewhere in the window, maybe all the spans referring to lines below that will need updating, or can we be more clever than that somehow?
I’ve been prototyping an application that works that way: I have a device that serves up a 9p filesystem that contains (among other things) a plain text file and a separate spans file, and I modified tail to use draw to render colored text spans rather than just outputting the text itself. (And then developed a more complex client program that renders some application-specific widgets around the colored text.) I think what I’m doing should work, but it’s buggy in practice: tail normally has to read character-by-character backwards from the end of the file to find the line breaks, and now my version has to further assume that the last span at the end of the spans file applies to that last line that was found (thus defining the line number for that line even though we have not counted all the lines in the whole file), and stay in sync (iterating backwards and then forwards again) from there on, even as both files change. (My device actually stores the text in something like a ring buffer, but I’m trying to preserve the illusion that the text and spans both keep growing indefinitely, forward from where it was at the time that a particular client opens both files.) So maybe that difficulty illustrates why people like to mix formatting into their text in such a myriad of ways (terminal codes, HTML, markdown or whatever): either way you are doing multiplexing, but the more explicitly the spans are mapped to the text, the more robust it will be. FWIW I will be at iwp9 and can probably do a demo if it still works well enough at that time.
What I would like to do next is modify rio’s window to have a /dev/text.meta/spans file alongside /dev/text, and be able to write to the spans file in case some non-default formatting is desired. Probably each span will just specify a numeric semantic, and then I’ll have a lookup table in another file to map those numbers to specific fonts and colors (so styling is modifiable dynamically). And each time you go back and modify history, your edits will have a different semantic automatically (and thus appear in a different color).
So that’s for color and font support. But one experiment I was also thinking of trying with what we have already: if all you want is full control of one screen-full of text, can you open /dev/text, get the file offset at that time, write your first screen-full, and then each time you update you can just seek back to that offset and overwrite it with the next screen-full, or even make incremental modifications? I didn’t try it yet… but maybe monochrome curses-like UIs are possible that way? Maybe I should try to write a top that way, unless somebody already did it.
I wondered if acme supports graphics (using draw) like the underlying window does: no, it does not, but I suspect that was something that could have eventually happened.
I also wondered how easy it is to make splitters with sub-windows of text (each with a tagline field at the top) like acme does, in my own program. It seems that’s quite a bit of work too: it’s not all library code. Probably we could make it easier. I wanted sub-windows in this toy application that I’m writing though, so I cheated and used Nuklear for now.
> 8. Add support for space-based indentation. Disgusting, but necessary
> (I patched my acme to support this, but it still requires manual
> activation, should be automatic).
What kind of changes?
> 14. Elastic tab support, or some better way of dealing with tabular
> data.
Yes! But I think that code belongs in the window, not acme. I want to be able to pipe tab-separated tables to the terminal anytime and have them lined up. Typewriters made better use of the tab key than most terminals do (except you had to set up the tab stops in advance: you shouldn’t have to do that on a computer). It should become so commonplace that even ls -l can use tabs to line up columns, and if you cat a source file, of course you get indentation looking the same as it does in an editor (if it doesn’t already). And I think adding this feature is probably easy compared to the text-spans stuff I was describing above.
> 16. No settings, no options, no themes, no syntax highlighting, no
> keyboard based interface (the mouse is king).
I wouldn’t break the mouse usage, but actually I want to use the keyboard more. Sorry.
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-Md3c9d0fe2113241d51ac4ddb
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 9874 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [9fans] Next Generation Acme
2025-05-13 12:20 [9fans] Next Generation Acme Aram Hăvărneanu
` (2 preceding siblings ...)
2025-05-13 14:15 ` Shawn Rutledge
@ 2025-05-13 14:32 ` tlaronde
2025-05-13 15:29 ` Jacob Moody
2025-05-17 11:59 ` Willow Liquorice
5 siblings, 0 replies; 11+ messages in thread
From: tlaronde @ 2025-05-13 14:32 UTC (permalink / raw)
To: 9fans
Partly related to this, there is the problem of line editing---calling
this 1D interface---and built on it, 2D editing, and then the
rendering, with a VGA---Video Graphics Array controller, displaying
some bits array in DRAM on a terminal.
For the first part, focusing on text rendering with here TeX or a
derivative, the engine rendering doesn't see / care about non visible
characters ASCII control sequences: these are all discarded or
replaced, before being seen by (here) TeX. (I will lightly touch the
subject during the presentation of my WIP during IWP9.)
So these control sequences can be used to edit the line before feeding
it to TeX---only when entering the EOL will send it to TeX, and
probably using arrow keys will recall a previous line in some
historical buffer.
So the questions for text editing:
1) Taking into account that in some installations there can be no rio
i.e. no 2D interface, but only 1D, would it be sensible to allow also
some control sequences (hence keyboard) to allow editing the current
line? (the only mandatory editor is the only 1D one that is ed(1);
but I speak there about command line editing or, alternatively, being
able to send a line or a sequence of lines from CLI history to some
buffer, editable by ed(1) but not being interpreted unless some
sequence is used to send the edited text to the interpreter---here the
shell)
2) In a 2D interface, would it not be sensible to be able to copy a
portion of text to a buffer, edit it in a buffer, before replacing the
initial text with the edited version?---if there is interpretation,
interpretation is only done with the text, not with the tentative
buffer;
3) The 2D text editing only needs a VGA. The present GPUs are overkill
and their path is only used because the rump VGA is generally attached
to the GPU---some people indeed make hardware adding a timer and a
circuit to be able to drive some monitor, "simply" displaying a
portion of memory on the terminal device. How to correctly segregate
things in the kernel code?
FWIW.
On Tue, May 13, 2025 at 02:20:56PM +0200, Aram H?v?rneanu wrote:
> Here are some of my ideas for the next generation of Acme. Please
> disagree or add more.
>
> Of course, this is all a pipe dream since I have no time to work
> on this, but one can dream... The purpose of this thread is to
> stimulate a discussion about text editing in 2025, more than anything
> else.
>
> 1. Keep the Acme UI, but add rows, not just columns. Potentially
> make each window a full multiplexor (like rio(1), not 100% sure
> about this).
>
> 2. Make it multi-process/multi-machine again (like Sam, but better).
>
> 3. Add a Sam-like menu on B2/B3. It should work like Sam (last used
> selection is default), but behave more like Octopus/Plan B (star-like
> expansion). This can make use of mouse gestures, no need to click
> twice.
>
> 4. Add support for mouse hover.
>
> 5. Add enough ANSI terminal sequences support to win(1) such that
> workarounds are no longer necessary for common CLI software (git(1),
> grep(2), etc).
>
> 6. Replace structural regular expression with something based on
> Tree-sitter, but with an actual usable syntax.
>
> 7. Expand the span for B3 auto-selection to include software that
> doesn't use `file:line:col` convention. Of course the plumber can
> do this, but it requires a manual B3 selection, auto-selection has
> to work.
>
> 8. Add support for space-based indentation. Disgusting, but necessary
> (I patched my acme to support this, but it still requires manual
> activation, should be automatic).
>
> 9. A better way of managing running processes.
>
> 10. A better way to place commands that you'd put in the tag, perhaps
> B2 opens a persistent window for window-specific (not global)
> commands.
>
> 11. Unlike in Plan 9, where paths are short (because you have
> namespaces), in Unix paths are long (because people have poor taste).
> This is annoying to deal with in Acme ATM, but I'm not sure what
> the right design for a solution is.
>
> 12. Multiple window support, in the sense of multiple operating
> system windows.
>
> 13. Some sort of minimal markup support. Perhaps with colors. Not
> arbitrary colors, just four or five predetermined colors that
> Acme programs could make use of (for example I'd like to see colors
> in my diffs). This should be done by a third party process writing
> in acme(4), acme(1) should not implement native markdown support
> or anything like that.
>
> 14. Elastic tab support, or some better way of dealing with tabular
> data.
>
> 15. A better way of dealing with resize, right now acme does really
> bad when moving from a big monitor to a laptop because it preserves
> layout. I'd like a way to globally set layout independent of Dump.
>
> Of course, keep what is already great:
>
> 16. No settings, no options, no themes, no syntax highlighting, no
> keyboard based interface (the mouse is king).
>
> --
> Aram H?v?rneanu
--
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/T4f1a2098b1e1c854-M745aca56b4518561018f4949
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [9fans] Next Generation Acme
2025-05-13 12:20 [9fans] Next Generation Acme Aram Hăvărneanu
` (3 preceding siblings ...)
2025-05-13 14:32 ` tlaronde
@ 2025-05-13 15:29 ` Jacob Moody
2025-05-13 23:20 ` Mathieu Bivert
2025-05-17 11:59 ` Willow Liquorice
5 siblings, 1 reply; 11+ messages in thread
From: Jacob Moody @ 2025-05-13 15:29 UTC (permalink / raw)
To: 9fans
Just to comment on some small points.
On 5/13/25 07:20, Aram Hăvărneanu wrote:
> Here are some of my ideas for the next generation of Acme. Please
> disagree or add more.
>
> Of course, this is all a pipe dream since I have no time to work
> on this, but one can dream... The purpose of this thread is to
> stimulate a discussion about text editing in 2025, more than anything
> else.
>
> 1. Keep the Acme UI, but add rows, not just columns. Potentially
> make each window a full multiplexor (like rio(1), not 100% sure
> about this).
>
> 2. Make it multi-process/multi-machine again (like Sam, but better).
>
> 3. Add a Sam-like menu on B2/B3. It should work like Sam (last used
> selection is default), but behave more like Octopus/Plan B (star-like
> expansion). This can make use of mouse gestures, no need to click
> twice.
>
> 4. Add support for mouse hover.
>
> 5. Add enough ANSI terminal sequences support to win(1) such that
> workarounds are no longer necessary for common CLI software (git(1),
> grep(2), etc).
>
> 6. Replace structural regular expression with something based on
> Tree-sitter, but with an actual usable syntax.
I had tried to get tree-sitter working on 9front one weekend but the code
is quite gnarly. Specifically I recall it using bitfields to make
pointer casts between one struct pointer to another work well enough
(or something to that effect).
I say this to not exclude tree sitter from your considerations, just
as a warning that the code is (in my experience) quite unpleasant to
work with.
>
> 7. Expand the span for B3 auto-selection to include software that
> doesn't use `file:line:col` convention. Of course the plumber can
> do this, but it requires a manual B3 selection, auto-selection has
> to work.
>
> 8. Add support for space-based indentation. Disgusting, but necessary
> (I patched my acme to support this, but it still requires manual
> activation, should be automatic).
>
> 9. A better way of managing running processes.
>
> 10. A better way to place commands that you'd put in the tag, perhaps
> B2 opens a persistent window for window-specific (not global)
> commands.
>
> 11. Unlike in Plan 9, where paths are short (because you have
> namespaces), in Unix paths are long (because people have poor taste).
> This is annoying to deal with in Acme ATM, but I'm not sure what
> the right design for a solution is.
>
> 12. Multiple window support, in the sense of multiple operating
> system windows.
>
> 13. Some sort of minimal markup support. Perhaps with colors. Not
> arbitrary colors, just four or five predetermined colors that
> Acme programs could make use of (for example I'd like to see colors
> in my diffs). This should be done by a third party process writing
> in acme(4), acme(1) should not implement native markdown support
> or anything like that.
>
> 14. Elastic tab support, or some better way of dealing with tabular
> data.
>
> 15. A better way of dealing with resize, right now acme does really
> bad when moving from a big monitor to a laptop because it preserves
> layout. I'd like a way to globally set layout independent of Dump.
One thing on my TODO list has been to better integrate combining
Unicode characters in an editor(or existing editors) for plan 9. Some of that work has
been merged in to 9front now (runegbreak and utfgbreak) which helps
to determine cursor positions when dealing with multi-codepoint graphemes.
All of our existing Unicode code has this assumption that
1 codepoint = 1 abstract character. There's lots of small details in changing
that but I think it would be a useful discussion for a "next generation" editor.
>
> Of course, keep what is already great:
>
> 16. No settings, no options, no themes, no syntax highlighting, no
> keyboard based interface (the mouse is king).
>
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-M5c5b7cafa94dbc358d57cc07
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [9fans] Next Generation Acme
2025-05-13 15:29 ` Jacob Moody
@ 2025-05-13 23:20 ` Mathieu Bivert
0 siblings, 0 replies; 11+ messages in thread
From: Mathieu Bivert @ 2025-05-13 23:20 UTC (permalink / raw)
To: 9fans
[-- Attachment #1: Type: text/plain, Size: 4955 bytes --]
I often consider acme as being a "clumsily programmable set
of text windows". I've often wondered about simplifying it as such.
e.g. replacing 9P by an ~RPC interface (+ an event stream?),
giving a simple, complete programmatic control over the editor.
usual commands (Undo, Snarf, etc.) would all become external
binaries.
the editor's behavior could be fully scripted, and externalized.
defaults resembling acme's current behavior may be provided.
similarly, window management may benefit from being
delegated to a [simply programmable] window manager.
On Tue, May 13, 2025 at 5:36 PM Jacob Moody <moody@posixcafe.org> wrote:
> Just to comment on some small points.
>
> On 5/13/25 07:20, Aram Hăvărneanu wrote:
> > Here are some of my ideas for the next generation of Acme. Please
> > disagree or add more.
> >
> > Of course, this is all a pipe dream since I have no time to work
> > on this, but one can dream... The purpose of this thread is to
> > stimulate a discussion about text editing in 2025, more than anything
> > else.
> >
> > 1. Keep the Acme UI, but add rows, not just columns. Potentially
> > make each window a full multiplexor (like rio(1), not 100% sure
> > about this).
> >
> > 2. Make it multi-process/multi-machine again (like Sam, but better).
> >
> > 3. Add a Sam-like menu on B2/B3. It should work like Sam (last used
> > selection is default), but behave more like Octopus/Plan B (star-like
> > expansion). This can make use of mouse gestures, no need to click
> > twice.
> >
> > 4. Add support for mouse hover.
> >
> > 5. Add enough ANSI terminal sequences support to win(1) such that
> > workarounds are no longer necessary for common CLI software (git(1),
> > grep(2), etc).
> >
> > 6. Replace structural regular expression with something based on
> > Tree-sitter, but with an actual usable syntax.
>
> I had tried to get tree-sitter working on 9front one weekend but the code
> is quite gnarly. Specifically I recall it using bitfields to make
> pointer casts between one struct pointer to another work well enough
> (or something to that effect).
>
> I say this to not exclude tree sitter from your considerations, just
> as a warning that the code is (in my experience) quite unpleasant to
> work with.
>
> >
> > 7. Expand the span for B3 auto-selection to include software that
> > doesn't use `file:line:col` convention. Of course the plumber can
> > do this, but it requires a manual B3 selection, auto-selection has
> > to work.
> >
> > 8. Add support for space-based indentation. Disgusting, but necessary
> > (I patched my acme to support this, but it still requires manual
> > activation, should be automatic).
> >
> > 9. A better way of managing running processes.
> >
> > 10. A better way to place commands that you'd put in the tag, perhaps
> > B2 opens a persistent window for window-specific (not global)
> > commands.
> >
> > 11. Unlike in Plan 9, where paths are short (because you have
> > namespaces), in Unix paths are long (because people have poor taste).
> > This is annoying to deal with in Acme ATM, but I'm not sure what
> > the right design for a solution is.
> >
> > 12. Multiple window support, in the sense of multiple operating
> > system windows.
> >
> > 13. Some sort of minimal markup support. Perhaps with colors. Not
> > arbitrary colors, just four or five predetermined colors that
> > Acme programs could make use of (for example I'd like to see colors
> > in my diffs). This should be done by a third party process writing
> > in acme(4), acme(1) should not implement native markdown support
> > or anything like that.
> >
> > 14. Elastic tab support, or some better way of dealing with tabular
> > data.
> >
> > 15. A better way of dealing with resize, right now acme does really
> > bad when moving from a big monitor to a laptop because it preserves
> > layout. I'd like a way to globally set layout independent of Dump.
>
> One thing on my TODO list has been to better integrate combining
> Unicode characters in an editor(or existing editors) for plan 9. Some of
> that work has
> been merged in to 9front now (runegbreak and utfgbreak) which helps
> to determine cursor positions when dealing with multi-codepoint graphemes.
> All of our existing Unicode code has this assumption that
> 1 codepoint = 1 abstract character. There's lots of small details in
> changing
> that but I think it would be a useful discussion for a "next generation"
> editor.
>
> >
> > Of course, keep what is already great:
> >
> > 16. No settings, no options, no themes, no syntax highlighting, no
> > keyboard based interface (the mouse is king).
> >
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-M998cdef58673174fab3f2b11
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
[-- Attachment #2: Type: text/html, Size: 7000 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [9fans] Next Generation Acme
2025-05-13 12:20 [9fans] Next Generation Acme Aram Hăvărneanu
` (4 preceding siblings ...)
2025-05-13 15:29 ` Jacob Moody
@ 2025-05-17 11:59 ` Willow Liquorice
5 siblings, 0 replies; 11+ messages in thread
From: Willow Liquorice @ 2025-05-17 11:59 UTC (permalink / raw)
To: 9fans
I'm not convinced that a "new acme" is the right direction. Its file
system is a different language to rio, and I am told this requires
special case handling in some programs. At any rate, having a program do
too much for itself is not The Way™.
My (uneducated) suggestion would be to give lola_ editable tags, then
twiddle the menu behaviour. Tiling could be achieved using a riow-like
program. There's your acme!
Want special plumbing behaviour? Run another plumber. Plumber not smart
enough? *Improve the plumber, which improves it everywhere.* Want to
encapsulate things? Use namespaces and a subrio/sublola.
I'll take the opportunity to share some thoughts I've been having on
text editor internals.
I recently encountered multi-zippers_: Pavel Panchekha's generalisation
of the zipper construction to multiple locations within a data structure.
A piece table with a multi-zipper could work, in principal, as a
representation of multi-caret editor state for a given file. In this
case the "region tree" would be linear, and the piece that a cursor lay
within would be split between the forwards and backwards edges.
As a natural consequence of the underlying data structure, a caret will
remain in position even if earlier text is modified.
It occurred to me that the dangling and attached subtrees Pavel
describes are, in effect, self-edges of the region tree (also as
described). As the contents of an edge are ordered, all nodes can be
ordered by ordering the edges and cursors.
With modifications to accommodate this ordering, documents with a
natural tree structure (i.e. anything XML, like SVG and OpenDocument)
could be manipulated using a common toolkit.
Best wishes,
Willow
_lola: https://only9fans.com/aap/lola/HEAD/info.html
_multi-zippers: https://pavpanchekha.com/blog/zippers/multi-zippers.html
On 13/05/2025 13:20, Aram Hăvărneanu wrote:
> Here are some of my ideas for the next generation of Acme. Please
> disagree or add more.
>
> Of course, this is all a pipe dream since I have no time to work
> on this, but one can dream... The purpose of this thread is to
> stimulate a discussion about text editing in 2025, more than anything
> else.
>
> 1. Keep the Acme UI, but add rows, not just columns. Potentially
> make each window a full multiplexor (like rio(1), not 100% sure
> about this).
>
> 2. Make it multi-process/multi-machine again (like Sam, but better).
>
> 3. Add a Sam-like menu on B2/B3. It should work like Sam (last used
> selection is default), but behave more like Octopus/Plan B (star-like
> expansion). This can make use of mouse gestures, no need to click
> twice.
>
> 4. Add support for mouse hover.
>
> 5. Add enough ANSI terminal sequences support to win(1) such that
> workarounds are no longer necessary for common CLI software (git(1),
> grep(2), etc).
>
> 6. Replace structural regular expression with something based on
> Tree-sitter, but with an actual usable syntax.
>
> 7. Expand the span for B3 auto-selection to include software that
> doesn't use `file:line:col` convention. Of course the plumber can
> do this, but it requires a manual B3 selection, auto-selection has
> to work.
>
> 8. Add support for space-based indentation. Disgusting, but necessary
> (I patched my acme to support this, but it still requires manual
> activation, should be automatic).
>
> 9. A better way of managing running processes.
>
> 10. A better way to place commands that you'd put in the tag, perhaps
> B2 opens a persistent window for window-specific (not global)
> commands.
>
> 11. Unlike in Plan 9, where paths are short (because you have
> namespaces), in Unix paths are long (because people have poor taste).
> This is annoying to deal with in Acme ATM, but I'm not sure what
> the right design for a solution is.
>
> 12. Multiple window support, in the sense of multiple operating
> system windows.
>
> 13. Some sort of minimal markup support. Perhaps with colors. Not
> arbitrary colors, just four or five predetermined colors that
> Acme programs could make use of (for example I'd like to see colors
> in my diffs). This should be done by a third party process writing
> in acme(4), acme(1) should not implement native markdown support
> or anything like that.
>
> 14. Elastic tab support, or some better way of dealing with tabular
> data.
>
> 15. A better way of dealing with resize, right now acme does really
> bad when moving from a big monitor to a laptop because it preserves
> layout. I'd like a way to globally set layout independent of Dump.
>
> Of course, keep what is already great:
>
> 16. No settings, no options, no themes, no syntax highlighting, no
> keyboard based interface (the mouse is king).
>
------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4f1a2098b1e1c854-Md8d4f027a6301431bbf2a382
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
^ permalink raw reply [flat|nested] 11+ messages in thread