Pasky’s Log

I recently switched to xterm-256color in my konsole, but I found that vim looks exceedingly ugly, unfortunately. The colors were all washed out and difficult to read with reduced brightness. I decided to explore some alternative color schemes, including popular ones like solarized etc., but they just don’t work for me – I have the default color scheme burned into my mind and I really like its high contrast even though I can easily stare at it for 12+ hours in a row. It also works great even in adverse light coditions on a notebook.

In the end, I didn’t find any dark vim color scheme that would just look like its default 16-color color scheme. (Light background color scheme looks mostly the same in 16 and 256 colors by default.) So I had to create my own – 256like16.vim, drop it in ~/.vim/colors. You may want to edit yours to add some more bolds to make it look exactly like the 16-color scheme, but I ended up liking this one more, after all.

(You will need to install colorsupport.vim so that GUI color settings are used in the 256-color terminal. This particular script worked by far the best for me, and :ColorSchemeBrowse is also great when exploring schemes.)

Call me old-fashioned but I’m still using xterm on my desktop computer (where I use just fluxbox as my window manager) – it suits me just fine, but for one thing that I finally managed to solve. xterm by default ignores the clipboard, and none of the previously published solutions cut it for me, until now.

In X11, we have two commonly used selection buffers – PRIMARY and CLIPBOARD:

• PRIMARY is used when you simply highlight text in most applications, without pressing anything, and you can paste from it using the middle mouse button; it is of fleeting nature and used for quick cut’n’paste; and it doesn’t work well with all applications, e.g. libreoffice doesn’t put highlighted stuff there at least in some contexts and non-textarea HTML5 text edit widgets usually can’t handle the middle button for pasting.
• CLIPBOARD is used when you use ctrl-c or ctrl-v and can be used even with the evil applications above, but the problem is it’s not supported by xterm well!

In most terminal emulators, you can use the clipboard either using menus or shift-ctrl-c / shift-ctrl-v. However, in xterm, the best you can do is either…

• Make it use CLIPBOARD just instead of PRIMARY and in the same manner – the moment you select any text in xterm, it will plaster it over whatever else was in the CLIPBOARD before, without any explicit action. This sucks.
• Have a different set of bindings for selection to PRIMARY and CLIPBOARD. This is a lot better, but I’m out of modifiers since I use shift to cut’n’paste in terminal applications that use mouse themselves (e.g. elinks).

So, my solution is to bring in the shift-ctrl-c / shift-ctrl-v bindings! In your ~/.Xresources or ~/.Xdefaults, add

XTerm*VT100.*translations:      #override \
        Shift Ctrl C: select-end(CLIPBOARD, CUT_BUFFER0) \n\
        Shift Ctrl V: insert-selection(CLIPBOARD, CUT_BUFFER0)

(and don’t forget to xrdb ~/.Xresources afterwards).

Now, you can use shift-ctrl-v for pasting from CLIPBOARD, and almost use shift-ctrl-c for copying to clipboard. There is a catch – you must press shift-ctrl-c while you are still holding the mouse button, i.e you press left mouse button, drag your selection, then before releasing it, press shift-ctrl-c; thankfully, that can be done by one hand without too much cramping.

It’s a bit inconvenient because of this bug, and doesn’t quite work with left and right selection; maybe I will sometime get around to adding true clipboard support to xterm code, but I think this is good enough for me at this point. :)

I’ve recently encountered a problem (on Debian Squeeze) with screen running in xterm, and applications using mouse reporting running inside – that is, an application that can be controlled using mouse while running in a terminal (in my case, elinks, and vim with :set mouse=a behaves the same although I don’t use that setting normally).

Basically, when you start the application, mouse reporting will never be switched off again (unless you do it manually or use `reset`). Not when the application exits, and (more importantly) not when you switch to another screen window!

I tracked this down to autonuke on in my ~/.screenrc. Apparently the clear screen command goes _after_ the turn-off-mouse-reporting command, nuking it in the process. I have enabled this option in the past in the hope that it will be helpful in case I inadverently trigger huge amount of data being sent (I could just “C-a -” to clear my screen. Too bad this breaks it; maybe GNU screen could be made smarter about this and not nuke escape sequences, but I have heard that its developers are fairly unfriendly, so I won’t pursue this further as I don’t need it that badly.