The Lumber Room

"Consign them to dust and damp by way of preserving them"

Archive for October 2006

Emacs copy/paste and X

with 17 comments

Many people have problems getting copy-paste working in Emacs. Sometimes this can be ascribed to a misunderstanding of how the system works, but often it is a bug with Emacs itself.

First, a general word about how cut/copy/paste work in Linux and all applications:
Much of the confusion arises because there are actually two mechanisms for copying text between applications:

There is an explicit “clipboard”, just as in Windows. If you select some text, and explicitly click “copy” (or “cut”) somewhere (that is, either in the right-click menu or in the Edit menu, usually), it goes into the clipboard. You can paste it elsewhere by again explicitly clicking on “paste” (or Ctrl-V, often). This works perfectly well within itself, and just as in Windows, so there are no problems at all (except in Emacs sometimes, and we’ll come to that).
Primary selection
In addition, there is the “primary selection”. Consider it an additional feature which you can ignore if you like. It works like this: when you select some text (just select… highlight it, that’s all), it gets automatically “copied”, and you can paste it into another location simply by middle-clicking. This is intended for more temporary tasks, and shouldn’t be used for anything serious. A thing to watch out for is that unlike in the case of the clipboard, the text doesn’t really get copied anywhere. What actually happens when you middle-click to paste, is that the destination program asks the source program the text to be pasted. A consequence of this is that if you select some text and close the source program, you can’t paste that text anymore. In short, a good way to think of this is as “extended drag-and-drop“, in which you are allowed to let go of the mouse, change windows, and maybe even do a little bit of work (which does not require selecting) in some another window before finally “dropping” with the middle-mouse click.
[There is also a “secondary selection” and another ancient mechanism involving “cut buffers”, but neither of them is in use these days. Clipboard managers, like Klipper or the GNOME clipboard tool, can often be asked to use either the clipboard alone or the primary selection too.]

This general picture is explained at jwz’s page and in this spec.

Second, the problem: Somehow, Emacs has problems with this. It is very inconsistent, so it’s hard to pin down the exact nature of the problem, but in general copying text between other applications and Emacs seems to just not work sometimes. With me, pasting into emacs works (almost always) by default; copying from emacs doesn’t, no matter what I try. Others have had the opposite problem.

Some possible solutions/ideas:

  1. This page claims to have a fix, which is essentially to add the lines
    (setq x-select-enable-clipboard t)
    (setq interprogram-paste-function 'x-cut-buffer-or-selection-value)

    to ~/.emacs. It didn’t help.

  2. There is mouse-sel-mode, which seems to affect pasting into emacs, whatever the name might say.
  3. The emacs manual says

    To copy text to another X window, kill it or save it in the kill ring. Under X, this also sets the primary selection. Then use the “paste” or “yank” command of the program operating the other window to insert the text from the selection.

    , but it didn’t help me either.

  4. I’ve discovered that the situation is better when Klipper is running — selecting (or copying) text in Emacs results in it being copied (imperfectly) to Klipper, and I can then paste in other apps, provided I first click on Klipper and choose that text. Weird.
  5. I can select in Emacs, and middle-click it onto konsole. It works. I can then select that and paste it into Firefox. That works too. So maybe Emacs and Firefox don’t have a good way of talking to each other. (The same seems to be true of any GNOME app, not just Firefox.)

The bug is clearly somewhere under x-set-selection, because invoking it directly doesn’t work either.

And, trying to set the Emacs font today, I discovered another bug: I couldn’t paste from the xfontsel selection to any KDE app. I could do the thing of pasting into Firefox and then pasting into Emacs, though. There is also this discussion about what happens (or should happen) when something is “copied” without being selected first.

There are some other discussions at , , and this Slashdot article about copy-paste, although none of it has been useful.

Please leave comments here if you have something to say; I still haven’t managed to find a workaround.

Updates: I found that M-x clipboard-kill-ring-save and M-x clipboard-yank seem to work for copying from Emacs to the clipboard and pasting from the clipboard into Emacs. In some of the comments below, Richard Lewis had the idea of using xsel, and Hugo Heden completed it further.

Written by S

Sun, 2006-10-22 at 23:55:00

Posted in compknow

Unpronounceable surnames

with one comment

There is a list of surnames (and anecdotes) here.

Reminds me of the joke (no point telling it like a joke now) of the Polish guy who goes to get an eyesight test, is asked if he can read the writing, reads


, and informs the doctor he actually knows the guy.

Written by S

Fri, 2006-10-20 at 20:30:21

Posted in funny

Kamion — User State Migration Tool for KDE

leave a comment »

See also Kamion’s project page and what’s probably its development blog.

Written by S

Tue, 2006-10-17 at 11:33:45

Posted in compknow

Tagged with

Bash script

leave a comment »

Relocate, using lns from Simon Tatham’s site.

function crude_dirname()
    echo "${1%/*}" # everything before last '/'

function crude_basename()
    echo "${1##*/}" # everything after last '/'

function relocate
    #Strip trailing slash, if there is one

    a_act=$(crude_basename $a)
    b_dir=$(crude_dirname $b)
    b_act=$(crude_basename $b)

    echo "mv $a $b"
    if [ -z $b_act ] #If the string b_act has length 0
    echo "lns $loc $a"

    echo "Fine?"
    read x
    if [ $x == "y" ]
        mv "$a" "$b"
        lns "$loc" "$a"

Written by S

Mon, 2006-10-16 at 21:42:12

Posted in Uncategorized

Tagged with

Collaborative work with LaTeX

with 5 comments

All things considered (after trawling through more than a dozen pages of Google results, that is), I’ve arrived at the conclusion that the best way [as of 2006-10-11] to work on LaTeX documents collaboratively is to use a CVS or Subversion repository, and let everyone commit changes to it.

There seems to be a MediaWiki plugin for collaborative LaTeX, but it needs some attention to security issues…

Someone asked around, and put up an extremely useful summary.

There’s a very short CVS tutorial here.

Update[2007-11-25]: For some reason, the PracTeX journal had three articles about LaTeX+Subversion in 2007-08: LaTeX Document Management with Subversion, Version Control of LaTeX Documents with svn-multi, and Subversion and TextMate: Making collaboration easier for LaTeX users. It’s a good idea to pick the simplest solution that works for you. I haven’t read those articles, but we did use LaTeX in a (somewhat) collaborative way (we weren’t sharing the work much, so it’s not clear the others saw any good in it) for two of our courses, here and here. The websvn interface is a bit crufty; we were using the commandline interface.

The work cycle was as below: (in case you’ve never used version control and don’t know what it is, this will show you that it’s simple after all!)

[Don’t use these URLs; they won’t work for you, of course.]

How to use the algcomp-notes subversion repository.

==Initial setup (only once)==
    svn checkout working-dir	

==Work cycle (each time)==
    svn update     # to get the latest version from the repository
Now work with your files as you usually would. After you're done, do:
    svn diff          #optional: to see what you have changed
    svn commit -m "some message, for the history"

Extra files you create in the directory are ignored. To add a new file, use:
    svn add [filename]

That’s all there is to it (apart from setting up — or getting someone to set up — the repository and access to it in the first place. Ask your sysadmin :-)

Update[2008-02-05]: Gobby is a collaborative text editor, and can be used with LaTeX, as this screenshot shows. Someone even wants to use Darcs’s Theory of Patches, and give it proper Undo etc… and at that point we are back to the version control solution, but with a good version-control system and a simple GUI for doing things.

Update[2008-03-25]: Here is a post by an actual mathematician using version control.

I do think it would be a great idea for someone to provide a version-control service for collaborative LaTeX documents over the internet. They could go further and make it easy to edit LaTeX in a browser, and we would have something along the lines of Google Docs.

Update [2009-10-03]: Some other things worth a mention: online LaTeX editors like MonkeyTex (but no one really likes editing in anything other than their familiar environment), a page at Wikibooks based on one of the PracTeX articles mentioned above, and, coming Real Soon Now, support for LaTeX in Google Wave.(link.)

Update [2010-05-11]: Some more things to mention: ScribTeX (see comments below), and LaTeX-lab, a plugin for Google Docs.

Update [2010-06-23]: Also see this Mathoverflow thread called Tools for Collaborative Paper Writing.

Written by S

Wed, 2006-10-11 at 20:50:53


leave a comment »

There is an article here which begins well, but is not at all impressive.

The C Preprocessor manual (available, say, here) has a section on macros, and I intend to read this soon.

Written by S

Wed, 2006-10-11 at 18:33:19

Posted in Uncategorized

Tagged with

Technical writing bookmarks

leave a comment »

From an AUE post:”””

Written by S

Wed, 2006-10-11 at 18:13:22

Posted in Uncategorized

Tagged with