Re: [9fans] Next Generation Acme

[Mathieu Bivert <mathieu.bivert@gmail.com>]

[-- 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 --]