A Tour of the Acme Editor

On tmux, I use split panels more often than tabs. Usually, there will be from 2 to 8 panels of different sizes. This gives me spacial short term memory: I know what each shell is by the panel position. I can zoom on then to bring them full screen (ctrl+b z) if I'm going to do anything that requires more space, then zoom out to the panel arrangement when I'm done. Sometimes I'll name prompts (eg `PS1='stg$ '`), specially when working with ssh, but that's rare. What inspired me to work this way was this video on the acme editor: ▶ this video

Rob Pike's acme text editor for the Plan 9 operating system: link ▶ this video (excellent overview of the editor by Russ Cox) And acme's predecessor sam: link You'll need plan9port to run acme on Linux, though. But the core ideas are very simple and powerful (sam: everything is a huge string; acme: everything is a clickable file) and thus hopefully long-lasting. I would also mention edbrowse, a line-oriented web browser initially for blind people. Maybe this is too far on the fringe, though. It does have a lot of depth (excellent scripting capabilities); it's an amazing project actually: link

There is a plan9 and acme demo on YouTube which is eye opening. One idea that has captured me is the idea that end users ought to be able to create custom UIs. This appears to be a foundational principle of plan9, the way all text is able to be executed. Another avenue for this idea are ZUIs as originally envisioned. Individual clipboard state can be reified as buttons in the UI, any formatting or pens or fonts can also be manifested in the interface and selected with something along the lines of the "eyedropper" tool present in many applications. edit: video here ▶ this video "A Tour of the Acme Editor" by Russ Cox

Pretty close to what you describe is Acme [0] the text editor/shell from Plan 9. It is mouse oriented edit. You can right click on words to search them in file or open text files, directories or compiler errors. I recommend viewing this [1] introduction video. I miss few things in Acme. A bit more WIMP-y familiarity and a 3 button mouse. That's why I'm working on experimental text editor inspired by Acme [2]. [0] link) [1] ▶ this video [2] link

> Sorry, I don't mean autocomplete. I mean other editors that do not rely on a large number of keyboard shortcuts. I have never seen someone use vim quickly. I'm not sure I follow. Have you seen people use vim slowly? Or have you not seen anyone use vim at all? Vim (from v7?) has built-in "omnicompletion", by default bound to ctrl-n -- that you can use for everything (by default it "tab completes" against words in the buffer/file). There are various plugins for eg: writing html, and ways to set up full autocompletion. In general though, typing isn't what limits productivity -- and I've seen some studies that indicate that even though people think they're faster using just the keyboard, most people are actually faster at editing text with a mouse (Obviously, people type faster on a keyboard). Personally I prefer vim for two reasons: 1) I can't use a mouse day-to-day due to latent carpal tunnel syndrome, and 2) I feel it's easier to stay in the flow, and work efficiently with a modal editor. This has to do with vim's use of verbs, nouns (text objects) and modifiers/ranges (adjectives/adverbs)[1] - eg. 3dl (3x delete line) and 3dw (delete 3 words). The other has to do with easily moving around by regex, or go directly to line-number. For a look at what a "modern" graphical text editor could/can work like, have a look at Russ Cox demoing how he works with the ACME editor: ▶ this video If I could use the mouse for editing, I'd try to learn ACME. I still think it might be an interesting interface for hi-res laptops with proper pen input (like a Surface Pro 4 with a keyboard - using the pen for mark/editing, and the keyboard for input). But more than anything, both for a glimpse into vim, and also for getting more efficient with whatever editor you are using - I recommend Bram Moolenaar's (creator of vim) talk on "Seven habits of effective text editing 2.0": link [1] link

> indexes everything So should your text editor (and/or it's companion programs) > and provides superior auto-completion. See above. Superior is a bold claim, superior out of the box for "strongly" supported languages, perhaps? (Eg: one way of working with java in vim is to use eclipse for extracting some information about a project[1]) Personally I'm more familiar with vim, than with Emacs -- arguably the main difference is that Emacs has one standard and sane scripting language (lisp), while vim doesn't (I'm very happy a lot of masochists work tirelessly to provide vim plugins for everything I need (and a great deal I don't) -- but I think it's hard to argue that vimscript is a "good" language. And having other bindings (eg: ruby, python) is a bit of a mixed blessing)). But what they have in common, is a strong focus on making it easy to automate transformation of text. Any kind of text. With any kind of automation, via commands. As such they empower a continued process of improving the process of writing and editing. I like Moolenaar's (vim's creator) short text and expanded talk on 7 habits of effective text editing: "7 Habits For Effective Text Editing 2.0": link "Seven habits of effective text editing": link I often feel that modern IDEs with typical "modern" languages, tend to trap you in a certain way of working that is "with" the IDE, that tend to be counter-productive if that "one true (editing) process" doesn't fit. And they tend to provide only something like 70% of the benefit of a true IDE, like a Smalltalk System coupled with a Object Database, or something simpler like a complete Forth system. For better or worse, all current popular programming systems (that I'm aware of) has the hopeless abstraction of program text organized in file system files in folders (often coupled with half-integrated resource files, be they xml-layout, binary images, fonts or other stuff). So no IDE can be effective, because the central abstraction remains only half-structured text, and you can only get that far with strapping semantic analysis on top. So as long as you're (forced to) working with text, programs that enable text editing and transformation will have an edge. I don't think there's a wall between the two: you might want to use something like [1], or vim-mode in IDEA or something -- but if you want one effective tool to work with: Documentation, a handful of mark-up languages, a data language (like SQL), and a handful of programming languages (eg: assembler, C/C++, python), patch-files and perhaps writing email -- then I think text editors are going to be a good investment. I do think that text editors (for writing code) is a kind of local maxima - but if we want to stick with traditional files and file systems (probably a terrible idea), they do help facilitate tools that have somewhat loose coupling (between editing, debugging, high-lighting, re-factoring, formatting) and I think that helps keep systems portable (you can take a similar set of C++ files and preform a similar set of transformation (with completely different tools) on Linux and Windows and end up with (different) binaries that preform a similar function. Another great video that I think demonstrates text editing as different from "just" an IDE, is Russ Cox' short intro on ACME: "A Tour of the Acme Editor": ▶ this video In short, I suppose text editors are a superior user interface for interacting with text-like structures in general. The relative benefit for programmers depends a bit on what kind of system you work with: I'd prefer a simple, less verbose language, like Kotlin coupled with a plain editor, to an IDE coupled with more traditional Java (esp: Java 5) -- I firmly believe auto-generated code is a dark pattern: if it can be automated, it should be moved to a run-time or a library so that it can be maintained in one place, rather th

"Opinionated" yes, but entirely consistent with the UNIX mentality. One tool, to do one thing, done well, chained together. I love emacs so, so much (I'm the nerd who has foot pedals, and I've spent at least 1k hours perfecting my .emacs.d over the last 10 years). It's ability to meta-modify itself is incredible. Editor rant for nerds who have spent at least 100 hours on .vimrc or emacs.d: But ACME takes it to the next level. It feels like Smalltalk. It exposes all buffers via a FUSE block device you can mount, and all of a sudden you can feed buffers or sub-selections of buffers to standard UNIX utils. Literally everything that takes input from STDIN you can pipe to, and optionally return to the same buffer via STDOUT. You're no tied to languages. Hating Vimscript or Elisp becomes irrelevant because as long as you can run the binary and pipe to/from it, you can manipulate your data. It's fantastic for exploratory scripting, literate programming and my only qualm with it is I'm a home-rower. (That is, all of my interfacing revolves around keeping my wrists and about 1/4" of my lower palm. My wrists are planted in that specific position 98% of the time, with movement primarily centered around pivoting my wrists about those two radial points). My idea is to use Caps as a meta-key, then have s,d,f act as 1,2,3 on the mouse. Even with chording, it doesn't impose a stretch. If you are passionate about editors, watch Russ Cox's talk on ACME. ▶ this video

I've seen Acme before. There is this webcast by Russ Cox that shows of what is interesting about it: ▶ this video I think it could be an interesting editor. It is a Plan 9 in the sense that it's API is a filesystem that it exports. This means any language that can talk to the filesystem can automate Acme. IIRC, there is a standard app called plumber that can be used to trigger contextually aware actions. It sounds neat. It is missing something I consider a deal breaker: no syntax highlighting. I know some people vocally dislike it, but I can't live without it. I would also be able to make it a different color than snot yellow. If I'm going to be staring at something all day, I'd like it to look decent.

It's sad that Acme hasn't been mentioned at all. While its mouse-oriented nature is a little strange coming from Vim, there are some very awesome ideas in it. For one: It lets you write plugins in anything you like. This is because all aspects of the editor are exposed as a filesystem a la /proc. Need to create a new window with some custom contents? Create a new file. Other awesome ideas: The text in that custom window can be actions because any text can invoke commands by using another mouse button. Russ Cox has a great video tour of Acme's features here: ▶ this video

Acme [1] It steps back from the “customize everything” mantra, believing that approach leaves users with an underdeveloped essential system. But it still has two major APIs: one for window manipulation [2], the other for text-based integration with the surrounding system via plumber [3]. All textual CLI tools (that is, those without pseudographics) work by default and are the heart of its style. I use Acme for everything except web browsing (although most links are still managed by Acme). [1]: ▶ this video [2]: link [3]: link