Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Edit: A Relaxing Mix of Vi and Acme

c9x.me

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Edit: A Relaxing Mix of Vi and Acme

#41

Post by mpu »

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.

Re: Edit: A Relaxing Mix of Vi and Acme

#42

Post by fmoralesc »

tsuraan wrote: post #40
fmoralesc wrote: post #29

Earlier quoted context omitted.

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…

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.

Re: Edit: A Relaxing Mix of Vi and Acme

#43

Post by fmoralesc »

mpu wrote: post #41

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,…

Everything about this awesome, really.

Re: Edit: A Relaxing Mix of Vi and Acme

#44

Post by philh »

dllthomas wrote: post #27
philh wrote: post #14

Earlier quoted context omitted.

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.)

Re: Edit: A Relaxing Mix of Vi and Acme

#45

Post by philh »

dllthomas wrote: post #26
xiaq wrote: post #8

Earlier quoted context omitted.

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…

'"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.

Re: Edit: A Relaxing Mix of Vi and Acme

#46

Post by dllthomas »

philh wrote: post #44
dllthomas wrote: post #27

Earlier quoted context omitted.

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 sh…

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 .).

Re: Edit: A Relaxing Mix of Vi and Acme

#47

Post by dllthomas »

philh wrote: post #45
dllthomas wrote: post #26

Earlier quoted context omitted.

'"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.

Re: Edit: A Relaxing Mix of Vi and Acme

#48

Post by AceJohnny2 »

prawks wrote: post #17

For people not familiar with Acme, I found this 20-minute video tour very informative: http://research.swtch.com/acme

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

Re: Edit: A Relaxing Mix of Vi and Acme

#49

Post by AceJohnny2 »

AceJohnny2 wrote: post #48
prawks wrote: post #17

For people not familiar with Acme, I found this 20-minute video tour very informative: http://research.swtch.com/acme

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…

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.

Re: Edit: A Relaxing Mix of Vi and Acme

#50

Post by philh »

dllthomas wrote: post #47
philh wrote: post #45

Earlier quoted context omitted.

> 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.
Post reply on HN