Re: [9fans] Next Generation Acme

[Willow Liquorice <willow@howhill.com>]

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