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
