Edit: A text-editor mixing vi and Acme

by caslon • 5 years ago

106 31 5 years ago

tekknolagi• 5 years ago

Pity it requires X11. I figured it would be a terminal application.

caslon5• 5 years ago

Acme is inherently graphical. Moving to a terminal application would be a regression, in this particular case. Then again, X11 is also a regression, in Acme's case.

tyingq• 5 years ago

Watching the video, this "Edit" editor does look like could work in a terminal. The split screens that come up don't look much different than what you see with tmux, for example.

Edit: He mentions it's been updated since the video to use multiple actual windows.

butterisgood2• 5 years ago

Acme uses devdraw for graphics, and devdraw, on macOS anyway, doesn't require X11.

ithkuil2• 5 years ago

Works also on other graphical systems. Acme itself talks the plan9 graphical protocol which. There is an implementation of that protocol in the plan9 from userspace port (https://9fans.github.io/plan9port/man/man1/devdraw.html). I'm using it on macos where it's a native application with retina support and native macos fonts, native macos clipboard etc.

IIIRC there is a web implementation too but last time I tried it it didn't work. YMMV

butterisgood2• 5 years ago

Got a link to the web devdraw? That sounds terribly interesting.

MisterTea• 5 years ago

Plan 9 abandoned the ancient concept of the typewriter interface and instead uses a graphical 2d engine called devdraw. With that you can mix and match text with graphics in the same window. We emulate typewriter interfaces in the vt program which is a graphical program that implements a vt terminal. Its 2021, use graphics.

Most people want a typewriter interface because they want/need to edit files in an ssh session on a remote server. Plan 9 doesn't do remote teletype control and instead imports/exports resources. Of course plan 9 has ssh but it is split into three separate programs: an ssh client that performs the regular teletype interface to a unix machine, sshnet which imports the remote systems tcp stack, and sshfs which mounts a remote file tree locally.

If I wanted to edit text files on a remote unix machine, I'd just mount the file tree locally using sshfs and run sam or acme locally. Bring the resources to you and use your local tool set. Then you don't have to worry if the remote machine has x installed because you don't care.

1MachineElf• 5 years ago

Speaking of Plan 9 and Vim, readers may also find interesting the Vis editor: https://github.com/martanne/vis

caslon5• 5 years ago

A tutorial, if you don't know what it means by being influenced by "sam":

http://doc.cat-v.org/bell_labs/sam_lang_tutorial/sam_tut.pdf

gbrown_3• 5 years ago

Structural regular expressions seem pretty great. If Vis ever gets some Vim features that allow operating across multiple buffers (quickfix et al) I'd probably switch.

boogies• 5 years ago

Like https://repo.or.cz/vis-quickfix.git? (More plugins: https://github.com/martanne/vis/wiki/Plugins)

tharne3• 5 years ago

I've tried out vis and it's very nice editor. I'd love to see something like vim-slime developed for it so it could be used for repl-based development. I may even get off my lazy a-- one day and try to implement it myself.

moeris• 5 years ago

If you want the ability to pipe commands more natively, Kakoune does that. It also improves on vi's commands syntax, and allows multiple selections.

I switched to Kakoune after trying to find something more Acme-like for the terminal. In fact, I still use all the scripts that I wrote for Acme. To insert the results of a command, you can use `! <command>`. To pipe, highlight and use `| <command>`.

You don't get mouse chording, but I find I don't miss it too much.

b3n• 5 years ago

It also improves on vi's commands syntax

I've never used Kakoune, but reading about it I'm not sure it's an improvement.

One powerful vi feature is the dot command, and having verbs act on selections doesn't allow for that in the same way.

chongli2• 5 years ago

I have used Kakoune. I tried it out pretty extensively for a few weeks. I could not get comfortable with it. I've used vi and vim for two decades now. Kakoune seems like it would appeal to people who have moderate exposure to vi/vim but not mastery.

From the mastery standpoint, Kakoune seems like a big step down from the vi model. Too many of its commands/selections seemed to give priority to the edge case over the central one. Most of the text editing I've ever done with vi is of the garden-variety "navigate to this line and insert/delete/change one thing". Kakoune makes this more difficult by creating multiple cursors/selections as a side effect of its movement/navigation tools. It's like Kakoune is trying to tell me "no, you want to edit stuff all over the place!"

I also think the promise of Kakoune, that you can use selections to see what will happen before you type the command to actually make the change, is violated when there are selections outside of the visible portion of the file. Furthermore, with vi/vim I tend to type commands so quickly that the visual nature of Kakoune would only slow me down, and so at that point the advantage of selections is greatly diminished.

andrewla• 5 years ago

I am always trying to see if I can switch over to Kakoune -- I love the fact that the syntax is more uniform.

But there are a couple of things that just don't work for me and my brain can't make it work. Multi-select is one -- it seems to me to be a fringe case that I rarely use, but it is core to kak and causes confusion every time I need to <space> out of that mode.

The other is the fact that the cursor is always on a character (rather than admitting an "end-of-line" state is a distinct state), combined with the fact that a non-select "mode" is not a mode at all, but is a one-character selection. While I admit that this is more uniform, it means that the behavior of "delete the current line" is odd; "xd" will (select the current line) and (delete it). But if the line is blank then this won't work, because x will advance the selection (since the current line is already implicitly selected as a one-character end-of-line selection) to the next line.

I like the plugin model, but I think that relying on tmux for the splitting will eventually be a liability that we'll need to unwind in favor of a native splitting mechanic. The Vim project drawer model is too powerful to rely on unreliable interactions with an independent system.

mendelmaleh• 5 years ago

I considered trying out kakoune, but the name turns me off every time for some reason...

tux1968• 5 years ago

Even though a few people hinted this had to do with Plan 9, I had to look up that Acme refers to a window-system, shell, and editor environment. Here's a link to save you a search if you're in the same boat:

http://doc.cat-v.org/plan_9/4th_edition/papers/acme/

caslon5• 5 years ago

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

anthk• 5 years ago

Two much context switching, <ESC> + mouse. This is bad :p

I prefer a Go clone of Acme, edwood, albeit it's damn slow if you build the plan9port-less port without SSSE3.

https://github.com/rjkroege/edwood

yiyus• 5 years ago

The killer feature of acme (and, previously, sam) are structural regular expressions. As far as I see (and I admit I did not take a deep look), this is more a simple vi-like editor that runs inside an acme-like window manager.

Edit: A text-editor mixing vi and Acme

Related Stories