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
