From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29489 invoked by alias); 11 Jan 2012 22:00:28 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 16728 Received: (qmail 14370 invoked from network); 11 Jan 2012 22:00:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: pass (ns1.primenet.com.au: SPF record at spf.mandic.com.br designates 200.225.81.133 as permitted sender) Message-ID: <4F0E04D7.9090207@mandic.com.br> Date: Wed, 11 Jan 2012 19:53:27 -0200 From: "Daniel Serodio (lists)" User-Agent: Postbox 3.0.2 (Macintosh/20111203) MIME-Version: 1.0 To: zsh-users@zsh.org Subject: Re: zkbd on OS X References: <4F01FE34.1020308@mandic.com.br> <20120103101643.GA1879@redoubt.spodhuis.org> <4F02F74F.1050004@mandic.com.br> <120104200225.ZM13518@torch.brasslantern.com> In-Reply-To: <120104200225.ZM13518@torch.brasslantern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sorry about the delay, replies inline: Bart Schaefer wrote: > [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 > } 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. Makes perfect sense, thanks for the explanation. > 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? My actual problems are: 1) I use Subversion to store my config files, which I share between my home and work computers. $DISPLAY is different between them, but I'd like the keymappings to be the same. 2) When zkbd finishes executing (eg. because I've changed terminal emulators), I get an error (which zkbd neither tries to prevent nor test for): mv: rename /Users/dserodio/.zkbd/xterm.tmp to /Users/dserodio/.zkbd/xterm-/tmp/launch-dC1Rir/org.x:0: No such file or directory zkbd should test for the existence of the the destination to mv before moving the temp file. Regards, Daniel Serodio