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.
* "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! :)
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.
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.
dwi is pretty short.
I agree that cw violates a pattern, but I think it's a reasonable violation. (Not necessarily good, but reasonable.
I agree with you on the doublings - probably makes most sense to preserve them.
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.)
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 .).
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).
Glad to see there is a small village of indomitable programmers still holding out against the invaders :)
Now I have the itch to fire up and work in Acme again :)
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).
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.
minime: http://daten.dieweltistgarnichtso.net/src/minime/README, also http://blog.dieweltistgarnichtso.net/minime-a-minimalist-uni...
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 ).
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.
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.
I am really curious about what the full text of Republic is doing here...
But, its funny that it is more than half of the full content in the git clone...
This is actually something I might contribute to! :P
edit: async is already in... mea culpa
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>
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)
I use git without github. I use it with vim outliner and keep the issues in the repo.
Are your issues simple text files describing it? In a "issues" folder? Do you enforce a format? How do you track their status?
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.
For multiple contributors, I don't think this will scale well, atleast without using some tool on top of the VCS.
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 firstname.lastname@example.org' 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).
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.
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)