Yep. I enjoy most of the benefits of the Oberon UI every day in OS X using Acme from plan9port.
Unfortunately making some text programs behave and not output escape sequences for colors is a constant battle, so from time to time I switch to using Terminal.app instead of Acme’s terminal, which somewhat limits the usefulness (I’m looking at you bundler, git and a bunch of node shit).
The feel (as in look-and-feel) of Acme is quite different from OS X’s, but since the look itself is so different as well I have a good sense of place and it doesn’t trip me up anymore.
It took me like a month before I was truly comfortable. Pressing up and down was particularly jarring as they do page-up and page-down, but now whenever I try to use something else I come running back to Acme in about a week.
Unfortunately making some text programs behave and not output escape sequences for colors is a constant battle, so from time to time I switch to using Terminal.app instead of Acme’s terminal, which somewhat limits the usefulness (I’m looking at you bundler, git and a bunch of node shit).
The default man-style output from manual page tools (like mandoc, or the more traditional roff-based stuff) is actually an oddball character stream aimed at an honest-to-goodness typewriter. The only control character that appears in the output is generally the ASCII BS (backspace) character:
Bold characters are rendered by the typewriter carriage being wound back by one cell and the same character typed again, increasing the amount of ink on the page for that character.
Underlined characters are emitted by the typewriter carriage being wound back by one cell and an underscore (_) character being typed “over” (or, as it were, under) the character to be underlined.
These encodings obviously don’t work in a video terminal, where overwriting a character simply removes all evidence of the previous cell contents, but by simulating a typewriter you can turn the stream of characters into a set of appropriate control sequences for, say, an xterm, or even into HTML. A simulation of this kind is also what tools like more and lessare doing to make manual pages render on a video terminal with bold and/or underlined output.
Short of editing the source (maybe here?), not really. Quoting Russ Cox from… elsewhere:
At Bell Labs, Rob switched acme and sam from black and white to color in the development version of Plan 9, called Brazil, in the late fall of 1997. I used Brazil on my laptop as my day-to-day work environment, but I was not a developer. I remember writing Rob an email saying how much I enjoyed having color but that it would be nice to have options to set the color scheme. He wrote a polite but firm response back explaining his position. He had worked with a graphic designer to choose a visually pleasing color palette. He said he believed strongly that it was important for the author of a system to get details like this right instead of defaulting on that responsibility by making every user make the choice instead. He said that if the users revolted he’d find a new set of colors, but that options wouldn’t happen.
It was really a marvelous email, polite yet firm and a crystal clear explanation of his philosophy. Over the years I have from time to time spent hours trying to find a copy of that email. It is lost.
But I can say definitively, both as a matter of philosophy and because I did the lion’s share of the open source release work for both systems since color went in, that there have never been color theme files in the Plan 9 distribution, nor in plan9port.
Not just any graphic designer, but artist and wife Renee French.
Here is a good explanation that was posted to 9fans:
the human system likes nature and nature is full of pale colors, so something you’re going to look at all day might best serve if it were also in relaxing shades.
renee french helped me with the specifics of the color scheme (she’s a professional illustrator and my collar vision is suspect), once i’d figured out how i wanted it to look. there are still some features of the color system that i put in that i think no one has ever noticed. that’s a good thing, in my opinion; the colors should fade away, if you’ll pardon the expression.
There’s honestly a lot about Acme that rules it out for a lot of people :/
I’d say give it a shot and if the color is truly the only barrier, it’s probably one of the easiest things to change in the code. The behaviors or lack of features are a much higher barrier to entry.
Color-blindness is not the only visual problem and not all are always in the same mode. I do, for example, suffer from bright colors (white!) quite often.
Still, the solution for me isn’t theming (because my favourite websites don’t have it and have a white background), but shell-wide color inversion.
He said he believed strongly that it was important for the author of a system to get details like this right instead of defaulting on that responsibility by making every user make the choice instead.
In a world of knobs and buttons, I find this to be an incredibly refreshing stance.
When creating software I’ve always found one of the hardest decisions was around what control I retain. But I never seem to go wrong when I decide to remove a feature.
It is possible to modify the source code and change the color of text, backgrounds, scrollbars, and tabbars, however syntax highlighting is not a thing in acme.
I love acme, but the assumptions made by some cli tools about terminal capabilities really ruin the experience. It’s only half as bad when running a dumb shell inside emacs (M-x shell works roughly like win), since at least some control characters get interpreted correctly.
The node ecosystem seems to have settled on the design decision that the unix shell is not a textual interface between small programs, but a retro-style color display with animated emojis. A loss, really.
I wish there were a standard environment variable one could set to get rid of all of that, instead of having to use aliases for every separate command.
There’s a lot of discussion in this thread about Acme being Oberon-like. I think that’s true if you focus purely on some of the interactions shown in this article (specifically, the click-to-execute, everything’s-a-CLI bit), but I think that’s missing the point.
The reason you can click on random things to get commands is because the entire environment is one giant IDE. The entire system is transparent and navigable; you can trivially jump down into any layer of the system (even the kernel!), modify it live, and jump back out. That you can execute lines of Oberon in situ with a middle click is really more of a byproduct of that design than its focal point. The only environments I’ve ever seen that come close to this are Smalltalk environments and Symbolics machines.
Acme’s not really equivalent here. Yes, you can click on text to perform commands, but your commands are limited to things that Acme directly understands, or that can be executed by rc. You don’t get the pervasive code navigation, the hot editing, or even the same degree of manipulating the environment.
I’m not trying to diss Acme here, but saying that Acme is Oberon-like, to me, would be like saying that WindowBlinds makes Windows Mac-like.
A lot of the basic UI benefits are there though, even if the entire experience isn’t.
I particularly like that if (more like when, heh) I get too scatterbrained, everything starts to look really cramped and cluttered, giving me ambient awareness that I have to refocus.
I never saw that coming when I started playing with it, but I certainly have come to rely on that “feature”.
Looks a lot like Acme, which I could never force myself to use since I didn’t have Vim bindings and it required the use of a mouse. I like the idea of being able to run the command under the current line, then print the output below and have a binding in my vimrc to do that:
nnoremap <leader>r yyp!!sh<CR>
(I also pipe out a lot with Visual select, then filter with :'<,'>!some-command)
Yeah, I saw that at one point (which actually inspired me to check out plan9). I stole a lot of ideas from it that I thought were useful and threw them in my vim config, bu I still prefer the asthetic/ease of use of the command prompt (also, I rely heavily upon tmux - I can’t quite give it up).
If you want to try something Oberon-like, Acme from the various Plan 9 distros implement the same text-and-mouse UI. You can get it here.
Yep. I enjoy most of the benefits of the Oberon UI every day in OS X using Acme from plan9port.
Unfortunately making some text programs behave and not output escape sequences for colors is a constant battle, so from time to time I switch to using Terminal.app instead of Acme’s terminal, which somewhat limits the usefulness (I’m looking at you
bundler,gitand a bunch ofnodeshit).The feel (as in look-and-feel) of Acme is quite different from OS X’s, but since the look itself is so different as well I have a good sense of place and it doesn’t trip me up anymore.
It took me like a month before I was truly comfortable. Pressing up and down was particularly jarring as they do page-up and page-down, but now whenever I try to use something else I come running back to Acme in about a week.
Included in plan9port is a filter “nobs” which filters escape sequences from text output. Maybe that helps you :) https://swtch.com/plan9port/man/man1/cat.html
And, at least with git you can disable the color with
--no-color(I don’t know if that works with every subcommand).I thought
nobswas for backspace?gitis actually quite well behaved with color, but the progress info ongit-pullassumes your terminal can handle cursor control characters.It removes the bold, etc. stuff from manpages, which should also be escape sequences, if i remember correctly, but I may be wrong :)
The default
man-style output from manual page tools (likemandoc, or the more traditionalroff-based stuff) is actually an oddball character stream aimed at an honest-to-goodness typewriter. The only control character that appears in the output is generally the ASCIIBS(backspace) character:_) character being typed “over” (or, as it were, under) the character to be underlined.These encodings obviously don’t work in a video terminal, where overwriting a character simply removes all evidence of the previous cell contents, but by simulating a typewriter you can turn the stream of characters into a set of appropriate control sequences for, say, an
xterm, or even into HTML. A simulation of this kind is also what tools likemoreandlessare doing to make manual pages render on a video terminal with bold and/or underlined output.thanks for the explanation :)
nobs => No Bullshit.
I’ve been meaning to try using acme as my standard editor, but the color scheme always turns me away. Is there a way to change it?
Short of editing the source (maybe here?), not really. Quoting Russ Cox from… elsewhere:
Not just any graphic designer, but artist and wife Renee French.
Here is a good explanation that was posted to 9fans:
http://www.mail-archive.com/9fans@cse.psu.edu/msg13035.html
Wow, of course, Tufte!
Well, I guess that rules it out for me :(
There’s honestly a lot about Acme that rules it out for a lot of people :/
I’d say give it a shot and if the color is truly the only barrier, it’s probably one of the easiest things to change in the code. The behaviors or lack of features are a much higher barrier to entry.
Or the need for a three button mouse.
If the colors where chosen with color-blindness in mind I 100% support this.
Color-blindness is not the only visual problem and not all are always in the same mode. I do, for example, suffer from bright colors (white!) quite often.
Still, the solution for me isn’t theming (because my favourite websites don’t have it and have a white background), but shell-wide color inversion.
Yeah I don’t agree with Mr. Pike’s reasoning either, I’m just lucky I’m cool with the default scheme.
In a world of knobs and buttons, I find this to be an incredibly refreshing stance.
When creating software I’ve always found one of the hardest decisions was around what control I retain. But I never seem to go wrong when I decide to remove a feature.
It is possible to modify the source code and change the color of text, backgrounds, scrollbars, and tabbars, however syntax highlighting is not a thing in acme.
The only way is to edit the source but doing so is actually pretty simple.
I love acme, but the assumptions made by some cli tools about terminal capabilities really ruin the experience. It’s only half as bad when running a dumb shell inside emacs (
M-x shellworks roughly likewin), since at least some control characters get interpreted correctly.The node ecosystem seems to have settled on the design decision that the unix shell is not a textual interface between small programs, but a retro-style color display with animated emojis. A loss, really.
I hear ya: https://lobste.rs/c/zman75
Reinvigorated by this thread I added a shell alias to de-colorize
bundler.gitis next.nodestuff is harder, but I thankfully do a lot less of that.I wish there were a standard environment variable one could set to get rid of all of that, instead of having to use aliases for every separate command.
https://twitter.com/jcs/status/524614835619635201
You know, that idea of command-line everywhere and clicking and things kinda reminds me of TempleOS.
There’s a lot of discussion in this thread about Acme being Oberon-like. I think that’s true if you focus purely on some of the interactions shown in this article (specifically, the click-to-execute, everything’s-a-CLI bit), but I think that’s missing the point.
The reason you can click on random things to get commands is because the entire environment is one giant IDE. The entire system is transparent and navigable; you can trivially jump down into any layer of the system (even the kernel!), modify it live, and jump back out. That you can execute lines of Oberon in situ with a middle click is really more of a byproduct of that design than its focal point. The only environments I’ve ever seen that come close to this are Smalltalk environments and Symbolics machines.
Acme’s not really equivalent here. Yes, you can click on text to perform commands, but your commands are limited to things that Acme directly understands, or that can be executed by
rc. You don’t get the pervasive code navigation, the hot editing, or even the same degree of manipulating the environment.I’m not trying to diss Acme here, but saying that Acme is Oberon-like, to me, would be like saying that WindowBlinds makes Windows Mac-like.
Yeah, Oberon-like is a bit of a stretch, agreed.
A lot of the basic UI benefits are there though, even if the entire experience isn’t.
I particularly like that if (more like when, heh) I get too scatterbrained, everything starts to look really cramped and cluttered, giving me ambient awareness that I have to refocus.
I never saw that coming when I started playing with it, but I certainly have come to rely on that “feature”.
Looks a lot like Acme, which I could never force myself to use since I didn’t have Vim bindings and it required the use of a mouse. I like the idea of being able to run the command under the current line, then print the output below and have a binding in my vimrc to do that:
(I also pipe out a lot with Visual select, then filter with
:'<,'>!some-command)I don’t know how far this went, but: http://c9x.me/edit/
Yeah, I saw that at one point (which actually inspired me to check out plan9). I stole a lot of ideas from it that I thought were useful and threw them in my vim config, bu I still prefer the asthetic/ease of use of the command prompt (also, I rely heavily upon tmux - I can’t quite give it up).