Clipboard history

The Windows clipboard only remembers the most recent thing you copied [1]. This can be very disappointing. Maybe you cut a large block of text intending to paste it somewhere, but without thinking you cut something else, and then realize you’ve just wiped out your first cut. Here are a few possible alternatives for Windows, MS Office, and Emacs.

A few years ago I tried ClipX, a free clipboard history manager for Windows, based on Jeff Atwood’s recommendation. It worked OK at first, but then I had problems with it and stopped using it. It looks like the software hasn’t been updated since 2008. If you know of a better alternative, please let me know. Also, please let me know if you have suggestions for Ubuntu.

(Update: See the comments for numerous suggestions of ClipX-like products. Also, see PHenry’s comment about clipboard history in Visual Studio.)

MS Office has its own clipboard that will store 24 entries. It stores things that have been copied either inside or outside of Office applications, but you can only paste from the Office clipboard using an Office application.

Emacs has a “kill ring” which is essentially a clipboard. It also has “registers” which are like named clipboard items.

Yesterday Emacs Knight posted a handy little bit of code for viewing your kill ring.

    (global-set-key "C-cy" '(lambda ()
        (interactive) (popup-menu 'yank-menu)))

If you add this to your .emacs file, you can type ctrl-c y to pull up a little GUI menu displaying the contents of your kill ring.

[1] I’ve heard that Windows actually keeps more clipboard history, but it doesn’t provide a user interface for accessing that history. I don’t know whether this is true. But if it is, you could access the history programmatically. Maybe Office isn’t maintaining its own clipboard but just exposing more of the system clipboard.

Playing with Eshell

I’ve been trying out Eshell lately. It’s a shell implemented in Emacs Lisp. Here I’ll mention a few features I’ve found interesting.

The command M-x shell lets you run a shell inside Emacs. This is quite handy, but it runs a different shell on each platform. For example, it might pull up bash on Linux and cmd.exe on Windows. Eshell provides a consistent shell across operating systems.

Eshell is one way to have a bash-like shell on Windows, so it’s an alternative to Cygwin. I haven’t used Eshell or Cygwin extensively, but Cygwin feels like some alien thing awkwardly grafted on to my Windows machine. Eshell feels more like cmd.exe with bash features added.

Of course Eshell is integrated with Emacs. One example of that is being able to run Emacs commands as shell commands. For example, you can run dired from the shell to open a directory in the Emacs directory editor.

Eshell has pseudo-devices. These act like Unix devices, but they’re implemented in Emacs and therefore run on non-Unix platforms. For example, you could direct command output to /dev/clip to send it to the system clipboard or to  /dev/kill to add it to the Emacs kill ring.

And now for a little silliness. Here’s an excerpt from Tron featuring Eshell.

It goes by very fast, but here’s the frame that shows Eshell:

eshell screen shot

For much more on Eshell, see A Complete Guide to Mastering Eshell.

Mixing R, Python, and Perl in 14 lines of code

This is a continuation of my previous post, Running Python and R inside Emacs. That post shows how to execute independent code blocks in Emacs org-mode. This post illustrates calling one code block from another, each written in a different language.

The example below computes sin2(x) + cos2(x) by computing the sine function in R, the cosine function in Python, and summing their squares in Perl. As you’d hope, it returns 1. (Actually, it returns 0.99999999999985 on my machine.)

To execute the code, go to the #+call line and type C-c C-c.

#+name: sin_r(x=1)
#+begin_src R

#+name: cos_p(x=0)
#+begin_src python
import math
return math.cos(x)

#+name: sum_sq(a = 0, b = 0)
#+begin_src perl
$a*$a + $b*$b;

#+call: sum_sq(sin_r(1), cos_p(1))

Apparently each function argument has to have a default value. If that’s documented, I missed it. I gave the sine and cosine functions default values that would cause the call to sum_sq to return more than 1 if the defaults were used.

Running Python and R inside Emacs

Emacs org-mode lets you manage blocks of source code inside a text file. You can execute these blocks and have the output display in your text file. Or you could export the file, say to HTML or PDF, and show the code and/or the results of executing the code.

Here I’ll show some of the most basic possibilities. For much more information, see And for the use of org-mode in research, see A Multi-Language Computing Environment for Literate Programming and Reproducible Research.

Source code blocks go between lines of the form


On the #+begin_src line, specify the programming language. Here I’ll demonstrate Python and R, but org-mode currently supports C++, Java, Perl, etc. for a total of 35 languages.

Suppose we want to compute √42 using R.

    #+begin_src R

If we put the cursor somewhere in the code block and type C-c C-c, org-mode will add these lines:

    : 6.48074069840786

Now suppose we do the same with Python:

    #+begin_src python
    from math import sqrt

This time we get disappointing results:

    : None

What happened? The org-mode manual explains:

… code should be written as if it were the body of such a function. In particular, note that Python does not automatically return a value from a function unless a return statement is present, and so a ‘return’ statement will usually be required in Python.

If we change sqrt(42) to return sqrt(42) then we get the same result that we got when using R.

By default, evaluating a block of code returns a single result. If you want to see the output as if you were interactively using Python from the REPL, you can add :results output :session following the language name.

    #+begin_src python :results output :session
    print "There are %d hours in a week." % (7*24)

This produces the lines

    : There are 168 hours in a week.
    : 1024

Without the :session tag, the second line would not appear because there was no print statement.

I had to do a couple things before I could get the examples above to work. First, I had to upgrade org-mode. The version of org-mode that shipped with Emacs 23.3 was quite out of date. Second, the only language you can run by default is Emacs Lisp. You have to turn on support for other languages in your .emacs file. Here’s the code to turn on support for Python and R.

        'org-babel-load-languages '((python . t) (R . t)))

Update: My next post shows how to call code in written in one language from code written in another language.

Related posts

Advantages of everything-is-text

In a typical Windows program, some output text can be copied as text but some is only an image. For example, the text in the body of a document is text, but the words on the menus are not. The text in a dialog box may or may not be.

In Emacs, text is just text, no matter where you see it. This means that Emacs is less visually interesting because there is less variety. But this also has several advantages that may not be immediately obvious. I’ll give a couple examples.

The Emacs directory editor dired lists files in a text buffer. The output is essentially the output of ls. (On Windows, Emacs emulates ls.) That means you can do anything to the output you could do to text: copy, paste, search, etc. No text is off-limits. And in editable mode, you can rename files just by editing their names. You could, for example, rename many files at once using regular expressions.

Dired also lets you navigate the file system with the same commands you use to edit files. In particular, you can keep your hands on the keyboard. (It’s possible to use the Windows file explorer without a mouse, but it’s limited and awkward.)

Another advantage of everything simply being text is that you can run a shell inside Emacs. Why not? A shell is just text output. In an ordinary shell, editing commands are mostly limited to the current line. Not all text is created equal. But when you’re running a shell inside an editor, all text is equal: current line, previous lines, and text on either side of the command prompt. And if you want a transcript of a shell session, just save the buffer displaying the session.

If you’re shopping for a text editor and spend an hour trying each one out, Emacs may not look very promising. It has odd terminology, weird key strokes, etc. But if you try Emacs long enough, and particularly if you have someone to help you get started, you start to appreciate the advantages of subtle features such as everything simply being a text buffer.

Related posts

A surprise with Emacs and Office 2007

I had a little surprise when I tried to open an Excel file from Emacs. I was using dired, a sort of file explorer inside Emacs. I expected one of two things to happen. Maybe Emacs would know to launch the file using Excel. Or maybe it would open the binary file as a bunch of gibberish. Instead I got something like this:


This was disorienting at first. Then I thought about how Office 2007 documents are zipped XML files. But how does dired know that my .xlsx file is a zip file? I suppose since Emacs is a Unix application at heart, it’s acting like a Unix application even though I was using it on Windows. It’s determining the file type by inspected the file itself and ignoring the file extension.

(Office 2007 documents are not entirely XML. The data and styling directives are XML, but embedded files are just files. The spreadsheet in this example contains a large photo. That photo is a JPEG file that gets zipped up with all the XML files that make up the spreadsheet.)

So I learned that Emacs knows how to navigate inside zip files, and that a convenient way to poke around inside an Office 2007 file is to browse into it from Emacs.

Here’s another post that discusses Emacs and Office 2007, contrasting their interface designs: Clutter-discoverability trade-off

Mental context switches are evil

This week I’ve run across two examples of technical strategies to reduce mental context switches.

The first example is Pete Kruckenberg’s story of why his team chose to develop a web application using node.js even though he had extensive experience in Perl/Apache. One of his arguments is that since the client-side code has to be written in JavaScript, it saves mental energy to use JavaScript for the server-side code as well. Even for someone who knows JavaScript and Perl well, it takes mental energy to oscillate between the two languages.

There’s much more to node.js than its use of JavaScript. It requires a very different approach to developing web applications. Kruckenberg and his colleagues had to weigh multiple factors in deciding their development framework. But it may not be too much of a simplification to say they chose a big, one-time mental context switch—the node.js style of development—in order to avoid countless daily context switches between JavaScript and Perl.

The second example is Ryan Barrett’s blog post Why I run shells inside Emacs.

Mental context switches are evil. Some people handle them better than others, but not me. I handle them worse. I feel it, almost physically, when context switches whittle down my precious flow piece by piece.

Barrett explains that he first tried configuring Emacs and his shell to be similar, but the very similarity made the context switch more irritating.

Even something as small as switching between Emacs and the shell can hurt, especially when I do it thousands of times a day. … What’s worse, only some parts are different, so my muscle memory is constantly seduced into a false sense of familiarity, only to have the rug yanked out from under it seconds later.

Both examples highlight the cost of context switches. Neither Kruckenberg nor Barrett mentioned the cost of learning two contexts. Instead both focused on the cost switching between two contexts. Novices might understandably want to avoid having to learn two similar tools, but these stories were from men who had learned two tools and wanted to avoid oscillating between them.

My favorite line from Barrett is “context switches whittle down my precious flow piece by piece.” I’ve felt little distractions erode my ability to concentrate but hadn’t expressed that feeling in words.

It’s no exaggeration to call flow “precious.” Productivity can easily vary by an order of magnitude depending on whether you’re in the zone. It may sound fussy to try to eliminate minor distractions, but if these distractions make it harder to get into the zone, they’re worth eliminating.

Related posts

Bumblebee software

Some say that aerodynamics can’t explain how a bumblebee flies. Perhaps that was once the case, but as far as I know there are no difficulties now. The bumblebee story persists as an urban legend. And it makes a nice metaphor for things that work better in practice than in theory.

Here’s the passage that brought the bumblebee story to mind.

Almost every software engineering principle that has become generally accepted as useful and valuable, Emacs flouts. The code is 24 years old, huge, and written by hundreds of different people. By rights, the whole thing should blow up. But it works—and works rather well.

This comes from Jim Blandy’s chapter in Beautiful Architecture. Blandy explains that Emacs’ architecture has allowed it to thrive despite some apparent disadvantages. Emacs is mostly written in its own programming language, Emacs Lisp.

Emacs Lisp has no object system, it’s module system is just a naming convention, all the fundamental text editing operations use implicit global arguments, and even local variables aren’t quite local.

In short, Emacs expects developers to be self-disciplined and does not enforce a great deal of external discipline. However, because the software is so light on bureaucracy, it is easy to customize and to contribute to.

TeX is another bumblebee project. Like Emacs, it has thrived for decades without following currently fashionable software techniques. Knuth implies in this presentation that TeX would have been a dismal failure if it had used technologies that are trendy now.

Related posts

Personal organization software

I’ve tried various strategies and pieces of software for personal organization and haven’t been happy with most of them. I’ll briefly describe my criteria and what I’ve found.

My needs are fairly simple. I don’t need or want something that could scale to running a multinational corporation.

I’d like something with a portable, transparent data format. I don’t want the data stored in a hidden file or in a proprietary format. I’d like to be able to read the data without the software that was used to write it.

I’d like to be as structured or unstructured as I choose and not have to conform to a rigid database schema. I’d like to be able to do ad hoc queries as well as strongly typed queries.

I’d like something that exports to paper easily.

Here’s what I found: org-mode. It’s an Emacs mode for editing text files. It provides sophisticated functionality, but all the sophistication is in the software, not the data format. It’s more convenient to work with org-mode files in Emacs, but the raw file format is just a light-weight mark-down, easy for a person or a computer to parse.

When I went back to using Emacs a year ago after a 15-year hiatus, I heard good things about org-mode but didn’t understand what people liked about it. I heard it described as a to-do list manager and was not impressed. I’m not interested in the features I was first introduced to: tracking the status of to-do items and making agendas. I still don’t use those features. It took me a while to realize that org-mode was what I had been looking for. It was similar in spirit to something I’d thought about writing.

Emacs is an acquired taste. But someone who doesn’t use Emacs could get some good ideas from looking at org-mode. I imagine some people have borrowed its ideas and implemented them for other editors. If not, someone should.

The org-mode site has links to numerous introductions and tutorials. I like the FLOSS Weekly interview with org-mode’s creator Carsten Dominik. In it he explains his motivation for writing org-mode and gives a high-level overview of its features.

Related posts