Edit: A Relaxing Mix of Vi and Acme | Hacker News Reader

Edit: A Relaxing Mix of Vi and Acme

c9x.me

118 pointsqznc54 comments

I'm glad to see such a positive reaction! I worked on that for quite a while and use it daily. I think the code is of pretty good quality (never had a segfault or data loss while using it). If you try it and encounter annoyances because it does not behave exactly like what you want, you have to hack in the code! I will never fix something myself if it does not annoy me. This does not mean that I did nothing for you, instead I tried a lot to make the code such that everybody can hack it, it is very regular, short, simple and occasionally well documented (vicmd.w, buf.c).

I spent a probably unreasonable amount of time thinking on its design and I believe I came up with something satisfying, the code is only 3000 lines but one or two features I want remain to be hacked in. The undo and the buffer data structures were tested automatically for several hours with success (see the tools/ subdir), no data was ever lost. The file saving command is even formally proved correct in Coq.

Any suggestion that could simplify the logic and preferably decrease the line count is more than welcome.

Also, note that the version showed in the video is a bit deprecated, the master branch now supports better handling of async commands and window splits (vertical and up to 6 windows) with resizes using the mouse.

Some are concerned about the license. It is public domain. But please tell me if you do something cool with it or like it.

Everything about this awesome, really.

Looks like there are some differences with vi, among others:

* "dd" is not implemented, use "d_"

* "cw" will not work as in vi, use "ce" or "cl"

* "r" is not implemented, use "cl"

I think these are very common mnemonics, so I wonder why they are not implemented and if there are any plans to do it in the future. I use these all the time, so this would be a major turnoff for me.

Because they are not very reasonable?

* "dd" isn't reasonable because it violates the "command + movement/region" structure of vi commands. So is "cc" and "yy". None of "c d y" is not a movement or region. Presumably in this editor "_" represents the "whole line" region, which leads to also "c_" and "y_". Much more regular although it does require you to lift your finger one more time.

* "cw" isn't reasonable because "w" as a movement usually means "to the next word", but in "cw" it means "to the end of current word" instead. "ce" is indeed better.

* "r" is actually not bad (indeed "rx" is equivalent to "clx<Esc>", but the former requires 2 keystrokes), but I guess it's because the author rarely uses it.

Anyway the editor is pretty small, it might be easy or even fun to hack it! :)

dd, cc and yy violate that pattern of vi commands, but they form their own pattern. (g~~ is another instance of it.)

I agree that cw violates a pattern, but I think it's a reasonable violation. (Not necessarily good, but reasonable.

Given that you can get cw behavior with ce, I don't really think the original breaking of cw was reasonable (though I expect it went the other way and cw existed before vi settled into its current verb-noun philosophy).

I agree with you on the doublings - probably makes most sense to preserve them.

That is a reasonable argument against the existing cw behaviour. I consider this to be a reasonable argument in favour: when you delete a word, you probably also want to delete the space after it; when you change a word, you probably don't.

There are reasonable arguments on both sides, and I don't think that the balance is overwhelmingly on either side, so I consider either choice to be reasonable.

(In general, to show that something is unreasonable, you can't simply present arguments against it. You need to show that the arguments supporting it are weak.)

I think that argument would be much stronger if forgoing deletion of the space was hard to do - but it's literally one key over. Further, it mucks with peoples' intuitions about what range w actually covers - something I'm only recently overcoming after 20+ years with vi and vim.

Meanwhile, I have found myself in the position of wanting to delete the space and had no way to express it (as a single action that I can redo with .).

Reasonable or not, dd and cw are wired into the fingers of almost every vi user, so they will indeed be a major turn-off for many. They are for me.

It's a reasonable expectation, and they're reasonable shortcuts. They many not conform to as strict syntax as other vim shortcuts, but english doesn't conform to any of it's own rules and I doubt we would call it unreasonable. All language is an abstraction of modelling the worlds things and concepts into sound.

'"cw" isn't reasonable because "w" as a movement usually means "to the next word", but in "cw" it means "to the end of current word" instead. "ce" is indeed better.'

I've recently been noticing this - dw behaves like dw, but cw behaves like ce and there's no way to express a real cw in a short number of keystrokes. Despite it breaking my muscle memory, I believe I approve of this change.

> there's no way to express a real cw in a short number of keystrokes.

dwi is pretty short.

... but not a single action. This is important when I want to repeat things.

Good point. It seems likely that caw will suit most of the time, but I can't think of an exact replacement.

Right, caw is probably the closest; cf<Space> is what I defaulted to earlier in my vi-ing, which is a little further away but also usually close enough.

Thanks, I didn't know about caw, because I learned vi on Solaris, which had real vi and not vim.

The a and i modifiers are great things - they can also be combined with most grouping characters (parens, brackets, braces, quotes).

> Presumably in this editor "_" represents the "whole line" region, which leads to also "c_" and "y_".

That's not specific to this editor. In vim _ goes from the cursor to the end of the line (but does not include the newline at the end like $ does).

The reasons you cite are the reasons why it is that way. Concerning the 'c' command, I leave it that way until people are so annoyed that they have to dive in the code themselves, it is a kind of social experiment. I got used to not using it.

I went through lots of thinking to make the code nice and clean and would like to see if it is indeed that way by having people modify it.

> you will also need cweb because one file is written in literate programming

Glad to see there is a small village of indomitable programmers still holding out against the invaders :)

It's still fairly alive in the academic community, with things like Sweave/knitr/IPython workbooks/Maple stuff/etc.

I hope the author of Edit is reading this thread. This sounds like a dream come true! The best form of encouragement is people using the software, but if the author wants us to wait, I'm cool with that - but I hope they make real progress quickly!

Now I have the itch to fire up and work in Acme again :)

For people not familiar with Acme, I found this 20-minute video tour very informative:

http://research.swtch.com/acme

Also, I asked HN about modern Acme clones recently: https://news.ycombinator.com/item?id=8269442 (glad this came along)

How about these (may have been mentioned on HN already, but not in response to your question):

minime: http://daten.dieweltistgarnichtso.net/src/minime/README, also http://blog.dieweltistgarnichtso.net/minime-a-minimalist-uni...

JaKme: https://code.google.com/p/jakme/

I'm the developer of plan9-for-vimspace[1], which you mentioned in your thread. I've not been very active with it, because I came up against some limitations in vim, but I really want to go further with it.

I would really like some feedback on what stuff should go in or out. I've thought a lot on how to implement acme's tag lines and a plumber system (just this weekend, I was thinking of providing a fuse-based system for that).

[1] https://github.com/fmoralesc/plan9-for-vimspace

Were the issues you hit being addressed by neovim (https://github.com/neovim/neovim)? They seem to be pretty interested in making a more extensible vim.

Not yet, the plugin API is not yet stable. One thing I needed for this was something like multiple selections, which is not in the roadmap. I also wanted to implement moving the mouse cursor like acme does on movements, but that currently would require vim to provide more info about its display (also not in neovim's roadmap, especially since it doesn't provide a GUI yet).

For the first point, I can hack something up with the recently merged (by yours truly) `matchaddpos()` function, and I think I will do so this week. I've been also toying with computing a character's position in vim's display taking into account splits, but that has proven to be very hard.

sam.pdf 404s

Thanks for that! I've long wondered what made Acme special, and never had the patience to read through Pike's paper.

TL;DW (my notes as I'm watching it for people who prefer text): Acme includes its own tiling window management for your open files/buffers. It is strongly mouse driven, where clicking or highlighting regions with the different buttons perform different actions. For example: highlight text with button 1, then with that held down clicking button 2 cuts that text. This mouse button combination/sequence is a "chord".

More powerful is the "execute" action (button 2) on various text. executing the word "cut" does that. You can execute external programs this way, with the output appearing in a new buffer. You can of course pipe or redirect selected text to/from external programs. You can add frequently used commands to the "menu bar" ("tag") by typing them there.

With the "load" action (button 3), you can load files by name and added references (such as open file at given regexp point and highlight to another point). This allows easy and native opening of filenames given by compiler errors.

Acme supports UTF-8 Unicode natively (aside: UTF-8 was invented for Plan9 where Acme comes from [1]).

Acme is an IDE that integrates external tools at the text level. As a Plan9 product, it exposes itself to other tools as a file system (using FUSE on Linux). Using this, the author created a simple presentation system used to demonstrate this very video.

An external script can read window events by reading a file in the file-system exposed by Acme. This can be used to implement a shell within Acme, or various things like mail readers, music players...

The button 3 (load) action can be used to easily open manpages and open related manpages by just highlighting "acme(1)", or directly view a given Mercurial commit by loading its hash, or even a UPS shipment by loading its tracking number. Things can be opened in external programs, and all of this is managed by a "plumber" program that has rules.

As a programming environment, you can run some 'watch' program on a work-in-progress buffer to (say) compile and run a program as you save.

TL;DR: Acme is a flexible editor that can perform programmable actions based on highlighted text and merge that into buffers, and exposes a filesystem-like interface for other programs to use.

PS: holy shit, I only just noticed that presentation was by Russ Cox.

[1] https://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt

And for a separate personal opinion: Acme indeed looks very very powerful, but I've gone too far down the keyboard-only path to ever accept its mouse-driven paradigm. Emacs (my poison of choice) has a bit of the same "interact with external programs through buffers" idea, though nothing as simple and powerful as Acme.

A wonderful idea, but in the current state I can’t use it since it doesn’t support entering Cyrillic.

In fact, vim doesn’t do the right thing with Cyrillic either (vim binds commands to entered characters, not keys; so when entering Cyrillic you either have to switch layouts when entering commands — or do some ugly hacks), but it’s at least usable. Edit is not, right now.

That's neat, it reminds me of MPW and the scheme interpreter I used long ago on a mac, wish I could remember which one now. They had a worksheet where you could go back to a previous line with the keyboard or mouse and hit enter there (or edit it first and hit enter then) to execute. I had a very nice worksheet with lots of templates I would follow.

Eddie(Text Editor) by Pavel Císler has a worksheet like that.

I found this in the doc/ subdirectory of the repository: http://c9x.me/git/?p=ed.git;a=blob;f=doc/republic.txt;h=366f...

I am really curious about what the full text of Republic is doing here...

Its probably for testing purpose. Its a big file of natural text so you can easily checks a lot of things with it and its a lot less boring than pages of lorem ipsum...

But, its funny that it is more than half of the full content in the git clone...

Ah, indeed. It turns out that the "doc" actually means "text documents" instead of "software documentation".

I thought it could be fun to include it in the documentation. Why not, after all. This is a good read. It turns out that I also used it for tests, if the editor behaves smoothly on this file I judge it fast enough.

Lovely.... Now to get some command line utils to interact with a clojure repl and some form of splits (i.e. for documentation).

This is actually something I might contribute to! :P

edit: async is already in... mea culpa

Splits are available in the git master branch.

just noticed; very awesome. For some reason this editor gives me the same feeling I had "back when I was little" when I was using IDE's like Turbo Pascal's. It just feels... modern retro!

Very nice. Wish it was on Github for easier contributing (and issue tracking).

>easier contributing

Er... what? What's hard about contributing? You don't have to go through a web interface for everything? IMHO that makes it easier.

    $ git clone git://c9x.me/ed.git
    <do your changes>
    $ git format-patch --cover-letter <any other options you want> <commits>
    <edit the file if you want>
    $ git send-email <the file>

`man git send-email` will tell you anything you need to know: configuration options, examples... If is well-written and straightforward! Seems like the author isn't interested in public issue tracking (yet), and using Github wouldn't have changed that.

I, for one, celebrate that he's not using Github. I'm very afraid of the git == github trend I'm seeing amongst many people (technically semi-literate or even technical people)

Excellent points. Monocultures are terribly harmful, especially in the open-source side of things. While github is convenient, it's not the right answer for a lot of things and terribly inconvenient for others.

I use git without github. I use it with vim outliner and keep the issues in the repo.

You use vim outliner plugin for the issues? How does that work?

Are your issues simple text files describing it? In a "issues" folder? Do you enforce a format? How do you track their status?

Not the parent, but I do something similar for projects where I am the only contributor. It is far easier to track them with a simple text editor.

For multiple contributors, I don't think this will scale well, atleast without using some tool on top of the VCS.

Yes. Indent per issue. One .otl file with all issues in it. No format enforced although I'm pretty consistent at writing issues. Once complete the issue is simply deleted. I've done this up to 4 people and it has worked wonderfully even though they had to learn vim :)

You can pipe it through awk to remove any lines starting with a space/tab, sort it then then diff the result with earlier versions to work out progress etc as well.

I wouldn't mind bitbucket, either. Anything that would give this more exposure.

And, seriously, e-mailing patches is tedious, error-prone and ultimately inefficient. _anything_ that smooths the path for contributors is paramount for a successful project, and I, for one, would love this becoming more than a one-off, niche thing.

(I'd also like to have Alt-Enter instead of Tab on it, and a Mac port, and even though the first is trivial enough to do, the second requires a fair amount of time to implement)

While I'm all for not standardizing on github, git send-email doesn't actually work.

First off, your assumption that people use the command line to interact with git is no longer correct. While that was true when I started using git, that's no longer a requirement for basic usage.

Next, perhaps as a corallary, many computer users don't have local email working, ie 'mail user@example.com' on the command line doesn't work. This means that git send-email also won't work.

Sad to say, but getting git send-email working is (unfortunately) beyond some people (as is getting a working 'tar' command line sans Google, apparently).

It's been a few years, but I got `git send-email` to work pretty easily back when I was contributing to Git. I seem to recall there simply being some configuration to tell it what SMTP server to use, and then just creating a single ~/.gitaliases file to map nicknames to email addresses.

There's also `git imap-send` if you want to have it dump the email into the Drafts folder on an IMAP server, where you can review it and send it from your normal mail client.

This is fantastic. I felt like I was alone in thinking acme is great, but is missing a text editor. Nice to see I'm not the only one.

I might just be missing it, but I don't see the license mentioned anywhere. Anyone know what it is?

I hacked it. It's public domain for now. I might (or not) switch to MIT later.

I don't think that's possible. If it's public domain, none can claim copyright.

Reply on news.ycombinator.com