Live data from Hacker News

A Tour of Acme (2012)

research.swtch.com

31–40 of 61 posts

Re: A Tour of Acme (2012)

#31
post #4

That video gets off to a very slow start but by minute 10 or so some very interesting features are on display. Some that stuck out were using filenames plus regexes or line numbers to create links in text files, a text file that is also a shell session, things that have been done in vi/emacs but this editor is mouse-centric so it looks very different.

The emphasis on "integrating development environment" is better experienced than what YouTube can render.

I would add to your list:

- acme is complemented by the plumber, which acts according to user defined rules when receiving a text selection (and context)

- anything in acme is text, which is editable. Menu bar, buffers, shell window... the editable dumb terminal is great.

- acme features a 9p fs "api" to access its state, and modify it, with any program. Go is first class citizen.

Acme cannot be used though ssh in a terminal nor on a iPad though :)

Re: A Tour of Acme (2012)

#32
post #27

I'm using it as my day to day tui (with an scratch buffer). I have a index file where I store "shortcuts" to lot of fs places. Also I store action logs of whatever related to shell. For example, a file rabbit.md, it starts with the snippet to portforward the k8 service.. but I also have there some curls to clean or manage things. Files are more or less like a notebook (but everything can be executed or it's just a mi…

"tui"?

Re: A Tour of Acme (2012)

#33
post #16

I use Acme (from Plan9Port) as my every-day editor for work. I run it full-screen on a 4K monitor. I've got a co-worker who likes to grumble about mice, but somehow when we're debugging something on a call, I'm always in the appropriate file at the appropriate line number long before he is :) There are some tools (acmego [9fans.net/go/acme/acmego], A [github.com/davidrjenni/A]) that make working with Go a lot more pl…

> but somehow when we're debugging something on a call, I'm always in the appropriate file at the appropriate line number long before he is :)

I’d enjoy seeing these parallel workflows happening, and seeing where Acme is a better , or where it punts and has a completely different paradigm, besting your coworker (and vice versa).

Re: A Tour of Acme (2012)

#34
post #16

I use Acme (from Plan9Port) as my every-day editor for work. I run it full-screen on a 4K monitor. I've got a co-worker who likes to grumble about mice, but somehow when we're debugging something on a call, I'm always in the appropriate file at the appropriate line number long before he is :) There are some tools (acmego [9fans.net/go/acme/acmego], A [github.com/davidrjenni/A]) that make working with Go a lot more pl…

Another thing I forgot to mention: Acme can be controlled programmatically, and there are Go bindings, so I wrote my own little mpd client to play music while I worked. You can see it at the bottom of the leftmost column in the screenshot... looks like Blue Oyster Cult was playing when I took the shot. It wasn't a lot of code (https://github.com/floren/Ampd)

Re: A Tour of Acme (2012)

#35
post #5
post #3

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 E…

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 … he…

> 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.

Re: A Tour of Acme (2012)

#36
post #3

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 E…

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.

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 :)

Re: A Tour of Acme (2012)

#37
post #5

Earlier quoted context omitted.

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 … he…

> 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

Re: A Tour of Acme (2012)

#38
post #6
post #5

Earlier quoted context omitted.

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 … he…

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 par…

> 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!

Re: A Tour of Acme (2012)

#39
post #32
post #27

I'm using it as my day to day tui (with an scratch buffer). I have a index file where I store "shortcuts" to lot of fs places. Also I store action logs of whatever related to shell. For example, a file rabbit.md, it starts with the snippet to portforward the k8 service.. but I also have there some curls to clean or manage things. Files are more or less like a notebook (but everything can be executed or it's just a mi…

"tui"?

text/terminal user interface.

Re: A Tour of Acme (2012)

#40
post #36

Earlier quoted context omitted.

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.

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…

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 “/“.

Post reply on HN