HN Theater @HNTheaterMonth

A great way to get a feel for Plan9's concepts and their power is Russ Cox's (of now Go fame) Tour of the Acme Editor:

https://youtu.be/dP1xVpMPn8M

https://www.nbcnews.com/technolog/how-fast-fast-some-pro-gam... claims that effective APM can hit 600, that sounds high to me but not by a lot. 10hz on the keyboard is probably not a realistic sustained rate for a hardcore vi/emacs user.

I easily hit 4hz at the end of a 20 hour coding bender, and I’m old: the hot shit kids on modafinil must be doing 1.5x my decrepit ass.

If you can really move on the keyboard? Touch the mouse? I’ll grab a coffee while I’m at it.

Edit: It turns out that “fast emacs” doesn’t turn up a video of a real pro easily on Google. You can see a code God like Russ Cox being slow and clumsy as fuck if you want: https://youtu.be/dP1xVpMPn8M.

It’s a good thing thing he gets everything right on the first try (not sarcasm, Cox is an alien life form optimized for doing the impossible) because if he didn’t he’d finish pound-defining everything by about next March.

Rob Pike's acme text editor for the Plan 9 operating system: http://acme.cat-v.org/

https://www.youtube.com/watch?v=dP1xVpMPn8M (excellent overview of the editor by Russ Cox)

And acme's predecessor sam: http://sam.cat-v.org

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: http://edbrowse.org/

It may be useful to see Russ Cox's "Tour of ACME" video [1]. ACME is a Plan-9 text editor, which applies the "everything is a file" philosophy pretty deeply. It doesn't answer your ioctl question (that I remember), but maybe it'll give you a better example of how other things can be accessed as files.

[1] https://www.youtube.com/watch?v=dP1xVpMPn8M

Twitter announcement: https://twitter.com/plan9foundation/status/13743504723168174...

Plan 9 Foundation: https://p9f.org/

Wikipedia: https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

There's still a pretty active community around Plan 9, too.

9Front, a popular fork of Plan 9: http://9front.org/

Interviews with some Plan 9 community members: https://0intro.dev/

Some videos: [A Tour of Acme](https://www.youtube.com/watch?v=dP1xVpMPn8M), [Peertube channel of sigrid's](https://diode.zone/video-channels/necrocheesecake/videos)

⬐ _joel

https link timing out for me http://p9f.org/

⬐ ori_b

Plan 9 is also participating in GSOC this year. http://p9f.org/wiki/gsoc-2021-ideas/index.html

⬐ JAlexoid

I've seen Plan 9 in GSoC multiple times, now.

I personally learned about it from GSoC many years ago.

⬐ choppaface

Rob Pike filled all the application spots himself.

⬐ AceJohnny2

with assistance from Russ Cox

The author is definitely right in saying that Emacs is an OS, because it runs "programs" that interact with a common datasource. The issue is that those "programs" are not the ones of your baremetal host.

The sequel that makes sense would be a text editor that allows host programs to be run seamlessly on the text. Once again the geniuses behind Plan 9 have shown how novel their system was by creating acme (https://www.youtube.com/watch?v=dP1xVpMPn8M). It allows any program to interact with whatever is in the text, so it clearly is the 2D cli the author is looking for

⬐ pjmlp

There is nothing genius about ACME.

Just like Emacs is a poor imitation of the developer experience on Lisp Machines, ACME is a poor imitation of developer experience on Oberon and Mesa/Cedar.

⬐ rakoo

How is it a poor imitation ? What is lacking ? (I've never used any of those predecessors)

⬐ pjmlp

On Oberon, Mesa/Cedar and Lisp Machines, the experience extends to the whole OS and any application, or REPL, not just a plain text editor.

Althought I haven't mentioned, Smalltalk also provides a similar experience.

Here are some videos that try to convey it, from my playlists,

"Eric Bier Demonstrates Cedar"

https://www.youtube.com/watch?v=z_dt7NG38V4

"Emulating a Xerox Star (8010) Information System Running the Xerox Development Environment (XDE) 5.0"

https://www.youtube.com/watch?v=HP4hRUEIuxo

"SymbolicsTalk28June2012"

"SYMBOLICS S-PACKAGES 3D GRAPHICS AND ANIMATION DEMO"

https://www.youtube.com/watch?v=gV5obrYaogU

"Symbolics Lisp Machine demo Jan 2013"

https://www.youtube.com/watch?v=o4-YnLpLgtk

The Native Oberon demos available at

https://www.youtube.com/channel/UCw6NbzmjW-wLvqVbxOXj7Ug/vid...

⬐ michael-ax

Its also a daemon that does a lot of work for me from the shell!

I meta-click to capture xterm output, call dired, make it give me popup-windows to edit short scripts and long command lines, i query the feed-reader, get my backup-schedule, have it popup for debrief when new voice notes are downloaded, serve as an emergency window manager, capture into multiple bins while browsing, turn into a presentation tool, create pdf reports and write-ups, prompt me to check-in any leftovers at the end of the day, work seamlessly across my machines, provide menus to give access to files, clickable functions, org-summaries, fantastic spreadsheets .. oh wait, that's going beyond shell.

so yes, it made my beard grey. big deal, i can shave. sure it not perfect, sure its infuriating, surely i'm insane for continually investing into my future while tweaking something to compound its benefits.

but none of this makes emacs anything but a lisp machine -- so well loved and so close to the metal that it will be here after you and me. Call it a general purpose computing shell, not an OS, and please compare it to the living, not the dead!

⬐ rakoo

Can you do all of those without emacs ? My point is that yes Emacs can do so many things, but 1) it's all accessible from Emacs only and 2) it uses Emacs-only components. This is fine if you live inside Emacs, but it doesn't really integrate with the rest of your system

⬐ BeetleB

That's kind of like asking "Can you do all the cool things Linux provides without installing UNIX?"

⬐ TeMPOraL

Emacs is your system. You can't integrate all that well in the other direction, because host OS platforms don't let software interop as well. Even the Unix family.

The deep interop of course comes at the expense of security. There's no sandboxing or restrictions in Emacs world. One day somebody will release a piece of elisp malware, and a lot of people - myself included - will lose their crown jewels. But until then, we get to enjoy the only remaining relatively mainstream OS with deep interoperability.

⬐ rakoo

Actually you can interop in the Unix family, that's what ACME is doing: write specific text to specific files and the content of your editor windows change. That allows the editor to implement any command you could find elsewhere, such as indent, put the contents of a directory, display compile errors...

⬐ TeMPOraL

I didn't realize that. I'll need to dig into ACME (and the history behind its ideas - I suspect there are many gems lost to time, like it is the case with Lisp machines).

> write specific text to specific files

Is that all plaintext, UNIX-style? Part of me wishes we could leave the era of unstructured text, and every tool carrying its own ad-hoc, bug-ridden, poorly specified parser and serialization logic - and send richly typed data structures (or objects) instead.

For a more accurate screenshot than a scan of a picture on a paper that had a screenshot in black-and-white on it:

http://acme.cat-v.org/_imgs/obsd_acme.png

Though a screen shot really can't sum up what makes acme so wonderful. Try Russ Cox's A Tour of the Acme Editor:

https://www.youtube.com/watch?v=dP1xVpMPn8M

https://www.youtube.com/watch?v=dP1xVpMPn8M

Is Plan9's ACME similar? https://www.youtube.com/watch?v=dP1xVpMPn8M

If yes, does it reinvent or borrow the concepts?

(I saw ACME in the yesterdays post: https://news.ycombinator.com/item?id=25777580)

⬐ pmarin

Acme User interface is inspired by Oberon and Oberon UI is inspired by the "Views" windows system used in the Xerox PARC Cedar integrated environment.

⬐ Grumbledour

It is inspired by it as the wikipedia[0] article notes. Both are inspired by Cedar/Mesa[1] from PARC. There is a great video of Eric Bier showing some of cedars capabilities on youtube[2].

[0] https://en.wikipedia.org/wiki/Acme_(text_editor) [1] https://en.wikipedia.org/wiki/Mesa_(programming_language) [2] https://www.youtube.com/watch?v=z_dt7NG38V4

It still strikes me that after all this time, the next step in the direction of the author is to use an editor like ACME (https://en.wikipedia.org/wiki/Acme_(text_editor)): use the shell to its maximum power, where the output of a command can be edited and used to control the existing interface.

Take for instance this video: https://www.youtube.com/watch?v=4djoOiLste0 The author shows how the output of "git status" is just a text, you can modify the text and add "git add" just in front of the files you care about and add the file to the index. There is no linear loop of command input that becomes command output, it's all one big buffer that can feed itself. Consider how there could be another window that perpetually shows the status thanks to a combination of inotify and git status, and you have a git view. Fiddle with the command line argument and you can choose wether to show whitespaces or not, whether to show a summary view or the full diff, or restrict the list to some files. Have another window where you can write some message, and a GitCommit command in the "Tag" of the window will use the whole buffer as a git commit message; boom, you have 60% of what I use git-cola for.

A bit more information can be seen by one of its creator here: https://www.youtube.com/watch?v=dP1xVpMPn8M. The possibilities are truly endless, and I haven't seen anything that resembles it. There is just no editor that embraces your platform the way Acme does.

No, Emacs is not the same, because Emacs doesn't integrate with your OS; Emacs is an OS unto itself. You can't really say it's integrated to the OS when everything is implemented in the language that only Emacs uses.

⬐ sime2009

Your git example is very similar to what can be done in my terminal, [Extraterm](https://extraterm.org/). See demo here: https://extraterm.org/features.html#reusing-command-output

Thanks for the tip about Acme. I'm always looking for ideas about how to improve integration between the terminal based work flows and other applications, command line, GUI, or others.

⬐ rakoo

Wow, I've been looking for a terminal that does this sort of thing for a while, nice job! And it's beautiful !

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 https://www.youtube.com/watch?v=dP1xVpMPn8M "A Tour of the Acme Editor" by Russ Cox

⬐ taeric

Sounds a lot like some of the macro tools in Emacs, all told. https://www.gnu.org/software/emacs/manual/html_node/emacs/Ed... has the general vision of showing so keyboard interactions. I don't know why this couldn't include mouse events.

⬐ angleofrepose

I agree, thanks for pointing me to that info page. I would bet that keys representing functions probably evolved simultaneously with the first computer typewriters, they've been around forever and are "obvious" to some degree. Making functions apparent in menus is also probably synonymous with the first non text-based GUIs. I don't know enough about the history of toolkits, but as far as I can tell that area of development is nowhere near mainstream today.

I have been reading Sutherland's Sketchpad thesis, and it struck me that no aspect of the system was unavailable to the user. By itself, this isn't entirely unusual, I think the same could be argued for emacs or linux in various ways or even of software when code is available etc. The unique aspect of this universal control with regard to sketchpad is that it was a graphical system. Controls for the graphics and viewport were essential, and reflected by the development of the first oop principles of master/instance and recursive expansion of arbitrary material in the workspace. Of multiple viewport movement controls (physical dials too!) and focus-selection zooming.

It is easy to imagine extensions of sketchpad with graphical macros. Of savable viewport state, of non-euclidean jumps between locations on the digital "paper".

It's funny to me that most clever things I enjoy about vim seem like they could fit right into a graphical system like sketchpad. `mkview`, marks, folds, repeat operations, contextual movement or selection like accessed via combinations of `[{(`.

Infinite canvas artboards are fantastic workspaces, but lack even the basic "focus shifting ability" of a few stacks of paper on a desk, taped on a wall, or strewn across the floor.

⬐ taeric

The thing I like about the best parts of vim and emacs is how much it feels like a conversation with the computer. Such that it natural lends itself to interacting with completed things. Indeed, "ciw" only works if you have a completed "word" to change.

Notebooks are usually tons and tons of fragments. Such that a precise dialog with them feels very difficult. I agree it would be awesome, but I have yet to see something that doesn't just harken to the ultimate failures of graphical programming languages. Neat for performance style programming. But needing a ton of rehearsal to get a performance.

If well configured, mouse support can be handful when navigating code. There is a niche editor called Acme[1] that is almost "mouse-only", where even Return won't put you in the next line :)

When using Emacs, my workflow was very keyboard-centric, but sometimes navigation was a pain (even with tags and whatnot).

[1]https://www.youtube.com/watch?v=dP1xVpMPn8M

⬐ wtetzner

Oh sure, I'm not saying it's not a useful feature. Just an observation of how different usage patterns can lead to blindspots.

Just a note, that for a person used to working in say, vim - having to take a hand off the keyboard in order to use the mouse (or touch the screen) essentially feels like changing to selection mode. Putting hand back on keyboard is like going back to insert mode.

The key difference is of course that "learning" to use the mouse, or the touch screen - feels much more natural than some arcane key combination.

So, if you already know the combinations for switching modes (both the arcane key combo, and the "process" of moving one hand from the keyboard to the mouse, and back again) - you are comparing different things - typically "efficiency".

While I'm a vim user, and unlikely to ever go back to using a mouse, due to RSS injuries - I still thing something like ACME[1] is likely more efficient than vim. On the other hand, the act of editing is plenty efficient in vim for me.

[1] Russ Cox "An introduction to the ACME editor": https://youtu.be/dP1xVpMPn8M

http://acme.cat-v.org/

This series is also discussed in the wiki for Plan9, the perhaps infamously mouse-centric OS:

https://9p.io/wiki/plan9/Mouse_vs._keyboard/index.html

A take-home message from there: "In the experience of many Plan 9 users, using the mouse in Plan 9 for an extended period of time and then going back to using vi in Unix highlights the amount of time you spend watching the screen as you cursor around with hjkl. Having broken out of the hypnosis that Tog describes, I just get frustrated beyond belief. Yes, I am watching the cursor move so I should be occupied, but all I can think is ``damnit, if I could just click where I want to go I'd be there by now.'' "

See also high-brow three button mousing in Acme, Plan9's text editor:

https://youtu.be/dP1xVpMPn8M

I'm a long time Plan9 fanboy, but I find myself more leaning towards line editors (Pla9's sam in terminal mode), partly to avoid watching the cursor all the time. In a line editor, you have to carry the structure in your head, and it is liberating and calming in a strange way.

Ken Thompson, prominent sam user, has been attributed saying "I don't want to see the state of the file when I'm editing." I really like this; then again, I am not a real coder, just a hobbyist and writer of words. So I have no idea how realistic it would be to use console sam or ed for daily professional coding. The way line editors resemble a typewriter can be an excellent cure to the so-called writer's blocks, though.

(See the interview containing Ken Thompson's quote: http://web.archive.org/web/20080103071208/http://www.dcs.qmu...)

⬐ laughinghan

> vi in Unix highlights the amount of time you spend watching the screen as you cursor around with hjkl

vi is four decades old. It's not the pinnacle of keyboard-driven interface design, vast improvements have been made since then.

For example, I use vim-sneak, which lets you jump to anywhere on your screen in 3 keystrokes flat 99% of the time (and the 1% of the time where you miss, well, 99% of those times, just one more keystroke is all it takes to get to the right spot): https://github.com/justinmk/vim-sneak

I also use relative line numbers, so I can select or delete most blocks of text in 3 or 4 keystrokes, for example d4j deletes the current line and the next 4 lines (5 lines total), or d23k deletes the current line and the previous 23 lines (24 lines total): https://jeffkreeftmeijer.com/vim-number/

Obviously number of keystrokes isn't the only factor that determines operation speed. This is actually exemplified by my second example, commands like "d23k" actually work out-of-the-box even in original vi, the problem is that counting 23 lines by eye is way slower than selecting 24 lines with a mouse by eye, which is solved by relative line numbers.

Plan 9 as a whole is a pretty good IDE for general development - excels at C, shell scripts, Go, and similar. Having been created explicitly to OS differs from older (POSIX/VMS era) OSes by making GUI, architecture portability, namespaces, user-level filesystems, software services, network transparency and distributed computing first-order concerns.

For those unable to switch outright, I wholeheartedly recommend plan9port[0] - an almost complete set of utilities and protocols from Plan 9, ported to run in Linux, MacOS X, and OpenBSD userspace. It's being actively developed[1] by the 9fans community.

plan9port comes with both sam and acme[2] programmers' text editors.

--

[0] https://9fans.github.io/plan9port/

[1] https://github.com/9fans/plan9port

[2] https://youtu.be/dP1xVpMPn8M

⬐ dandelo1953

I know I can google this, but I am really looking for a more personal answer that others might also gleam insight from.

What are the efforts like for non x86 architectures, if any exist?

Are there working kernels for arm as there is for *nix with things like Raspberry Pi?

I haven't started my IoT journey yet. I am wondering if plan9 would be stable enough to tinker with in that space and in order to capture two birds with one trap.

[edits made to cleaned up the original mess]

⬐ Seirdy

9front runs wonderfully well on the Pi and other SBCs.

#cat-v on OFTC is very helpful if you want to try it out.

⬐ dexen

Certainly runs on Raspberry Pi - there are several mentions to that effect.

Sadly I can't help you more - best ask on mailing lists[0] or on IRC[1].

Historically Plan 9 was developed from grounds up to support several architectures, so in this case you're really asking about drivers for specific peripherals.

--

[0] http://mail.9fans.net/listinfo/9fans and http://lists.9front.org/

[1] #plan9 and #9front and #cat-v on irc.freenode.org

So does Go.

And in Plan 9 all compilers did. I bet this is the first exmaple of a humorous Hello world in C with Unicode smileys in identifiers: https://youtu.be/dP1xVpMPn8M?t=695, by Dennis Richie I think.

⬐ 16

this is the video that convinced me to give acme a shot. 6 months later and I can't imagine going back to anything else. this coming from a heavy vim user of 10+ years.

⬐ hollerith

what OS do you run Acme on?

what browser do you usually use when you're using the OS you run Acme on?

(I ask because the text in Acme (under plan9port) looks so different than the other text on my OS (Macos) particular the text in my browser (Chrome) as to constitute a dealbreaker for me.)

⬐ bigato

You can change the font in plan9port, you know? The default font looks terrible indeed.

⬐ hollerith

you can change the font, but when I tried that, the text still looked very different from the same font at the same text size in, e.g., Terminal.app.

rsc is one of the most brilliant minds of 21st century software engineering. A very lucid thinker and speaker, too. While not everyone likes stuff he works on (ex: Golang), his insight and brain power are unmistakable.

One such example to me is his overview of Acme: https://www.youtube.com/watch?v=dP1xVpMPn8M

Russ's demo is one of the clearest technical demos I've seen.

⬐ kmicklas

If only he implemented his thesis into Go. Then maybe we could add generics.

⬐ sitkack

> rsc is one of the most brilliant minds of 21st century software engineering

Are you trying to make pull quotes for the jerk? Because seriously kids. This is how its done!

How do you feel about Plan 9's acme editor (https://www.youtube.com/watch?v=dP1xVpMPn8M)? It's a "GUI", but from a very different branch of thinking than the ones we have right now.

As a contrast, I use sublime. It has (almost) everything I desire. And it saves everything i write, even in the case of a power outage.

Another example would be Acme[0].

>The point is that user preferences are more fragmented and expectations are higher for features, and willingness to learn details and gotchas of a program are lower, which has created the bloated program for the simple things like text editors.

I agree. People are people and people will always be subjective. But there should be a distinction between feature bloat and node.js bloat. Still, ofc, to each his own. (I measure how good it is for me by how much hair i pull out by using it, be it by lack of features, bugs, performance, or anything)

[0]https://www.youtube.com/watch?v=dP1xVpMPn8M and https://www.usenix.org/legacy/publications/library/proceedin...

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] https://en.m.wikipedia.org/wiki/Acme_(text_editor)

[1] https://youtu.be/dP1xVpMPn8M

[2] https://github.com/hadrianw/werf

⬐ kps

I really like Rob Pike's minimalist principles but somehow dislike most of his implementation choices. I can't be productive in acme due to missing my #3 arm, but I'd kill for structured regular expressions in vim.

Acme, the text editor from Plan 9 has this. Piping, inputing and outputing from commands are some of the most basic operations there.

Check out:

- http://acme.cat-v.org/

- Russ Cox' tour: https://www.youtube.com/watch?v=dP1xVpMPn8M

⬐ gravypod

Is there an updated version with less complicated mouse interfaces?

I have to say that I had no use for YouTube until I realized that these kind of talks were on there. In addition to what you mentioned, some I like:

The Gruqg on OpSec: https://youtu.be/9XaYdCdwiWU

Russ Cox's ACME tutorial: https://youtu.be/dP1xVpMPn8M

Jessie Frazelle on running containers on the desktop: https://youtu.be/1qlLUf7KtAw

> There's a reason people tend to disable computer touchscreens.

They do? I've disabled the touchpad on my surface pro 4 (and have been known to toggle it and the nub on my thinkpad) - but the touchscreen actually works great, I think. So much so, that I'm now touching all screens everywhere, like a three year old that's been given a tablet as her first computer.

I've actually thought that a good touch screen and perhaps stylus, would be the perfect environment for something like the ACME editor: https://www.youtube.com/watch?v=dP1xVpMPn8M as a new power-user editor.

> 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: https://www.youtube.com/watch?v=dP1xVpMPn8M

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": https://www.youtube.com/watch?v=p6K4iIMlouI

[1] http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...

> 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": https://www.youtube.com/watch?v=p6K4iIMlouI

"Seven habits of effective text editing": http://www.moolenaar.net/habits.html

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": https://www.youtube.com/watch?v=dP1xVpMPn8M

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 than leaving dead and possible buggy code in dark corners of a large code-base.

[1] http://eclim.org/

I recall seeing a study that concluded with mouse/gui-based editing being more efficient, even if users felt more efficient using vim. You might want to look at ACME[1].

For me personally, I can't use the mouse much, or my carpal tunnel comes back quickly. So I need a keyboard-only workflow. And I'm happy with vim.

"A Tour of the Acme Editor" by Russ Cox https://www.youtube.com/watch?v=dP1xVpMPn8M

Personally, I find vim's modal editing to be very efficient. When starting from a clean slate, it doesn't really matter much -- but when changing/editing existing text/code, I find it feels much more natural. It also works well without using the mouse, which is important to me because of carpal tunnel syndrome (and also helps when working without a proper mouse, such as on laptops).

I've only toyed with emacs, but based on that, I don't think emacs' idea of keyboard "chords" is as good a fit as vi(m). With standard keybindings, it also puts a strain on my wrists.

Modal editing and the "edit language"[1] (verbs, nouns, modifiers (and motions), like dw=delete word, dd/dl=delete line, d$=delete from cursor to end-of-line, dG (delete to endo-of-file, where gg/G is motion for moving to top/bottom of file respectively), ciw()<ESC>P=change inner word (cut word under cursor to buffer), add "()", escape out of insert mode, paste word between "()"). These look cryptic, but quickly starts to feel quite natural and intuitive.

My impression is that Emacs' Evil-mode has evolved quite a lot lately, and allows one to combine the best of both: a much better programming language (scheme dialect) for customization, with modal editing and vi(m) key bindings. But I've yet to play with it.

If you don't mind using the mouse, you might also want to look at ACME[2] - it's a bit more exotic, and unfortunately hasn't gotten as much support as VIM/Emacs.

The creator of Vim, Mjolnar, has a great video on "7 Habits For Effective Text Editing 2.0":

https://www.youtube.com/watch?v=p6K4iIMlouI

I think the idea is very powerful: aim for incremental improvement in your workflow. You don't have to use vim to do that, but you certainly can use vim for that. Another editor that might be worth a look if you're not already familiar with vim, is: https://github.com/mawww/kakoune

The main argument for Neovim/vim/Emacs over other "smaller" editors would be the plugin eco-system. I have a theory though, that beginners tend to start out with a lot of plugins, and then gradually trim down, as they realize the power that lies within the editor itself.

Still, for vim, you will probably want a plugin manager (well, maybe not now with vim 8 supporting that out of the box :-), and depending on what you're writing, some integration with a tag tools, like cscope, perhaps a search-tool like Ag/The silver searcher: https://github.com/rking/ag.vim#readme

As for plugin manager, I'm personally in the process of moving - I'd suggest looking at Vundle and/or vim-plug.

Finally, you can generally count on any unix-like system to have some form of vi(m) installed -- I'm not sure I really see that as such an important point, but does make it easier to edit stuff on a server with only ssh open to the world. But that stuff you're editing should probably be in a VCS, and use some kind of automated push to land on the server anyway! :-)

[1] http://yanpritzker.com/2011/12/16/learn-to-speak-vim-verbs-n...

"A Tour of the Acme Editor", by Russ Cox [2] https://www.youtube.com/watch?v=dP1xVpMPn8M

I found http://vim-adventures.com/ (no affiliation) to be the best way to finally learn vim in the sense of actually developing automatic muscle memory. It teaches you how to use vim using a 2d game. It's worlds better than the built in vim tutorial, to say the least. :)

For a really different take on editors+shells, check out acme: https://www.youtube.com/watch?v=dP1xVpMPn8M

The most important role of UNIX is to provide a file system. From the point of view of the user, there are three kinds of files: ordinary disk files, directories, and special files. [DRAFT: The UNIX Time-Sharing System]

> "In the spirit of UNIX, every thing is a file." "Everything is a file" is a Plan 9, not UNIX, adage. `Block devices aren't a file (though they are represented by files). Network devices are not files (again, they have representational forms, but you can't pipe to them, a la Plan 9). > "Though unlike it, a file can contain other files. " By definition, a directory is a file. It's the second item in that tuple of 3 outlined by Ritchie.

You essentially have re-invented Plan 9 and to some extent ACME[1]. Sadly, Plan 9 faded into obscurity due to licensing, but it was poised to fill the position Linux has now. Watch that video [the whole thing) and borrow the good ideas. LISPs are homoiconic in that whole text-is-data sense. ACME takes it a further, in that your terminal is a shell, which can invoke programs to manipulate data. The only other environment I've ever worked where everything was as unified consistently was Smalltalk.

Emacs is a close 3rd and that's hard for me to admit, as an emacs fanatic. Though I can (and have been) doing exactly what you're trying to solve for ages within emacs, but that leaves all the vimmers in the dark ;) Ledger for accounting, org-mode for generic notes, a highly customized e-mail client which I integrated to a calendar/contacts/todo, all of which have tags. I can fuzzy-match my notes to the point where if I'm trying to remember a resource (say, a library for redistribution of data amongst a network on soft-failures), I can search by tag, by time (i.e., I remember it was sometime this week; filter; I remember it was a link on medium.com; filter), and various other components.

I see what target demographic you're going for and it's a pretty good idea. Most people need 'information stores'. Evernote was the Web 1.5/2.0 solution, inevitably there'll be a Web 3.0 version, you might be it.

Side bit of trivia: Cox loved ACME so much he ported all of the essentials when he moved over to Google, from the Plan9 FS (FUSE'd, not native, obviously) to ACME itself.

[0] http://www.tuhs.org/Archive/PDP-11/Distributions/research/Mc... [1] https://www.youtube.com/watch?v=dP1xVpMPn8M

⬐ saola-app

Thanks for bring up Acme and Plan9. Having used Acme as a primary editor for a while I definitely plan to bring some of its features along. I have ported part of plumbing to elisp though very rudimentary. Though I wonder how plumbing could be implemented in the web. It is an interesting thought.

"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. https://www.youtube.com/watch?v=dP1xVpMPn8M.

I agree. One place I had seen this approach before was Russ Cox's "A Tour of the Acme Editor" video[1]. He fixes an issue in a go library towards the end of the video as a workflow demonstration.

[1] https://www.youtube.com/watch?v=dP1xVpMPn8M

Personally, I can't find a text editor I like. The closest I came was acme from plan9, shown here https://www.youtube.com/watch?v=dP1xVpMPn8M.

I would love to see an editor which clones acme, but follows a few of the modern ui conventions.

I've seen Acme before. There is this webcast by Russ Cox that shows of what is interesting about it: https://www.youtube.com/watch?v=dP1xVpMPn8M

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.

⬐ digi_owl

Basically a tiling WM running as a program.

The ability to edit the CLI history reminds me of Archy, of Jef Raskin fame (and as i dive back into it, so does some of the button chords).

And the whole thing really takes composability to its extreme. As should be expected from something that came to be on Plan9.

You might get a better idea by watching a bit of Russ Cox's tour of the Acme editor, in particular the couple of minutes starting around 12:40 [1]. In there he shows how the contents of the various editor windows in the editor are available as files in the filesystem, which means that editor macros can be written in any language that can access the filesystem, without any special bindings.

[1] https://www.youtube.com/watch?v=dP1xVpMPn8M#t=12m42s

I love (don't use, but love) editors like this -- that push at some boundaries and rather than having that push be some "side feature" or "addon" -- is the core part of the editor.

An older editor that I thought was amazing was Acme (http://en.wikipedia.org/wiki/Acme_%28text_editor%29) -- the famous plan 9 editor. http://youtu.be/dP1xVpMPn8M is a Tour of Acme, some really cool features are built into it. Any text is a command.

⬐ klibertp

> editors like this -- that push at some boundaries and rather than having that push be some "side feature" or "addon"

The problem with this is that it's really, really hard to build a good editor, and when you concentrate on some novel idea the "basic" functionality suffers.

For example, both Vim and Emacs have easily accessed commands for moving cursor by words, sentences, paragraphs and moving to the nearest given character (on top of traditional beginning and end of line, of course). Also for selecting them, copying and pasting, indenting, surrounding and so on, all in 2 to 3 keystrokes. Another example is the multilevel, tree-like, infinite undo of both editors. And many more: mark ring, multilevel "clipboard", registers, very easy to access macros, narrow to region (this one could be Emacs specific, but I doubt there's no Vim plugin for this), search (both literal and regex) and replace (both literal and with expression, incredibly powerful) and so on and on, and that's just built-in purely editing features, not going into integration with other tools or plugins.

I would have migrated to LightTable long ago if it provided at least some of a more advanced, but purely editing oriented features. It doesn't yet, and it will take it long years to get there because of sheer size of a required featureset. And that's still not counting my 3k lines of personal Elisp and some 20k lines of Elisp in installed plugins.

I'm going to give Leo a try, but even if it really is as good as it's web page says I can't see myself migrating to it in the near future. I may use it from time to time for specific tasks, but my daily editing will be done in Emacs; in the worst case I will have to copy&paste bits of text between Emacs and Leo windows if Leo's editing model/core editing functionality sucks enough (I did this with some other editors and I despite copy&paste overhead I was still faster than I'd be staying in the single editor).

⬐ vertex-four

The problem is, there's still not a really good composable text editing system. I can drop any number of HTML WYSIWYG editors into a web page in five lines of code, but it's really hard to do that with anything but SciTE for code editors, and SciTE is pretty dreadful.

If this existed, we could start building on that widget and have a decent, extensible text editor from the outset, then build on that.

⬐ jacquesm

We grow attached to our tools. I built a full screen editor somewhere in the 80's, used it until 2005 or so, when I really could no longer justify (to myself) the effort required of keeping it going. I still type 'e filename' or will use its weird set of control keys when I'm not paying attention. And it's almost 9 years now since I stopped using it. So I suspect you'll be back with emacs before the first day is out. But please do look at leo, it has some interesting ideas embedded in it and there may be ways to get emacs to adopt some of those.

Leo is the best implementation of the literate programming method that I've come across to date, and the first time when it all clicked for me.

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: http://www.youtube.com/watch?v=dP1xVpMPn8M

⬐ weslly

The concept of Acme remembers me of Xiki[1]. It would be perfect with better fonts and/or code highlighting.

[1]: https://www.youtube.com/watch?v=bUR_eUVcABg

⬐ lord_quas

Wow, there are some really cool and unique ideas in this editor. Thank you for sharing.

I am of course so ingrained in the emacs way that I probably will never change editors.

⬐ wingerlang

Interesting but I feel the constant switching between mouse and keyboard would get annoying really fast.

⬐ aidenn0

The theory is that it's modal like vim; when you are entering text, you have both hands on the keyboard; when you are manipulating text, you have one on keyboard and one on mouse.

⬐ judk

Yes but whe editing programs we are constantly alternating between insertion and manipulation every few seconds.

Acme with keybindings for chord actions might be interesting

⬐ kps

Which goes all the way back to the beginning: Englebart's NLS, which had a mouse on the right and a chord set on the left of the keyboard. (Go watch The Mother of All Demos if you've forgotten; I'll wait.) The Xerox Alto borrowed the chord/mouse pair; then the Xerox Star team found the chord set too hard for normal people to learn, and substituted dedicated function keys on the left of the keyboard, still designed to be paired with the mouse. (Incidentally, while we're talking editors, Star had a MOVE key instead of CUT and PASTE, because it was a user interface principle that there be no hidden state.)

⬐ discreteevent

" The basic summary is cursoring around required a higher level of mental planning to organize the interaction, which apparently obscures the perception of the passage of time--think of being deeply engaged in something and being surprised when you look at a clock-- whereas the use of the mouse was done at a lower, mechanical level that left the mind free for higher things, such as complaining about the mouse."

http://plan9.bell-labs.com/wiki/plan9/Mouse_vs._Keyboard/ind...

> Has anyone used this extensively?

Rob Pike and any devoted Acme users?

http://www.youtube.com/watch?v=dP1xVpMPn8M

There is Acme for Plan9 [1] and it has inspired a few other editors. I don't use them myself because they don't have syntax highlighting.

[1]: demo at http://www.youtube.com/watch?v=dP1xVpMPn8M

⬐ symmetricsaurus

That looks awesome. Having used the WMII window manager it looks quite familiar. Even then the learning curve seems steep.

If you haven't seen acme in action, it is pretty crazy and interesting. Basically it makes heavy use of the mouse, and any typed word can be invoked like a command.

Here is a tutorial. https://www.youtube.com/watch?v=dP1xVpMPn8M

⬐ wyclif

The mousing is what lost me. I love vim because you don't have to deal with the mouse at all.

⬐ jff

The mousing is what adds a crazy amount of power. You end up with dozens of files on screen, some showing text, some just displayed as the "tag" line. You use the mouse to rapidly jump around them, select text from one, paste into another, etc.

The mouse is a pointing device, why not use it to point at things? If I have 3 columns in my acme window (which I usually do) and I'm working in the 3rd file down in the left-most column, it's faster to get to the top file in the right-most column by just grabbing the mouse and clicking than by futzing with key combos.

⬐ None

None

⬐ wyclif

You make a good case for acme; I'd be willing to try it. But I'm not convinced that in any context grabbing the mouse (with or without chording) is faster than keying, esp. since in vim many of the most important navigational keys are on the home row.

⬐ jff

You really need to try it, if nothing else it will broaden your experience so you can compare vi vs. emacs vs. acme. Myself, I watch vim users spend so much time just trying to get their cursors to the appropriate part of the file/line, and then select the appropriate text, that I scratch my head--this is faster? By the time you've figured out that typing "/whatev" should be sufficient to get you to the point you want, I could have grabbed the mouse, simply pointed it to the location I'm interested, and had my hands back on the keyboard already. Don't get me wrong, I also use vi a lot because it's very convenient and very powerful, but there are some things I'm much happier with in Acme.