Re: [dev] my compatible ideas: vim like mapping for any tools, C scripts, vi clone

From: anonymous <>
Date: Sun, 16 May 2010 03:46:28 +0400

On Fri, May 14, 2010 at 08:02:57PM +0000, Bjartur Thorlacius wrote:
> > 1. good tools should have a way to define easily keyboard shortcuts.
> True. It's quite irritating that some tools use the arrow keys for scrolling,
> others use hjkl (which doesn't make sense on all keyboards) and one
> has to configure each seperately to use the keybindings you like.
> > 1.1. Preferably good tools should have at least one predefined set of
> > shortcuts that is compatible with vimi
> I don't think imitiating vim is a good idea. When in a windowing system
> at least it would be nice if apps grabbed all keys they wanted
> (e.g. text boxes could grab all printing characters) but all other keys would
> bubble up (as I think they already do in X) but if they reach the root window
> they could be rethrown in the original window, but as some other user-defined
> keys. For example if one presses <j> when focused on an image
> inside web page, it would bubble through e.g. xloadimage, surf, tabbed, root
> and then root would look it up and see that <j> should be rethrown as
> <down> which would bubble through xloadimage to surf which would scroll
> down. But I doubt it's possible in X (or does XEmbed allow for this?).

Mostly agree, but chaning X is nearly impossible. Currently it is
possible to use modifiers for this. Alt (and A-C, A-S-C, A-S) for
window manager, Ctrl (and S-C) for special actions in programs,
everything else (with Shift or not) for typing. If we don't have
plugins, embedded windows and other things like that, there are only
two classes:

1. Window manager
2. Windows.

So it is easy to determine who should react to keypress:

1. If Alt is pressed then it is for window manager.
2. If Ctrl is pressed then it is for focused window.
3. In other case it is for focused widget (letters types text, return presses buttons etc.).

Super and other modifiers are for for user, he can use it as Compose
key, for switching layout etc.

This behaviour is compatible with unix keybindings
( Most (all?) suckless tools follow these
rules so there are no problems. Maybe they should be documented

What I don't like in current suckless programs is hjkl keybindings.
They are designed only for one layout. I think it is better to use
some kind of mnemonics like ^f for forward, ^b for backward, ^n for
next, ^p for previous etc. Something like this is used in Lynx, Dillo
(f for forward), most GNU programs (readline, emacs for example),
ratpoison, screen, tmux and many others. These keybindings are
independent from layout so you can use Dvorak layout or any other
layout that sucks less than current default created for typewriters
(which AFAIK was created to slow down typists, but I am not really
sure if it is not a myth; anyway it was not carefully designed to make
typing faster).
Received on Sat May 15 2010 - 23:46:28 UTC

This archive was generated by hypermail 2.2.0 : Sat May 15 2010 - 23:48:01 UTC