Hacker News Reader

Comment by bitwize | Hacker News Reader

Acme is an incredible, fascinating editor... that relies too much on rat wrestling to be useful to me. I really find it interesting how it takes advantage of Plan 9's aggressive Unix philosophy to provide functionality that would've been plugins or extensions in other editors as separate C programs or scripts.

But having to use the mouse for everything just drives me nuts. It's easier for my fingers to acquire even Emacs keybindings than it is for me to acquire the mouse and point at something with any precision.

View on HN

It would not be infuriating if basic movements were possible using the keyboard, such as the classic left-down-up-right.

As for key binding, it’s pretty easy to add that as external tools, thanks to the 9p interface.

Left and right already works.

Up and down can't work, because acme was designed for proportional fonts, and many of us acme users use proportional fonts. Up and down are not well defined/not useful with proportional fonts.

Up and down works just fine in just about every word processor out there, using proportional fonts.

> Up and down can't work, because acme was designed for proportional fonts, and many of us acme users use proportional fonts. Up and down are not well defined/not useful with proportional fonts.

It can work with proportional fonts. Word for instance defines it well enough to be useful. Rather than down taking you to the same column on the next line, it just takes you to the character rendered at a similar x coordinate on the next line.

And this is useful when writing code how?

I'd use such a feature if I had to fill a table, and wanted to move to the same column on a different row. But with proportional fonts, the columns don't line up. So yes, it can move to the same x coordinate, but why is this useful?

> And this is useful when writing code how?

It's useful for general text navigation, and writing code is an instance of that.

> I'd use such a feature if I had to fill a table, and wanted to move to the same column on a different row. But with proportional fonts, the columns don't line up. So yes, it can move to the same x coordinate, but why is this useful?

"Doesn't work well for use case X" != "not useful [in general]"

If your text is laid out assuming fixed-width fonts, and it's important for you to move to the same column in a different row, then just use fixed-width fonts and the method I described would work as you expect.

Word processors use up/down keys to move up/down one line, at the same index, or the beginning or the end of the previous ‘ next line, if they exist. It can work.

Acme is opinionated and it’s a good thing if it fits its userbase. I am actually quite fond of many design decisions and maintain patches to workaround defaults that could drive me insane.

My personal feeling is negative on this matter, just as if I would need to reach to the mouse to delete a character. Up and down mapped to something like page up / page down feels as infuriating as those website that hijack scroll and back button.

I'd just take a look at some patches out there. There's a lot of usability tweaks existing for acme.

however I still think acme is a conflagration of confusion. It has programs, inside of it, it's a text editor, a terminal, but breaks the interface of /dev/draw so it doesn't properly multiplex by rio.

Often stated, and I imagine to be true, acme was to be a full replacement for rio almost, but it ends up falling short of that.

I am not bothered by acme / rio issues, since I use acme on plan9port.

However, I have been maintaining a set of patches, including up/down and additional goodies such as bindings for save, copy, cut, paste. Some of them are actually hard coded for Mac (cmd modifier), but not for Linux. It’s workable.

The golang port, edwood, features the same limitations, in my opinion.

I’ve never tried it, but always kind of assumed such basic keystrokes just worked as expected. Now I know I shouldn’t bother with it.

Left and right work as expected. Up and down scroll.

People frequently say this sort of thing, but it's so rare for me to want to move precisely one line up--more usually, I want to move N lines up and M characters over. By the time I've mashed the arrow keys (or hjkl) enough to get there, I could have just as easily grabbed the mouse. Of course editors like vi and emacs have much more powerful movement capabilities, but those aren't "classic left-down-up-right".

What I'd probably most appreciate in Acme is a shortcut equivalent to / in vi, for those situations where I can see a bit of text I want to get to and it'd just be faster to hit (hypothetically) Ctrl-J and type a few characters vs grabbing the mouse. But I don't miss it often enough to go hacking the source :)

Being also a vim user, I prefer the arrow keys to the idiomatic hjkl, for anything within a “block” or paragraph. If further away, I would probably “/“ too sh

Maybe I am an incorrigible arrow addict !

There’s a patch to jump to the bar from the text using a keychord, to type and right click, as an alternative to “/“.

It is definitely an interesting editor, and it has some neat ideas. But when I compare the masterpiece that is Acme on Plan 9 with the — frankly — cobbled-together heap that is Emacs … I would prefer to use Emacs, because Emacs does more for me than Acme on Plan 9.

I think that says a lot about the fundamental power of dynamic languages in general and Lisp in particular. Plan 9 is in a lot of ways the zenith (or … heh … acme) of what C and Unix can do. It is awesome, it is wonderful, it is better in every technical way than Linux or true Unix. But it pales in comparison to the hacked-together incomplete Lisp machine that is Emacs.

Imagine how much better off we would be with true Lisp machines on our desks and in our data centres!

(in my ideal world this 21st-century Lisp machine would actually take a lot of ideas from Plan 9, and even some from Emacs)

Have you had a look at Oberon? That's where Acme took most of its stuff from, and it being a fully integrated language, the interfaces between the parts are a lot cleaner.

That's what Oberon, Smalltalk and even Emacs Lisp have that's not as good in Unix. Files full of plain text plus executables are a good foundation, but they're also quite unstructured and so is communication between them. Command line parameter parsing is an absolute nightmare. Whereas if you use a language directly, that's just function parameters and you're also not restricted to arrays of strings as your sole communication format.

Not that Emacs is doing all that it can with that, as it's usually used as an intermediary between a high-falutin' language environment and text files.

> Have you had a look at Oberon?

No, but it is on my list of things to look at when I get some free time. It sounds like another one of those tantalising might-have-beens.

One of my retirement projects will be to write an OS as it should be, given what we have learned from decades of research and use. I imagine that I will never complete it, but it will give me something to do with my time!

> is the acme of what C and Unix can do

No way, acme is just ONE direction for Unix and C. Vi is another direction, as well as a ton of other editors that were made for Unix and C.

I was making a pun: 'acme' means the highest point.

But I also disagree with you: acme is strictly more powerful than vi, and vim is just a Greenspunned Emacs. Greenspun's Tenth Rule holds that 'any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp'; I contend that vim is an ad-hoc, informally-specified[0], bad-taste (seriously, have you ever looked at Vimscript?) reimplementation of Emacs's functionality.

It does, however, have better keybindings than Emacs does by default.

0: outside of the POSIX stuff it gets from vi, that is

Emacs is built on Unix like vi and everything else. The fact that vi has a less elegant language doesn't affect me, because I don't see much value in adding extensions to the editor. What I need is a sane user interface, which vim provides.

The original Emacs was written for Multics at a time when people outside of Bell Labs were largely unaware of the existence of Unix[1]. It also doesn't follow the Unix philosophy of making small CLI utilities composed with pipes. As I understand it (though I haven't used it), Acme is extended with external programs which communicate through pipes just like the traditional Unix utilities.

[1]: https://www.jwz.org/doc/emacs-timeline.html

The first version of Emacs was not made in lisp, instead it used TECO, a horrible programming editor/programming language.

It is convenient with a pointer or trackpad close to your thumb. Three buttons associated with such pointer or trackpad would be nice, but it would work much better with more buttons. Two or three buttons for each hand would be awesome.

I used acme for years with a laptop and no external mouse, just using the trackpad (and trackpoint). I never missed more buttons.

So currently control, option, and command are three buttons. I'm wondering if it would be better with the left and right sides functioning differently. You could get many more chording combinations.

Sorry, but a trackpad or TrackPoint just makes things worse. It's much harder to precision-highlight a chunk of text with those than with the mouse (or my Logitech TrackMan).

Sometimes it just feels faster to think about and execute keyboard shortcuts, although the actual tests I've read about that seem to be from the early Macintosh age, which feels a bit like measuring anything by looking at your university's students...

I don't understand what you're saying.

That evidence of keys being faster than the mouse are old?

Why would the speed change over time? It's measuring the human, not the machines; and we are no faster.

I think speed could change over time because our generation uses computer and common shortcuts from childhood. People who participated in the study could have been much less experienced users at that time and the shortcuts might have been less established and more varying from platform to platform

That's an assumption that needs to be verified. Sure, over a generation it's quite unlikely that evolution made for better mouse users.

But we don't need to go that far. I mean, when you were testing during the development of the Mac, it was what, 1983? The mouse was a new thing, CUA didn't exist yet, I doubt that many vim and emacs users were part of the target group.

I doubt that speed changes if you test the same demographic as back then, although it's harder to find people as unaccustomed to mice.

In addition, has there ever been a test that includes mouse chords as used in Acme/Oberon?

Reply on news.ycombinator.com