Live data from Hacker News

A Tour of the Acme Editor

research.swtch.com

1–10 of 91 posts

Re: A Tour of the Acme Editor

#2
Acme was also Dennis Ritchie's editor of choice, there is a picture of him and his working environment here:

http://acme.cat-v.org

Also wish Russ had shown acme in a full screen setup, one of the most awesome things about acme is how well it manages having tons of windows, and you don't get a real feeling for it without seeing it done in a real full screen large environment.

Re: A Tour of the Acme Editor

#3
The ':' syntax for inner reference is great. As the OP describes it, hypertext for files.

With per format program, possibly implicitely called based on extension, it could be extended to structural reference.

/foo/bar.c:function[2]/statement[3] would call an ANSI C parser and return the substream enclosing the :/expr/ passed.

Re: A Tour of the Acme Editor

#4

The ':' syntax for inner reference is great. As the OP describes it, hypertext for files. With per format program, possibly implicitely called based on extension, it could be extended to structural reference. /foo/bar.c:function[2]/statement[3] would call an ANSI C parser and return the substream enclosing the :/expr/ passed.

That's how the plumber works: http://doc.cat-v.org/plan_9/4th_edition/papers/plumb

Re: A Tour of the Acme Editor

#5
post #4

The ':' syntax for inner reference is great. As the OP describes it, hypertext for files. With per format program, possibly implicitely called based on extension, it could be extended to structural reference. /foo/bar.c:function[2]/statement[3] would call an ANSI C parser and return the substream enclosing the :/expr/ passed.

That's how the plumber works: http://doc.cat-v.org/plan_9/4th_edition/papers/plumb

I was thinking of something at the os level, like the namespaces for windows.

Re: A Tour of the Acme Editor

#7
post #4

Earlier quoted context omitted.

That's how the plumber works: http://doc.cat-v.org/plan_9/4th_edition/papers/plumb

I was thinking of something at the os level, like the namespaces for windows.

The plumber is effectively at the OS level. It's a userspace program, but it provides it services to the whole system at once. It's a global service that handles all plumbing between all programs. (Think "Android Intents". It's not too far off, conceptually.). Running, for example,

    plumb path/to/file.c:123
will send the file to whatever editor instance is set up to handle C files, and move the dot to line 123, from wherever it is invoked, be it the command line, the

    plumb bar.jpg
will open bar.jpg in whatever image viewer is appropriate. More or less, you can think of the plumber as a system level "take this text and do an appropriate action with it" service, where you can set up whatever rules you want to do the plumbing.

I don't think there's a good reason for this to live inside the OS, instead of simply running as a service. I don't think there's any extra functionality or elegance that would buy you.

Re: A Tour of the Acme Editor

#8
post #7

Earlier quoted context omitted.

I was thinking of something at the os level, like the namespaces for windows.

The plumber is effectively at the OS level. It's a userspace program, but it provides it services to the whole system at once. It's a global service that handles all plumbing between all programs. (Think "Android Intents". It's not too far off, conceptually.). Running, for example, plumb path/to/file.c:123 will send the file to whatever editor instance is set up to handle C files, and move the dot to line 123, from w…

Right, I just meant something as global as the windows namespaces (I don't know how it is designed, kernel module for vfs or userspace)

Re: A Tour of the Acme Editor

#9
Very neat. It seems to me the really interesting bit here is the ability to add execution meaning to arbitrary bits of text. Can anyone who uses Acme comment on whether or not that is primarily what gives Acme its power? Is there something else key to it that isn't shown cleanly in the video?

Interestingly, I also see Light Table as an "Integrating" Development Environment - something that utilizes all the amazing tools out there and strings them together into a very fluid workflow. I think we need to decouple the raw functionality of dev tools from the experience of their use, since it seems to me the latter is infinitely configurable and far too subjective to get "right" in all cases.

Re: A Tour of the Acme Editor

#10
post #9

Very neat. It seems to me the really interesting bit here is the ability to add execution meaning to arbitrary bits of text. Can anyone who uses Acme comment on whether or not that is primarily what gives Acme its power? Is there something else key to it that isn't shown cleanly in the video? Interestingly, I also see Light Table as an "Integrating" Development Environment - something that utilizes all the amazing to…

The window management is a huge win for me, if you'll pardon the unintentional pun. It's so much simpler and fluid than in Emacs or Vim, at least for me. I just kind of throw windows around and resize them with an ease and speed that I was never able to achieve on Emacs. For instance, when using Emacs I may have as many as 4 windows open at a time, frequently switching buffers around with the clumsy C-x b switching (I know there are better switchers). With Acme, I'll have 30 windows open, most of them stacked up with just the tag lines visible until I need them. When I need one, I just mid-click on the little box and it expands.

Execution of arbitrary text and loading/plumbing files/text with the mouse buttons is also really powerful for me, as you point out. I haven't finished watching the video yet (I'm at work), but in case he doesn't cover it, mouse chording is one of the most important capabilities in my mind. Makes copy-pasting significantly quicker.

Post reply on HN