Two Negatives

If you’re editing Clojure code in Emacs a lot, you’re probably using ⌥.. If you’re not, you should be. It’s a fantastic way to navigate around your code.

That being said, Emacs comes with this awesome feature where if you try to ‘edit’ an archive file of some kind, it’ll simply open it and allow you to edit it and then save the file back to the original archive for you. It’s all pretty magical.

Except when you’ve ⌥.ed into a jar file and find yourself editing it by mistake.

So I hacked together this very simple bit of Elisp. All it does is make a buffer produced by archive extraction read-only by default, which I’ll be thanking myself for later.

Enjoy!

If you’re like me, you’re stuck on Windows at your day job.

I know, I know. But it’s reality. No point in getting all upset about it.

On my mac, if I need to sync a large number of files between me and a remote disk, I have trusty rsync.

There are a number of utilities that offer support for rsync in Windows, but they aren’t that good. Cygwin runs like a dog on my work box and it’s really not an option. I did the whole Cygwin thing at my previous day job and since moving to my current one, I find that I’m much happier just using native tools. Besides, the only tool that matters has native Windows support so life is good.

I ran into the situation recently working remotely, though, where I had to copy a large number of files over and over again, after changing only a few of them, to a remote server. The copy would take about 2 or 3 minutes every time to copy the entire tree. At any given point, I may have only edited 2 or 3 files but the work involved with diffing the two directories or keeping track of edited files so that I could copy only the changes was outweighed by simply copying the tree over again.

More than that, I would delete files every now and again, and my method would break. In that event, I just deleted the whole remote tree and copied my entire tree into it again.

2 or 3 minutes, every 2 or 3 minutes, is a bit of an overhead.

What I wanted was rsync for Windows. I didn’t get that, but I got something that fit my needs just as well.

SyncToy is a little utility written by Microsoft and published as a PowerToy. An aside: PowerToys are programs that should really be included in Windows but aren’t for some reason. You really should install many of them. That’s another post.

SyncToy sports the ability to set up a group of Folder Pairs and run them as needed. A Folder Pair can be set up several ways:

1. Synchronize: Watches both folders and makes them look the same if you change either end.
2. Echo: Only watches the left side. Renames, updates and deletes are all done on the right.
3. Contribute: New and updated files, with renames, are updated from left to right. Deletions, however, are not.

The way it works is by adding a little file on either end that contains metadata about your tree. The file can be easily ignored if your using something like git. When you run a sync, it just compares metadata in your files and only copies changes which ends up being nice and fast.

There is a GUI, but you definitely want a CLI for quickly syncing up your directories directly from Emacs. To do that, you just add /path/to/install/directory to your PATH variable and run SyncToyCmd -R to run all your Folder Pairs. If you have too many Folder Pairs, there is a variant that accepts a Folder Pair name which only syncs that. The command line output is nicely descriptive and you can run the entire thing from the command line.

Not the most ground breaking discovery in the world, but hopefully it’s useful to others.

I’ve recently begun re-implementing a few of the remaining custom functions that I had written that had survived the move to the Emacs starter kit in terms of deft, the amazing notational velocity replacement for Emacs written by the inimitable Jason Blevins.

If you’re anything like me, you want to deal with text of any kind in Emacs. I’ve had somewhat poor success with things like Its-All-Text! in FireFox or the similar plug-in for Google Chrome. I was able to successfully set up Emacs server with a right-click context menu hack on Windows and with the standard Emacs services on the Mac, but I still find myself often enough wanting to edit a text box in some app in Emacs with no support but the clipboard to get that text there. What that translates to is:

1. Select all text
2. Copy text
3. Switch to Emacs
4. Create a new buffer
5. Yank in text
6. Set the mode to markdown
7. Turn on visual line mode
8. Open a new frame and size it appropriately for writing
9. Go to beginning of buffer
10. Start editing
11. Finish editing
12. C-x h
13. M-w
14. C-x 5 0
15. Switch back to whatever app I came from
16. Paste it in

That is a mouthful.

Long ago, in fact right around the time that I was getting back into Emacs, I wrote a long series of functions that would allow me to get rid of most of this hassle. The functions would create a new temporary file called markdown<timestamp>.md, launch a new frame titled the right thing, and yank my text into it and position point correctly.

The process then became:

1. Select and Copy Text
2. Switch to Emacs
3. M-x mdf
4. Start editing
5. Finish editing
6. C-x h
7. M-w
8. C-x 5 0
9. Switch back to whatever app
10. Paste it in

That’s better, but I implemented all sorts of weird logic to get the frames and the files correct. Now I have deft!

So I decided to re-implement things in terms of it. The only awkward part about it is that the current version of deft in Marmalade isn’t up to date.

Deft has a little function called deft-new-file that is the main interface as far as I can tell for creating a new deft file in the proper location with the proper auto-incrementing file name.

So our function is very simple. It just needs to create a frame and select it, call that function, turn on our modes, yank the text in, and set point to the correct position.

Easy peasy, but now maybe we can do a little better. After all, we’ve taken care of re-implementing popping open a frame with the correct contents, but don’t you think we should be able to get rid of those nasty steps at the end where we copy the buffer contents and close the frame?

Of course we can:

Now we could in theory give that an alias and call it via M-x, but is that what true Emacs ninjas like us would do? Of course not! We would bind it to C-c C-c (well, C-c C-q…) just like Magit wouldn’t we?

A big hat tip to Mickey for his excellent, excellent tutorial on key bindings in Emacs. Truly amazing stuff.

Now I have code merged in to Jason’s repo that autoloads deft-new-file but it still hasn’t made it to the Marmalade repo. Until that happens, you’d have to use this code like so:

Enjoy!