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
