Re: zkbd on OS X

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

[Was away on travel for a few days.]

On Jan 3, 12:13pm, Mikael Magnusson wrote:
} Subject: Re: zkbd on OS X
}
} On 3 January 2012 11:16, Phil Pennock
} <zsh-workers+phil.pennock@xxxxxxxxxxxx> wrote:
} > On 2012-01-02 at 16:57 -0200, Daniel Serodio (lists) wrote:
} >> Since 4.3.5 or so[1], zkbd uses ${DISPLAY:-$VENDOR-$OSTYPE} instead of
} >
} >> Has anyone had this problem before? Am I doing something wrong?
} >
} > You're not doing anything wrong; it was an Xorg/XFree86 assumption
} > about the value of $DISPLAY, ":0", ":0.0", "hostname:0" or the like.

Indeed, at the time there really was nothing else to assume.

} > ("hostname:displaynumber.screennumber"). I think that this might be
} > an X11 requirement ...

It's definitely documented that way for X11/XFree86/Xorg.

} > How about:
} > ----------------------------8< cut here >8------------------------------
} > if [[ -z "$DISPLAY" || $DISPLAY == */* ]]; then
} >  termID="$VENDOR-$OSTYPE"
} > else
} >  termID="$DISPLAY"
} > fi
} > ----------------------------8< cut here >8------------------------------

I'd probably go with one of:

local termID=${${DISPLAY%%*/*}:-$VENDOR-$OSTYPE}

or

local termID=${${DISPLAY:t}:-$VENDOR-$OSTYPE}

depending on whether it's better to ignore DISPLAY when it contains a
slash, or to use the part of the file name that corresponds to the X11
display name.  Opinions?

} Why does zkbd use $DISPLAY at all?

The problem with using only $TERM-$VENDOR-$OSTYPE is that with remote
display, you may be either (a) running $TERM on host Q but displaying
on host P, or (b) running $TERM on host Q but with the shell in ssh on
host P.  In either of these cases $VENDOR-$OSTYPE will refer to the
local machine where zsh has started, but the keybindings you want are
for the keyboard attached to the remote machine.

The only obvious way to identify the remote keyboard is to use $DISPLAY.

} Why would I be getting different sequences for urxvt in :1 than in :0?

:0 is presumably the console with a physically attached keyboard, whereas
:1 is most likely a VNC or NX device with a virtual keyboard.  Once again
the keystrokes may be different; e.g., DEL on the physical keyboard might
send ^? but on the virtual keyboard it sends ^[[3~ .  So you need separate
zkbd files for those cases.

} Or have to set everything up separately when the display number changes?

The assumption is that the display number is pretty closely tied to the
source from which that display originates.  That assumption isn't always
going to be correct, but zkbd can't cover all possible cases; the user
is assumed to be intelligent enough to rename some files and change the
corresponding "source" commands if she has special cases.

On Jan 3, 10:40am, Daniel Serodio (lists) wrote:
}
} Works fine for me, but this fix has to me made not only where zkbd moves 
} the temporary file but also when sourceing it in ~/.zshrc

Well, yes obviously.

} The corresponding lines in .zshrc look somewhat like a kludge.

Welcome to the world of terminal/keyboard handling.  There's very little
that is NOT a kludge, given the number of possible different combinations
of physical and virtual terminals and emulators and types of keyboards.
Setting up zsh for my semi-qwerty smartphone keypad was a real joy [not],
but at least it was possible.

} I was wondering the same thing as Mikael: why does zsh use $DISPLAY in 
} the first place? IMHO, it doesn't make sense to have different 
} keymapping in :1 then in :0, and having to setup the keyboard when 
} $DISPLAY changes.

What circumstances are you dealing with where $DISPLAY changes without
some other part of the environment also changing?