Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Tour of Acme (2012)

research.swtch.com

Post reply on HN
Print view View original

41–50 of 61 posts

Re: A Tour of Acme (2012)

#41

Post by coliveira »

zeveb wrote: post #37
coliveira wrote: post #35

Earlier quoted context omitted.

> 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 (serious…

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.

Re: A Tour of Acme (2012)

#43

Post by jordic »

coliveira wrote: post #26

Acme must be very useful in a Plan9 system. But on UNIX, I don't see any single thing it does that cannot be done by vim, with some configuration. And of course vim can do more.

Vim is keyboard centric, acme is mostly mouse centric (just taste) I prefer the mouse :)

Re: A Tour of Acme (2012)

#44

Post by jordic »

jeromenerf wrote: post #31
jrumbut wrote: 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 "integrat ing 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…

For example I have a plumber rule where I link issue/123 with GitHub. When right mouse clicking the text the browser opens the issue page.

Re: A Tour of Acme (2012)

#46

Post by abjKT26nO8 »

coliveira wrote: post #41
zeveb wrote: post #37

Earlier quoted context omitted.

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 (serious…

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

Re: A Tour of Acme (2012)

#48

Post by somezero »

floren wrote: post #21
haolez wrote: post #18

Earlier quoted context omitted.

I've been willing to try it for a while, now. Does the lack of "native" support for real-time linting, debuggers, formatters, etc get in your way? Did you manage to integrate such features in your workflow?

Go tooling actually works surprisingly well in Acme, because the tools tend to print out files with line numbers for errors, then when you click on that line number Acme will take you directly to the line in question. Here's a sample workflow: I'm hacking on some code in /home/john/foo. I have a directory window open in /home/john/foo, plus the files foo.go and foo_test.go open. I make some changes in foo.go, then in…

One of the main argument for Acme was that keyboard navigation is tends to be one dimensional, whereas navigating with mouse is two dimensional.

I find it curious that a higher-than-one dimensional representation of a program is not present: proper syntax highlighting makes debugging much faster.

Say, I want to see some expression with deeply nested parenthesis (lisp-style, or nested function calling in Python) is matching. I can do that with my eyes, checking the color of the beginning and the ending parenthesis. Same goes for, say, if I want to find a string in my program. I don't have to care about the quotation mark, I can just look at its color being different from the rest.

Executing commands with the mouse is heavily underrated and is a behavior I fail to faithfully replicate in i3 - or even Emacs, for that matter - but only if you guys had syntax highlighting...

Re: A Tour of Acme (2012)

#49

Post by floren »

somezero wrote: post #48
floren wrote: post #21

Earlier quoted context omitted.

Go tooling actually works surprisingly well in Acme, because the tools tend to print out files with line numbers for errors, then when you click on that line number Acme will take you directly to the line in question. Here's a sample workflow: I'm hacking on some code in /home/john/foo. I have a directory window open in /home/john/foo, plus the files foo.go and foo_test.go open. I make some changes in foo.go, then in…

One of the main argument for Acme was that keyboard navigation is tends to be one dimensional, whereas navigating with mouse is two dimensional. I find it curious that a higher-than-one dimensional representation of a program is not present: proper syntax highlighting makes debugging much faster. Say, I want to see some expression with deeply nested parenthesis (lisp-style, or nested function calling in Python) is ma…

I consider the lack of highlighting part of a "calm" interface: the only thing that changes as I type, are the characters that I type. But maybe that's just Stockholm Syndrome after 15 years of Acme! :)

When I need to check nesting levels, I use a little acme-trick: double-click on the closing mark (works for parentheses, curly brackets, quotes, probably more) and it'll highlight everything contained within that level. So if I type (some (big (lisp (expression)))) and want to make sure I got the right number of parentheses at the end, I just double-click on the last one and make sure the whole expression gets highlighted. Here's a screenshot: https://i.imgur.com/Qyvv2K9.png

I don't find I need to do it particularly often when writing Go, though, and if I do... well, I start to think about refactoring to make my function invocation less obtuse, or whatever.

Re: A Tour of Acme (2012)

#50

Post by somezero »

floren wrote: post #49
somezero wrote: post #48

Earlier quoted context omitted.

One of the main argument for Acme was that keyboard navigation is tends to be one dimensional, whereas navigating with mouse is two dimensional. I find it curious that a higher-than-one dimensional representation of a program is not present: proper syntax highlighting makes debugging much faster. Say, I want to see some expression with deeply nested parenthesis (lisp-style, or nested function calling in Python) is ma…

I consider the lack of highlighting part of a "calm" interface: the only thing that changes as I type, are the characters that I type. But maybe that's just Stockholm Syndrome after 15 years of Acme! :) When I need to check nesting levels, I use a little acme-trick: double-click on the closing mark (works for parentheses, curly brackets, quotes, probably more) and it'll highlight everything contained within that leve…

Interesting! But you see all of the benefits of syntax highlighting and real-time linting is about being steered towards a working code in a gradual and unmotivated way, prior to actually intending to check whether the code works... Although I'm not sure how critical this really is. My personal argument for them might really `only` be habit.
Post reply on HN