Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: zkbd on OS X

Comments inline.

Daniel Serodio wrote:
Bart Schaefer wrote:
On Jan 11,  7:53pm, Daniel Serodio (lists) wrote:
} Bart Schaefer wrote:
}>  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?
I'd go with the second option, as it would be more consistent with the behaviour on Linux, but since I don't use remote X I don't really understand the pros and cons of each for remote X.
Since no one else chimed in, would you agree to change this zkbd behaviour? I prefer the second option but IMHO, any of these is better then the current situation (ie. ${DISPLAY:-$VENDOR-$OSTYPE})
}> 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.

I do something similar and deal with this kind of thing in this way:

(1) _Don't_ source-control $HOME/.z* files; instead have a $ZDOTDIR
that is source controlled (I use $HOME/.zsh/) and have $HOME/.zshenv
do nothing but export ZDOTDIR and then "source $ZDOTDIR/.zshenv"

(2) Have a subdirectory $ZDOTDIR/local/ which contains symlinks from
standard names for assorted files (such as zkbd bindings) to the actual
files used for each host (this could be somewhere outside ZDOTDIR if it
creates source control conflicts)

(3) Create a little setup script that populates local/ the first time
the ZDOTDIR source tree is checked out on a new host (also creates the
$HOME/.zshenv in my case)

(4) $ZDOTDIR/.zshrc et al. always "source $ZDOTDIR/local/something"
for any config that isn't completely portable.
Thanks for the help, I'll give it a try and see how it compares with my current setup. Currently, my .zshrc has some if statements testing for $OS and hostname for dealing with non-portable stuff.
I've found this scheme too complicated and ended never implementing it. My current setup is working fine, except for this zkbd problem. The change suggested above would fix it for my use case.

} 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)

See "Opinions?" question above.
Sorry I'd skipped this part. I've replied now.
Daniel Serodio

Messages sorted by: Reverse Date, Date, Thread, Author