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.
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.
* "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! :)
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.
'"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.
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.
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 .).
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.
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 :)
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).
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.
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.
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.
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.
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...
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!
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.
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.
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.
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)
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.