My impression so far with acme is that it fills the "IDE" gap much
more than the "text editor" gap. I watched a screencast by Russ Cox
(
https://www.youtube.com/watch?v=dP1xVpMPn8M) and the appealing
features were mostly around co-ordination of windows rather than the
contents of the windows themselves. Being able to right-click a file
reference (to redirect directly to a failing test, for example) is
handy.
It's kind of funny that they insist on using a GUI, but all of the
windows are designed to render text and nothing else. I wonder whether
a similarly designed program, with mouse chording replaced by....
customisable buttons?, and the acme windows replaced by terminals,
would provide many of the gains with less weirdness.
On Sat, Feb 12, 2022 at 2:30 PM Ethan Marshall
<lists_AT_ethanjmarshall.co.uk> wrote:
>
> > Acme looks extremely neat. Mouse
> > chording is a strange concept (which doesn't play nicely with my
> > laptop mouse)
>
> This is something that I fundamentally disagree with the designers of
> acme on, actually. I think that mouse "chording" or mouse-based
> shortcuts of any kind are slow and wasteful of precious time.
>
> When entering text, you keep your hands on the keyboard. I see no reason
> why we should introduce yet another input device for simply editing or
> transforming the text. This is why so many programs naturally gravitate
> toward cursor-addressed, textual editing. vi is designed to keep your
> fingers on the home row when moving the cursor, so touch typing is meant
> to be easier. Not only is this a stroke of genius (something that I feel
> Emacs never succeeded in), it also has wide, practical implications on
> your editing of text. Why should I reach for a mouse to cut the previous
> section of text when I can keep using the current input device? Rather
> than moving my hands over an inch, instead I can not move them at all
> and get the same result, the only requirement being that I press escape
> first.
>
> The usual counter-argument for this is that the keyboard is an imperfect
> device for this situation, as it was not designed for anything but
> inputting characters. So - in theory - the time saved from using a
> device meant for this purpose should be better. However, practice again
> teaches us that this is not the case. Mice are the bane of most users'
> lives when they are forced to use them for editing text. You have to
> take your hand off the keyboard, move them to some arbitrary location,
> correctly manoeuvre the mouse, move back to the initial position and
> finally edit your text. After all this, you may have to repeat the
> process to navigate to the end of the text.
>
> Even if the mouse were, in fact, the perfect time-saver that we are
> told, it is not designed for such shortcuts and chording. The mouse has
> three buttons. These were intended with three very clear purposes. The
> keyboard usually has 104+ keys on it for usage in key shortcuts. The
> mouse? Three. If we assume chording, a theoretical maximum of nine
> shortcuts. However, to access them, you have to memorize a nonsensical
> pattern of M1-M2 (Emacs style). Instead, to delete text in my silly,
> inefficient visual editor, I just press d on my keyboard.
>
> This may just be me being a perfectionist who likes to edit back what he
> has just written, or it may just be something that I feel personally
> about mice, but I cannot understand why you would build an editor for
> programmers which does not use keyboard bindings.
>
> I have tried acme and sam. Both have their benefits, and I like the some
> of their ideas. I tried acme for equal to or greater than the amount of
> time which I spent learning vi(m) - and I just cannot like it.
>
> Ethan
>
Received on Sat Feb 12 2022 - 16:08:13 CET