OddThinking

Emacs and bash both let you rebind the keys …

Yes, Mr Rohan, that is true. But there is more than just the difference of a few key-bindings.

For example, CTRL-C shouldn’t be sent to bash in the first place. It should be interpreted by the Windows GUI as a local clipboard operation.

Similarly, how could bash handle SHIFT-CTRL-Left (select a word to the left)? There isn’t even an ASCII character to represent that.

I wish I could offer some sort of solution for you. Instead I’m going to ramble on with a comment that is almost as long as your blog post. That’s almost as good as a real solution, right?

I have Windows and Linux desktops at work and a Mac at home. The work machines are linked via synergy (that would be the software application, not the corporate buzzword). And as a result I switch contexts a lot.

Of course the key shortcuts differ subtly across plaforms and applications, despite my persistent attempts to impose some kind of consistency. But even within a single OS the consistency is pretty dubious, as you point out for the case of Windows vs DOS. Emacs helps to bring order to it all, but there is still some variation – in the physical keyboard layout if nothing else – which needs to be accounted for.

Outside Emacs the key-bindings are frustratingly inconsistent. Some things work, some don’t. For example, here in Safari I can use ctrl-t to swap the two characters prior to the cursor but not meta-t to swap words, as I can in emacs. Little differences like this add up.

But because I switch contexts so damn often, my poor fingers just have to deal with it, and for the most part they do. I think I’ve trained my fingers to realise what context they’re in and adjust accordingly. Which is not to say it’s always a seamless transition, I suspect there are often small speedbumps, but they don’t often propogate up to reach my awareness. It seems that the fingers automatically shift gears and are able to continue in the new mode without necessarily interrupting the higher-level thought processes. And that is the really important part.

It’s my observation that most of the time – ignoring ctrl-c and cases like it – getting the keystroke wrong is relatively harmless. If I tell the fingers to move the cursor one word to the left and they get it wrong, it’s relatively simple to undo (with the corresponding right arrow), and carry on. Usually the worst that happens is that the wrong keystroke takes me to a completely different part of the text than I expect.

There are exceptions of course. For example, when I occasionally have to edit in Visual Studio I often get into trouble. I think it has the absolute worst default keybindings for an emacs user, and for whatever reason I generally avoid using it rather than customise its key bindings. An emacs user will generally type ctrl-x ctrl-s as a matter of habit, to save the current document. However in VS this keystroke combination will delete the current line – even if nothing is selected – and then save the document! I suspect that if I cared to use Visual Studio more often I might train myself to avoid this particular reflex…

In general though I would say that cases like this are quite rare, and mostly if I hit the wrong keystroke, my fingers just try the next in the list of likely suspects and my brain continues thinking about whatever it was thinking about.

I think that to some extent the inconsistency you’re seeing is the cost that must be paid to live and work in a hetrogeneous world. You’ve chosen a Windows desktop and a Linux server for good reasons which I’m not about to argue with. Each has unique strengths for the task, but the downside is some user interface inconsistency.

In summary: HTFU 🙂

Alastair,

When I asked the question on Super User, I added a couple of community wiki answers to questions myself, to let people vote on them – until I got told off by a moderator 🙁

They were basically “Just stick to a real OS, ya wuss” and “HTFU”, but not quite those words.

Maybe it shows something about the way my memory works, but it takes me a long time for me to learn these context switches. Hell, it has been over 6 months, and I still stuff up many, many times per hour when using the command line.

I remember at uni, in a lab sharing a pool of X-terms of many vintages. The nicer ones were quite rightly in high demand, but I would gladly have accepted the shittiest keyboard in the pile, if it just meant I didn’t have to change keyboards each session. (Until I started using some software that crashed a certain subset of X-term models, which caused me to become an Xterm nomad in search of an available working one.)

I find the wrong operation to be a constant source of surprising interruption. It is like a phone ringing on someone else’s desk. I should be able to ignore it, and plough on but it breaks me from my flow.

Yes, some commands have a quick recovery: CTRL-Right moves one character rather than one word, so I just press it more. If I use the mouse-wheel to scroll while in running less, I just need to scroll back to the bottom and remember the “b” command.

However, others are more drastic.

The more frustrating ones include:

• Having absolutely no recollection of how to undo in emacs. CTRL-_ you say? Is that even ASCII?
• Selecting text in PuTTY with the mouse and then killing the (long-running) current process with CTRL-C.
• Selecting text in a DOS window with the finished output of a test, which is paused before exiting, dismissing the window, and pasting the results into a text file, only to discover it is an old value in the clipboard, because I didn’t hit Enter.
• CTRL-Q invoking the help system rather than sending an X-Off. Oh wait, that was close to 20 years ago. Never mind.
• Moving to exactly the right spot in emacs to paste, hitting CTRL-V, and having it jump to the end of the file, losing my position.

The last one doesn’t sound bad, but I find it a little bewildering. I am reminded of a discussion with a driving instructor when I was learning to drive. “Without looking, what gear do you think you are in?” he asked. I had no idea. I mean, it was third or fourth, I think. And it was the correct gear. And shortly, I was going to have to change down for the corner. And when I reached for the stick, I would know what gear I was in, and where to move it, relative to its current position… But between gear changes, I had no reason to remember such a detail.

Similarly, I seem to get in a state during refactoring where I know I have one more paste to do to get it into a consistent state, then I can save and run the unit tests. When the cursor jumps to a random position, I am jolted. Where was I a moment ago? Will I be able to find it again?

In an unrelated gripe, I am using a Microsoft-brand wireless keyboard. This is my first and my last. I undergo the same bewilderment every time the battery starts to go, and keystrokes go missing.

That isn’t even mentioning how it finds capital letters tiring, and can’t do too many in a row. I now live in the state of NSw. (That wasn’t faked. when I hold the shift key down and type N S W, I get NSw nine times out of ten. Entering a password with many capital letters is a crap shoot.)

I’ll agree with you on the Microsoft wireless keyboard. My $200 wireless keyboard and mouse package is sitting on a shelf collecting dust, ever since I got sick of them. I use a Logitech G15 and G9x now. They both have cables, and work reliably with relatively little RAM usage.

My keyboard (G15) has 6 programmable buttons along the side, and they vary depending on the active window. One possible solution to your problems might be to stick to using G1 for undo, G2 for copy, G3 for paste, etc. It would send the correct keyboard shortcut for the active program, and you wouldn’t be constantly interrupted.

That PuTTY clipboard behaviour is standard Unix style. Emacs in windows will by default do the same too. That doesn’t make it good for a windows environment, unless you can make everything in windows do the same… You can avoid some of the issue if you use Cygwin SSH instead of PuTTY – that way, all your windows will respond to CMD window style mouse selection.

If you’re using cygwin already, then you’ve also eliminated the SSH to CMD command style dissonance (which slash do I use here? How do I use find here? Can I grep?). Unfortunately, this doesn’t fix any command line to windows app (or to web app!) dissonance (where’s my back button? Where’s my command line undo redo?).

Regarding remapping keys in Emacs: it’d be excellent if the CUA key bindings of EmacsW32 were available in the standard GnuEmacs build, so it was easy to turn on under Linux. That would solve a lot of the cut/copy/paste/undo basic issues.

For bash (and other readline based applications), is there a patch to make it CUA compatible too? There’d have to be something to remap the keybinding for SIGTERM to something you’d be used to… CTRL-D? Alt-F4?

Another issue that can crop up is using bash CTRL-K to cut from the SSH window, then trying to paste that text into a CMD or a windows app (or vice versa). Clearly, that’s not going to work unless you’ve got a distributed clipboard going. Making the same handle table content and file transfers too would be a godsend.

Another one I’m frequently caught by is the fact that the command line apps do rectangle select (trimming whitespace from the start of the first line and end of the last line only), rather than normal text select (whitespace intact). It’d be even better if you could make a command line that handled mouse wheel and scrollbar events nicely.

The fact that selecting text in CMD (and Cygwin SSH) pauses output and execution can also be very confusing (why is this job taking so long?). But the feature is so handy, I’ve no idea how I’d replace it. Scroll Lock to the rescue?

Oh, and CTRL-Q/CTRL-S are still issues with many environments. The death of software flow control has been greatly exaggerated.

I don’t know why I didn’t remember this when writing the earlier comment, but there is one little bit of keyboard-related inconsistency that trips me up fairly infrequently but it is an absolute killer each time.

Like most emacs users – and RSI-adverse users in general – I have my capslock key remapped to be a third control key. This prime bit of keyboard real-estate is otherwise completely wasted, and it’s just so much more comfortable to use as a control key than the default control key placement. And fortunately on Mac and Linux (well GNOME anyway), this setting is just a checkbox away. On Windows though it requires admin access and a reboot which is just not feasible on shared machines. So I often find myself doing demos/presentations/whatever and continually TRIPPING CAPSLOCK INADVERTENTLY. Does my head in. Does anyone know of a good user-mode solution?

I wonder if this would provide a way to distinguish between ctrl-C as copy command and ctrl-C as SIGINT? Map one of them to a less commonly used modifier key, such as capslock? Or better still maybe the *other* control key – assuming you are like me and generally only use the control key on the left hand side of the keyboard. Might be a good feature for PuTTY?

On emacs: yes the standard undo keybinding is ctrl-_. No it doesn’t haven’t to be an ASCII character, and why would you even want it to be so? This is pretty trivially remapped to ctrl-z but the problem is that undo has different behaviour on emacs than just about every other application. There’s no “redo” command, instead you have to undo your undo…

Richard: CUA mode is definitely part of the standard Gnu Emacs build. Activating it is easy as going to the Options menu.

Rectangle selection is prettymuch confined to the Windows terminal from what I remember. I don’t think PuTTY does it, neither Terminal.app on the Mac nor gnome-terminal on GNOME do anything like it. Same for the selection-pauses-output behaviour you mention; most other terminals allow the application to continue running.

gnome-terminal also seems to pass the scroll wheel events to less. Which is nice of it.

On Windows though [remapping the caps lock] requires admin access and a reboot which is just not feasible on shared machines. So I often find myself doing demos/presentations/whatever and continually TRIPPING CAPSLOCK INADVERTENTLY. Does my head in. Does anyone know of a good user-mode solution?

If you haven’t already tried it, maybe give AutoHotkey a go.

I had a slightly different problem: multiple Windows keyboards. My solution was to turn on Toggle Keys.

(Look under the Ease of Access options in the Control Panel, or just hold the Num Lock button down for 5 seconds.)

It doesn’t change the behaviour of the CAPS LOCK, but makes an annoying beep, reminiscent of a operant conditioning chamber (a.k.a. Skinner box), every time you hit the Caps Lock, Scroll Lock or Num Lock keys.

Alastair, the issue with CTRL-_ got confused earlier on. Let me try to explain.

All the EMACS commands have to map to ASCII characters, so they can be sent by a an old-fashioned green-screen dumb terminal. (Why is the meta-key = ALT on some machines and ESC on others? Because ALT is generally considered preferable, but can’t be transmitted via ASCII, forcing the ESC key to be used instead on dumb-terminals.)

When you said that CTRL-_ was the shortcut for a key, I expressed surprise that there was an ASCII code for that, because it didn’t ring any bells. (Clearly bad memory, because I must have used in many, many times.) However, I concluded that there must be such an ASCII character, or that shortcut wouldn’t work.

And, indeed, I checked and found there is: ASCII 31.

Only keys that are processed by the terminal driver have to be ASCII. Those are the ones shown by ‘stty -a’ and include stuff like interrupt and suspend. Other keys and key combinations send keycodes consisting of multiple ASCII characters starting with the ESC character, e.g. \e[D for ArrowLeft and \e[1;5D for Ctrl+ArrowLeft. PuTTY doesn’t support such modifier combinations, but xterm and xterm-compatible terminals such as mintty do. Xterm’s ‘modifyOtherKeys’ mode makes even more key combinations available as escape sequences.

Btw, you might want to have a look at the PowerShell ISE, which does what you want for “DOS”.

Another thought: one feature that would be a challenge to implement in a terminal-side line editor is tab completion, because only the shell on the remote system has all the information needed for that.

Andy,

Re: ASCII combinations

Agreed. In the world of xterms, you can start adding non-ASCII keycodes, but this isn’t the world I am working in.

Re: PowerShell ISE

Thanks for the suggestion! I will have to have a closer look at that. I dismissed PowerShell in general, as providing a more powerful language but not a more powerful GUI. PowerShell ISE seems to undercut that claim.

Re: Tab Completion

Yes, I touched on that difficulty in the penultimate paragraph.

You might want to, behind the scenes, be sending some variation of the commands through immediately – e.g. when they hit cut, you might send a corresponding number of Dels, to keep the two lines in sync.

Alternatively, when they hit tab, you might want to clear the current command line on the server and send the whole line so far.

Or use sftp in the background to emulate the feature locally.

Or just live without.

You are willing to go without Tab completion in order to get consistency on other shortcuts?

I don’t understand how that works. Maybe that’s because I don’t have to deal with three different kinds of terminal window on the same machine, and I would understand if I did.

But really, if you ask me, if something is painful enough to elevate the loss of Tab completion to a legitimate trade-off, then something is drastically wrong.

Hi Julian, I have the same problem and still no solution. I started to develop a Java application but stopped because I lack time.
Ebe