How to make a function use inbuilt completions of another command?

How to make a function use inbuilt completions of another command?

[Keerthan jai.c]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

I have a function for creating or attaching to an existing tmux session. Is
there a simple way to make it use the competions for 'tmux attach -t' ?

'compdef __tmux-sessions funcname' works only if _tmux has been loaded by
triggering a tab completion on 'tmux'

-- 
have a nice day
-jck

Re: How to make a function use inbuilt completions of another command?

[Bart Schaefer]

On Feb 3, 11:09pm, Keerthan jai.c wrote:
} 
} 'compdef __tmux-sessions funcname' works only if _tmux has been loaded by
} triggering a tab completion on 'tmux'

Ideally, the _tmux completer would offer to interpret the $service
parameter and jump to the appropriate subsection.  If that were done,
you could write something similar to:

    compdef _tmux funcname=sessions

Since that's not yet possible (few completion function writers know
about the command=service extension), you're going to have to do
something like this:

    _tmux 2>/dev/null	# force _tmux to be loaded and define helpers
    compdef __tmux-sessions funcname

It should be harmless to do this; after defining the helpers for all of
its subcommands, _tmux will simply fail because it is not being called
in completion context (hence 2>/dev/null to hide the warning).

Re: How to make a function use inbuilt completions of another command?

[Frank Terbeck]

Bart Schaefer wrote:
> On Feb 3, 11:09pm, Keerthan jai.c wrote:
> } 'compdef __tmux-sessions funcname' works only if _tmux has been loaded by
> } triggering a tab completion on 'tmux'
>
> Ideally, the _tmux completer would offer to interpret the $service
> parameter and jump to the appropriate subsection.  If that were done,
> you could write something similar to:
>
>     compdef _tmux funcname=sessions
>
> Since that's not yet possible (few completion function writers know

I wrote the _tmux completion and indeed don't have a clue about said
extension. Where can I take a closer look at it? Which completion should
I look at for guidance?

> about the command=service extension), you're going to have to do
> something like this:
>
>     _tmux 2>/dev/null	# force _tmux to be loaded and define helpers
>     compdef __tmux-sessions funcname
>
> It should be harmless to do this; after defining the helpers for all of
> its subcommands, _tmux will simply fail because it is not being called
> in completion context (hence 2>/dev/null to hide the warning).

I got a function myself, that I use for creating/attaching to sessions,
that uses the __tmux-sessions function, too. I do it like this (borrowed
the idea from _complete-debug; the anonymous function makes sure
everything from _tmux is available when _ta is called for the first
time):

#+BEGIN_SRC shell-script
#compdef ta

() {
    compadd() { return 1; }
    zstyle() { return 1; }
    trap 'unfunction compadd zstyle' EXIT INT
    _tmux
    unfunction compadd zstyle
    trap - EXIT INT
}

function _ta() {
    local -a arguments
    arguments=(
        '-d[detach other clients when attaching to existing sessions]'
        '-x[do not `exec'\'' off to tmux; just call it]'
        '*::existing tmux sessions:__tmux-sessions'
    )
    _arguments -s $arguments
}

_ta "$@"
#+END_SRC

...which works fine for me.


Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: How to make a function use inbuilt completions of another command?

[Bart Schaefer]

On Feb 4,  5:10pm, Frank Terbeck wrote:
}
} >     compdef _tmux funcname=sessions
} 
} I wrote the _tmux completion and indeed don't have a clue about said
} extension. Where can I take a closer look at it? Which completion should
} I look at for guidance?

Any of these should be good:

    _pkgtool
    _git
    _urpmi
    _uml 

Or just fgrep Completion/**/*(.) for references to '$service' ...

Re: How to make a function use inbuilt completions of another command?

[Keerthan jai.c]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

It turns out that tmux has an inbuilt way of supporting this behaviour.
The -A flag makes new-session behave like attach-session if session-name
already exists.
I have modified the completion script to support this:
--- /usr/share/zsh/functions/Completion/Unix/_tmux      2014-01-06
05:59:47.000000000 -0500
+++ _tmux       2014-07-20 20:50:01.994939784 -0400
@@ -573,12 +573,13 @@
     local -a args
     args=(
         '-d[do not attach new session to current terminal]'
+        '-A[attach to existing session if it already exists]'
         '-n[name the initial window]:window name'
-        '-s[name the session]:session name'
+        '-s[name the session]:session name:__tmux-sessions'
         '-t[specify target session]:sessions:__tmux-sessions'
         '*:: :_command'
     )
-    _arguments ${args}
+    _arguments -s ${args}
 }

 function _tmux-new-window() {



On Tue, Feb 4, 2014 at 1:08 PM, Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On Feb 4,  5:10pm, Frank Terbeck wrote:
> }
> } >     compdef _tmux funcname=sessions
> }
> } I wrote the _tmux completion and indeed don't have a clue about said
> } extension. Where can I take a closer look at it? Which completion should
> } I look at for guidance?
>
> Any of these should be good:
>
>     _pkgtool
>     _git
>     _urpmi
>     _uml
>
> Or just fgrep Completion/**/*(.) for references to '$service' ...
>



-- 
have a nice day
-jck

Access command that called a function within the function.

[Ray Andrews]

Is there any way for a function to access the exact command line that 
called it?  This sort of thing does not work:

   function whats-my-line () { history; }

... the last line in history is the command previous to the one that  
calls whats-my-line. I have a lot of functions  that need to know the 
literal line that called them. So far, the best I can do is this:

   alias whats-my-line='set -F; _whats-my-line'
   function _whats-my-line () {__whats-my-line $@; set +F; }

   function __whats-my-line ()
  {
... and then, to expand wildcards and other stuff for processing inside 
the function:

     set +F
     expanded-line=`eval "${@}"`
     set -F
      ....
   }

... it all works, but it's so much trouble. If I could just grab the 
line that *will* be put into history once the function quits *before* it 
quits, that would do the trick. Can it be done? One might dream of some 
variable that contains the line about to be appended to history once the 
function returns. It must be stored somewhere.

In a similar frustration, I'm trying to make my functions accept piping. 
This sort of thing works:

   function pipe-grabber ()
   {
     input-from-pipe=`cat`
     echo "Here's what was piped in: \n$input-from-pipe"
   }

$ echo "Let me not, to the marriage of true minds admit impediments" | 
pipe-grabber

... works fine.

... but if you have 'set -F' active before pipe-grabber is called, the 
stdin is blocked and nothing gets grabbed :-(  Why should 'set -F' be so 
ruthless?

Re: Access command that called a function within the function.

[Bart Schaefer]

On Feb 4,  8:25am, Ray Andrews wrote:
> Subject: Access command that called a function within the function.
>
> I have a lot of functions  that need to know the 
> literal line that called them.

A lot?  Whatever for?

> Is there any way for a function to access the exact command line that 
> called it? ... One might dream of some 
> variable that contains the line about to be appended to history once the 
> function returns.

If you're only worried about knowing the line that was entered at the
interactive prompt, which seems to be the case because you are asking
about the history:  Use a preexec hook to copy one of the arguments to
a parameter declared with typeset -g, and then reference the parameter.
The value of $1 during preexec is the closest you'll get to the string
that is going to be written to the history.  The value of $3 might be
more useful depending on what you want to do with it.

If you need this from something like a script, setopt DEBUG_BEFORE_CMD
and define the TRAPDEBUG function to similarly copy $ZSH_DEBUG_CMD.
It is farther from the original text but should suffice.

> So far, the best I can do is this:
> 
>    alias whats-my-line='set -F; _whats-my-line'
>    function _whats-my-line () {__whats-my-line $@; set +F; }

This is what the "noglob" precommand modifier is for:

    function whats-my-line() {
       expanded_line=$(eval "$@")
       # ...
    }
    alias whats-my-line='noglob \whats-my-line'

Note that you need to define the function before the alias if you are
going to name them both the same like that.

However, that won't prevent $(command) or $parameter references from
expanding, so I'm still not sure what you're trying to accomplish.

> In a similar frustration, I'm trying to make my functions accept piping. 
> This sort of thing works:
> 
>    function pipe-grabber ()
>    {
>      input-from-pipe=`cat`
>      echo "Here's what was piped in: \n$input-from-pipe"
>    }

You keep writing parameter names with hyphens in them, but that isn't
valid syntax ...

> ... but if you have 'set -F' active before pipe-grabber is called, the 
> stdin is blocked and nothing gets grabbed :-(  Why should 'set -F' be so 
> ruthless?

If you mean that you did

    alias pipe-grabber='set -F; _pipe-grabber'

and then did

    echo "Shakespeare wrote a lot of sonnets" | pipe-grabber

please consider that what you have just accomplished is

    echo "Shakespeare wrote a lot of sonnets" | set -F; _pipe-grabber

and let us know if you are still confused.

Re: Access command that called a function within the function.

[Ray Andrews]

On 04/02/14 07:46 PM, Bart Schaefer wrote:

Bart,

Thanks for the reply. You gave me some ideas that are still beyond my 
knowledge; I'll play with them and get back.  For now:
>
> I have a lot of functions  that need to know the
> literal line that called them.
> A lot?  Whatever for?
I make wrappers for just about all the commands I use constantly, the 
idea being to customize things to my taste, and to regularize the common 
switches.  But I like the wrapper to push the 'real' command to history 
and to do that, it  must be able to grab the command line unexpanded.  
Eg. my wrapper around 'ls' is 'l' thus:

pts/3 hp root /root/.opera $ l *

   EXECUTING: ls --time-style=+%F//%T -AGhrFl --group-directories-first 
--color=always  *

   Sorting Backwards by Name:

drwxr-xr-x  2 root 4.0K 2014-02-02//05:54:28 webserver/
drwxr-xr-x  7 root 4.0K 2014-02-05//08:49:15 vps/
...

The function pushes the full 'ls ....' line to history for recall, and 
if there are wildcards in the command line, I must capture them 
unexpanded, but actually *execute* the command fully  expanded of 
course. As I said, I have it working fine, but it's so laborious. If the 
function could just grab it's own command line literally  things would 
be simpler. And I'd not have to fool around with 'set -F'.



>> You keep writing parameter names with hyphens in them, but that isn't
>> valid syntax ...
Pardon, I just made those names up for clarity.

I'll experiment with your ideas.

Re: Access command that called a function within the function.

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 1515 bytes --]

On Wed, Feb 5, 2014 at 10:33 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:

> I make wrappers for just about all the commands I use constantly, the idea
> being to customize things to my taste, and to regularize the common
> switches.  But I like the wrapper to push the 'real' command to history and
> to do that, it  must be able to grab the command line unexpanded.


If you really want it entirely unexpanded (except for history, there's no
way to head that off), then a preexec function is the way to go; you won't
even need to mess with noglob, the literal input string is right there in
$1.

But ...

The function pushes the full 'ls ....' line to history for recall, and if
> there are wildcards in the command line, I must capture them unexpanded


There seems to be a basic flaw in this plan, which is that if you use one
or more of these wrappers in a compound command such as a pipeline or
(worse) a loop, you're going to get separate history entries written by
each wrapper, which won't reflect the surrounding structure.  E.g. with
your "l" command, if you wrote

    for directory in *(/); do l $directory/*(.); done

You'd get one new history entry for every expanded "ls" command (and maybe
*not* one of the "for" loop itself, depending on how you implement it).  Is
that really what you intend?

Further the value of $1 in preexec is going to be the whole "for" loop,
which won't be what you need inside each individual command.  Which brings
us back to TRAPDEBUG and $ZSH_DEBUG_CMD and noglob.

Re: Access command that called a function within the function.

[Ray Andrews]

On 05/02/14 12:21 PM, Bart Schaefer wrote:


Bart,

> The function pushes the full 'ls ....' line to history for recall, and if
>> there are wildcards in the command line, I must capture them unexpanded
>
> There seems to be a basic flaw in this plan, which is that if you use one
> or more of these wrappers in a compound command such as a pipeline or
> (worse) a loop, you're going to get separate history entries written by
> each wrapper, which won't reflect the surrounding structure.  E.g. with
> your "l" command, if you wrote
>
>      for directory in *(/); do l $directory/*(.); done
>
> You'd get one new history entry for every expanded "ls" command (and maybe
> *not* one of the "for" loop itself, depending on how you implement it).  Is
> that really what you intend?
I turn this echo to history thing on with a switch to the command, so 
it's only there when I want to, say, pull back a complicated 'find' 
command for editing. Normally the entire system is turned off. Besides, 
I'm only just beginning to contemplate using my wrappers in pipes. They 
are only intended (so far) as simple shortcuts with easy to remember 
switches.
> Further the value of $1 in preexec is going to be the whole "for" loop,
> which won't be what you need inside each individual command.  Which brings
> us back to TRAPDEBUG and $ZSH_DEBUG_CMD and noglob.
>
Well all that is still way over my head. One thing at a time ;-) I'll 
get to that stuff sooner or  latter.  Thanks again.

key bindings table?

[Ray Andrews]

Gentlemen:

Do we have a key bindings table that translates all the various ways of 
referring to a key press?
The reason I ask is that I'd like to assign some keybindings and I have 
no way of knowing how to refer to them (unless I'm going to steal one 
that's already defined).

For example, in 'zbindkey' we have this sort of thing:

   [[ "$terminfo[kend]"  == "^[O"* ]] && bindkey -M emacs 
"${terminfo[kend]/O/[}"  end-of-line

... and I can guess that 'kend' means that this refers to the 'End' key.

Cross checking with " $ bindkey " I get this:

   "^E" end-of-line
"^[OF" end-of-line
"^[[F" end-of-line

... so I trust that one of those lines refers to the 'End' key. Which one?

and we also have this:

   bindkey "\e[A" history-beginning-search-backward

... Now, I happen to know that that's the 'Up Arrow' key, but how could 
I find out if I didn't know?

   $ bindkey (at CLI)

... gives us a different language for the same key:

   "^[[A" history-beginning-search-backward

... but at least now I know that  " ^[[A " in bindkey-at-CLI speak is 
the same thing as " \e[A " in bindkey-in-zbindkey speak. That's easy.  
In the old days in DOS, the 'Up Arrow'  was " 0;72 " -- you could find 
the scan code of every legal keystroke and there was only the one language.

Is there a table? Or some other way of being able to pick a keystroke 
and know how to refer to it in " terminfo[] " ... in " 
bindkey-in-zbindkey " ... in  "bindkey-at-CLI " and/or in whatever other 
languages there may happen to be? Again, in DOS there was the 'scancode' 
program -- type a keystroke, and you got the scancode. It was sinfully easy.

Re: key bindings table?

[Bart Schaefer]

On Feb 22, 10:35am, Ray Andrews wrote:
}
} Do we have a key bindings table that translates all the various ways of 
} referring to a key press?

You can generate one for your terminal/keyboard combo by running the
"zkbd" utility.  As you noticed, $terminfo (from zsh/terminfo module)
sometimes has useful definitions but it's more interested in what the
terminal understands for cursor motion than what the keyboard sends
for input.

There's documentation for zkbd in the manual.  (If someone feels like
extending zkbd to cover the keypad, jump right in.)

} For example, in 'zbindkey' we have this sort of thing:
} 
}    [[ "$terminfo[kend]"  == "^[O"* ]] &&
}    bindkey -M emacs "${terminfo[kend]/O/[}"  end-of-line

I'm not sure which "zbindkey" this refers to.  It's not something that
is distributed with zsh.

} "^E" end-of-line
} "^[OF" end-of-line
} "^[[F" end-of-line
} 
} ... so I trust that one of those lines refers to the 'End' key. Which one?

Two of them do, in this case.  Keyboards can be in two states, usually
called "normal mode" and "keypad transmit mode" and the End key sends
different sequences depending on which mode is in effect.  ^E is the
usual emacs end-of-line binding, the other two are End key values.

} Is there a table? Or some other way of being able to pick a keystroke 
} and know how to refer to it in " terminfo[] " ... in " 
} bindkey-in-zbindkey " ... in  "bindkey-at-CLI " and/or in whatever other 
} languages there may happen to be?

There are too many interchangable combinations of keyboards and terminals
(and operating systems) to create a table that covers them all.  The zkbd
utility covers the most common ones (plus some from old Sun keyboards
that are a lot less common now) but far from everything.  The manual for
terminfo (not zsh's manual for the zsh/terminfo module) usually includes
a table of the most standard names for display actions, which as mentioned
covers some key-driven cursor motions, but also covers all sorts of other
display actions that have nothing to do with the keyboard.

On top of this you have terminal emulators which often have the ability
to redefine all of the keys.  Graphical interfaces receive "scan codes"
based on the keyboard layout, but CLI programs don't see them, they can
only use the character sequences that the emulator generates based on the
scan code it receives.

DOS was simple because it was Microsoft and IBM everywhere, and it all
used the raw scan codes.

-- 
Barton E. Schaefer

Re: key bindings table?

[Ray Andrews]

On 02/23/2014 03:40 PM, Bart Schaefer wrote:

Bart:
> On Feb 22, 10:35am, Ray Andrews wrote:
> }
> } Do we have a key bindings table that translates all the various ways of
> } referring to a key press?
>
> You can generate one for your terminal/keyboard combo by running the
> "zkbd" utility.  As you noticed, $terminfo (from zsh/terminfo module)
> sometimes has useful definitions but it's more interested in what the
> terminal understands for cursor motion than what the keyboard sends
> for input.
Yeah, I was put onto that. The output is easy to understand, but also 
quite limited. If it coughed up all the  possible legal key combos, that 
would be the thing.  I've had some satisfaction from 'dumpkeys' and 
'showkey' however.
> }
> }    [[ "$terminfo[kend]"  == "^[O"* ]] &&
> }    bindkey -M emacs "${terminfo[kend]/O/[}"  end-of-line
>
> I'm not sure which "zbindkey" this refers to.  It's not something that
> is distributed with zsh.
No? I wonder where it came from then, maybe I made it myself, to cut KB 
stuff out of zshrc. Anyway those '$terminfo' lines are certainly not my 
making since I don't know how they work ;-)

> Two of them do, in this case.  Keyboards can be in two states, usually
> called "normal mode" and "keypad transmit mode" and the End key sends
> different sequences depending on which mode is in effect.  ^E is the
> usual emacs end-of-line binding, the other two are End key values.
Yikes, that's a new concept for me.
> There are too many interchangable combinations of keyboards and terminals
> (and operating systems) to create a table that covers them all.  The zkbd
> ...

Ok then, I'll make do. I suppose one might wish for a 'complete' output from zkbd, short of that, I can use 'showkey' to check out the codes for a key, and then 'bindkey' to see if/what that key is doing at the moment and 'zkbd' for a nice if incomplete listing of the important keys.


Thanks as always.

completion fails if dir referenced via variable.

[Ray Andrews]

When I open an xterm it automatically assigns its current directory to a 
variable, eg. the current directory in 'pts/1' will always be '$t1'. I 
use this shorthand for moving stuff. Say I'm in xterm 'pts/2' and I want 
to  copy something from the current dir in 'pts/1', I just  " cp 
$t1/filename .' " Works fine. However completion does not work. Using 
that last example, if I type " cp $t1/filen [tab] " what happens is that 
" $t1 " expands just fine followed by " filen ". On the line below it 
says: " Completing all expansions ", but nothing happens. If I press 
[tab] again the expansion of " $t1 " collapses and on the next line it 
says: " Completing original " from then on [tab] alternates between 
those two states. Can I overcome this? It seems strange since the 
variable expands just fine, so completion 'knows' what it's looking for 
as if I typed the full path by hand (and if I do, type it by hand, 
completion works fine, of course).  I'm betting there's a setopt for this.

Re: completion fails if dir referenced via variable.

[Bart Schaefer]

On Feb 25,  7:21am, Ray Andrews wrote:
}
} if I type " cp $t1/filen [tab] " what happens is that 
} " $t1 " expands just fine followed by " filen ". On the line below it 
} says: " Completing all expansions ", but nothing happens.

This is the _expand completer at work.  It detects that there is a
variable that could be expanded, expands it, and returns 0, which
tells compsys that it doesn't need to try any other completions
until you have accepted this expansion.

You could try swapping the order of your completer zstyle from
_expand _complete to _compete _expand, or (if you have the default
bindings) you may be able to press ^Xn (_next_tags) to skip over
_expand and try _complete.

Re: completion fails if dir referenced via variable.

[Ray Andrews]

On 02/25/2014 09:46 AM, Bart Schaefer wrote:
> On Feb 25,  7:21am, Ray Andrews wrote:
> }
> } if I type " cp $t1/filen [tab] " what happens is that
> } " $t1 " expands just fine followed by " filen ". On the line below it
> } says: " Completing all expansions ", but nothing happens.
>
> This is the _expand completer at work.  It detects that there is a
> variable that could be expanded, expands it, and returns 0, which
> tells compsys that it doesn't need to try any other completions
> until you have accepted this expansion.
>
> You could try swapping the order of your completer zstyle from
> _expand _complete to _compete _expand, or (if you have the default
> bindings) you may be able to press ^Xn (_next_tags) to skip over
> _expand and try _complete.
I tried the above and a few other things, but nothing improves the 
situation. So far the most useful line is:

zstyle ':completion:*' completer _expand _complete _correct _approximate

It seems intuitive that one should be able to have more than one 
expansion and/or completion per line, not just one, does it not? Why the 
artificial limitation? As a nasty work around, I can hit TAB once, which 
expands the variable, store the line to history, recall the line from 
history, and hit TAB again which completes the filename, but that seems 
like a whole lot of trouble.

Tell compsys it can't go home until all it's work is done ;-)

... mind, you say "until you have accepted" ... can I 'accept' one 
expansion/completion and have it go on to the next?


>

Re: completion fails if dir referenced via variable.

[Bart Schaefer]

On Feb 25, 10:25am, Ray Andrews wrote:
}
} It seems intuitive that one should be able to have more than one 
} expansion and/or completion per line, not just one, does it not? Why the 
} artificial limitation?

It's not a limitation, it's that way so that two tabs in a row enters
menu completion on the same set of answers.  You have to do something
(anything, really) in between the two presses of tab to say "yeah, I
am done with the first completion, let's start a new one using what's
on the line now".

} As a nasty work around, I can hit TAB once, which 
} expands the variable, store the line to history, recall the line from 
} history, and hit TAB again which completes the filename

You could also type one more character of the filename, type space and
then backspace, etc. -- anything so that you aren't invoking the same
completion widget twice consecutively, which has its own special meaning.

Re: completion fails if dir referenced via variable.

[Ray Andrews]

On 02/25/2014 11:21 AM, Bart Schaefer wrote:
> You could also type one more character of the filename, type space and
> then backspace, etc. -- anything so that you aren't invoking the same
> completion widget twice consecutively, which has its own special meaning.
Bingo! Thanks Bart. I can't say that's intuitive but it works and isn't 
hard to remember. But couldn't we have:

  zstyle ':completion:*' auto-multiple-completion

or something like that? In the above situation I'd want it to perform 
any and all completions/expansions/corrections all at once, every time. 
Mind, with completions, of course there can be choices to be made, but 
variable expansions should pretty well be automatic IMHO. Or at least 
I'd always want that.

Re: completion fails if dir referenced via variable.

[Bart Schaefer]

On Feb 25, 11:41am, Ray Andrews wrote:
}
} But couldn't we have:
} 
}   zstyle ':completion:*' auto-multiple-completion
} 
} or something like that? In the above situation I'd want it to perform 
} any and all completions/expansions/corrections all at once, every time. 

The default tab-binding around which this is essentially designed is
the builtin widget "expand-or-complete".  Note "or": expand if possible,
else complete, not both.

If what you want is "expand-and-complete" you can construct that:

    expand-and-complete() {
      zle expand-word	# perhaps _expand_word for compsys support
      zle complete-word
    }
    zle -N expand-and-complete
    bindkey $'\t' expand-and-complete

If you go with _expand_word instead of expand-word you still need the
tag-order all-expansions style that Oliver described, but there are some
rare cases that _expand_word handles better than the builtin expand-word.

Here's a slightly more sophisticated version:

    expand-and-complete() {
      if [[ $LASTWIDGET != expand-and-complete ]]; then
        zle expand-word
	zle auto-remove-suffix
      fi
      zle complete-word
    }
    zle -N expand-and-complete
    bindkey $'\t' expand-and-complete

This allows multiple TABs to enter menu completion, otherwise the call
to expand-word breaks off the last completion and starts a new one.

Re: completion fails if dir referenced via variable.

[Ray Andrews]

On 02/26/2014 06:29 PM, Bart Schaefer wrote:


Thanks Bart, I'm not sophisticated enough yet for this sort of thing. 
Where do I put this function? I'll certainly play with it, but I've not 
yet looked into the guts of any of this stuff. All those 'zstyle' things 
are a mystery. Is there some recommended doc? It's time I knew what 
those dozen or so 'zstyle' lines did.

As to:

} BTW another strange thing: if I start a fresh shell, I can't expand a
} variable unless I 'echo' it first. The variable is certainly set, and it
} echos to screen, but without echoing it, it will not expand nohow. Any
} reason of that?

I'm guessing this is going to depend on which variable you're trying.
Some variables are autoloaded from modules and appear when you reference
them with $varname, but wouldn't be around yet to be completed when you
first attempt it.

The variable is $t[?] where '?' is the number of each open terminal, and 
which holds the current directory for each open terminal. It's updated 
automatically within 'chpwd()'.  So 'cp $t1/filename .' copies  
'filename' from whatever is the current directory on terminal #1 to the 
current directory on whatever terminal the command is executed from. It 
works fine except that it won't expand on the command line in a brand 
new shell. Note this is not much of an issue since there's no problem 
with the actual copy, only with expanding it visually with TAB, and that 
only becomes an issue if I'm wanting to complete a filename in the same 
command in which a variable also exists, so it's the most minimal of 
bugs. Still it seems to me that it should expand. Actually, any command 
at all prior to the command in which  I attempt this sort of expansion 
solves the problem so it's only happens with an absolutely virgin shell. 
Not worth any trouble.

Re: key codes table.

[Ray Andrews]

So, using a tweaked zkbd I came up with this, I think it's pretty near 
all of them:



         BEGINNER'S GUIDE TO ZSH KEYBOARD ASSIGNMENTS, AKA 'KEYBOARD 
BINDINGS'.
   (comments, improvements, bitter denunciations welcome: rayandrews at 
eastlink dot ca)

'Available' key combinations on a '101' PC keyboard attached to a PC 
running 'zsh' under xfce4 under Debian Linux (I don't know who's 'in 
charge').  All combinations that produce duplicate codes within the 
'grey' keys have been removed except for the simplest avatar which is 
shown. Note, some grey keys/combinations have '^letter' duplicates, like 
'Enter' == '^M', these have not been removed. Other active combinations 
were not 'available' since used by the system, even from console, eg. 
'Alt+Function' keys switch terminals. Perhaps the 'Meta' key would do 
more, but this is with a 101 KB. Interesting that there are far more 
combinations available in DOS, such as Ctrl+Function -- all available in 
DOS, none of them available in Linux, so it seems.  None of the triple 
key combinations (eg. 'Ctrl+Alt+Up') produced any unique codes within 
the grey keys, but they do produce codes in the white keys.  Interesting 
anomalies: '^[[22' '^[[27' '^[[30' are 'missing', you hafta wonder why 
those numbers were skipped. (Which is to say that you might expect 'F11' 
to be '^[[22' not '^[[23'.)

The key codes shown are as they would be output by 'showkeys -a' or 
'bindkey' at CLI. However, for some reason if you use 'bindkey' within a 
script (as in '.zshrc') ' ^[ ' must be replaced with ' \e ', thus at CLI:

   bindkey -s '^[[[A' 'my-command \C-m'

... bind 'F1' to 'my-command' and execute it (the ' \C-m ' simulates the 
'Enter' key).

in '.zshrc':

   bindkey -s '\e[25' 'my-command1 ; my command2 \C-m'

... bind 'Shift-F1' to 'my-command1' followed by 'my-command2' and 
execute both of them.



COMBINATIONS USING JUST THE 'GREY' KEYS:

key[F1]        = '^[[[A'
key[F2]        = '^[[[B'
key[F3]        = '^[[[C'
key[F4]        = '^[[[D'
key[F5]        = '^[[[E'
key[F6]        = '^[[17~'
key[F7]        = '^[[18~'
key[F8]        = '^[[19~'
key[F9]        = '^[[20~'
key[F10]       = '^[[21~'
key[F11]       = '^[[23~'
key[F12]       = '^[[24~'

key[Shift-F1]  = '^[[25~'
key[Shift-F2]  = '^[[26~'
key[Shift-F3]  = '^[[28~'
key[Shift-F4]  = '^[[29~'
key[Shift-F5]  = '^[[31~'
key[Shift-F6]  = '^[[32~'
key[Shift-F7]  = '^[[33~'
key[Shift-F8]  = '^[[34~'

key[Insert]    = '^[[2~'
key[Delete]    = '^[[3~'
key[Home]      = '^[[1~'
key[End]       = '^[[4~'
key[PageUp]    = '^[[5~'
key[PageDown]  = '^[[6~'
key[Up]        = '^[[A'
key[Down]      = '^[[B'
key[Right]     = '^[[C'
key[Left]      = '^[[D'

key[Bksp]      = '^?'
key[Bksp-Alt]  = '^[^?'
key[Bksp-Ctrl] = '^H'    console only.

key[Esc]       = '^['
key[Esc-Alt]   = '^[^['

key[Enter]     = '^M'
key[Enter-Alt] = '^[^M'

key[Tab]       = '^I' or '\t'  unique form! can be bound, but does not 
'showkey -a'.
key[Tab-Alt]   = '^[\t'


COMBINATIONS USING THE WHITE KEYS:

Anomalies:
'Ctrl+`' == 'Ctrl+2', and 'Ctrl+1' == '1' in xterm.
Several 'Ctrl+number' combinations are void at console, but return codes 
in xterm. OTOH Ctrl+Bksp returns '^H' at console, but is identical to 
plain 'Bksp' in xterm. There are no doubt more of these little glitches 
however, in the main:

White key codes are easy to understand, each of these 'normal' printing 
keys has six forms:

A            = 'a'    (duhhh)
A-Shift      = 'A'    (who would have guessed?)
A-Alt        = '^[a'
A-Ctrl       = '^A'
A-Alt-Ctrl   = '^[^A'
A-Alt-Shift  = '^[A'
A-Ctrl-Shift = '^A'   (Shift has no effect)

Don't forget that:

/-Shift-Ctrl = Bksp      = '^?'
[-Ctrl       = Esc       = '^['
M-Ctrl       = Enter     = '^M'
I-Ctrl       = Tab       = '^I' or '\t'

And, we can 'stack' keybindings:

   bindkey -s '^Xm' "My mistress\' eyes are nothing like the sun."

... Bind 'Ctrl-X' followed by 'm' to a nice line of poetry.

And we can flirt with madness:

   bindkey -s '^Pletmenot' 'Let me not, to the marriage of true minds'

... but you hafta start something like that with a 'modifier' 
character.  Try it, if you like keyboard shortcuts, you can really go to 
town.


QUESTIONS:

Where is it written that 'Ctrl-Bksp' gives one code at console, another 
in in xterm?

Are these assignments changable?

Who designed all this, and what were they thinking at the time?

Why is it 'Alt-Function' to change terminals *at* a terminal, but 
'Alt-Ctrl-Function' to change *to* a terminal from GUI?

How/where is 'Alt-Ctrl-Delete' defined?

=======================================================

Re: key codes table.

[Bart Schaefer]

Eventually Ray is going to regret asking me these questions ...

On Feb 26,  9:34pm, Ray Andrews wrote:
}
} 'Available' key combinations on a '101' PC keyboard attached to a PC 
} running 'zsh' under xfce4 under Debian Linux (I don't know who's 'in 
} charge').

Unfortunately the set of key sequences you've listed here is likely
very specific to the environment you just described.  As you've noticed, 
it's not even the same for the console terminals on the same OS.

For example my PC101 keyboard on CentOS / Gnome sends ^[OQ, not ^[[[B.
On Ubuntu 12.04 it also sends ^[OQ.

} 'Alt+Function' keys switch terminals. Perhaps the 'Meta' key would do 
} more, but this is with a 101 KB.

Whether the Alt and Meta keys do something is also controllable via a
number of different mechanisms which may include X resources and your
language environment.

} Interesting that there are far more 
} combinations available in DOS, such as Ctrl+Function -- all available in 
} DOS, none of them available in Linux, so it seems.

If you mean Ctrl+F1, Ctrl+F2, etc., those are certainly available "in
Linux" because for Ctrl+F2 I get ^[O5Q (CentOs) or ^[O1;5Q (Ubuntu)
[and so on for other Ctrl+Fn keys].  (Actually this may be an xterm vs.
gnome-terminal difference instead of CentOS vs. Ubuntu.)

Do you begin to see why we don't bother attempting to create a static
table of all this?

} None of the triple 
} key combinations (eg. 'Ctrl+Alt+Up') produced any unique codes

Ctrl+Alt combinations are often grabbed by GUI management layers (as
are Meta combinations); more about this in a bit ...

} anomalies: '^[[22' '^[[27' '^[[30' are 'missing', you hafta wonder why 
} those numbers were skipped. (Which is to say that you might expect 'F11' 
} to be '^[[22' not '^[[23'.)

Could be an artifact of some other (possibly historical/disused) keyboard
layout such as the Sun keyboard that zkbd partly supports.  Could even be
related to the wiring of the circuit board in some keyboard from the 80s
that became a defacto standard.  A lot of this stuff was invented when
most Unix keyboards were an integral part of the terminal device and
there was no such thing as separate, independent monitor and keyboard.

} A-Alt        = '^[a'
} A-Alt-Ctrl   = '^[^A'
} A-Alt-Shift  = '^[A'

Note that the effect of Alt prefixing the key with ESC is one of those
things I mentioned about that may depend on your language environment.
It is equally likely that those combinations send single 8-bit chars
equivalent to $'\Ma' $'\M\Ca' and $'\MA' respectively.

Or the Meta key might do that instead of the Alt key.
 
} Don't forget that:
} 
} /-Shift-Ctrl = Bksp      = '^?'

Actually that is ASCII DELete not Backspace.  Backspace is ^H ... but 
of course the Del key might send any of ^? or ^H or ^[[3~ etc., and
the key labeled Backspace often sends ^?.

} Where is it written that 'Ctrl-Bksp' gives one code at console, another 
} in in xterm?
} 
} Are these assignments changeable?
} 
} Who designed all this, and what were they thinking at the time?
} 
} Why is it 'Alt-Function' to change terminals *at* a terminal, but 
} 'Alt-Ctrl-Function' to change *to* a terminal from GUI?
} 
} How/where is 'Alt-Ctrl-Delete' defined?

All of these have related answers.

Consider all the layers that a key press has to pass through to reach
your shell or other program running in your xterm:

- Circuit board in the keyboard itself
- Motherboard or graphics card hardware
- BIOS
- Operating system device driver
- Input event device
  [<
- X server event handler
- Session manager
- Desktop manager
- Window manager
- Terminal emulator
  >]
- (Pseudo-) TTY device
- Kernel I/O layer
- User-space system call interface

Everything in [< here >] is replaced by the virtual console manager
when you are not using a GUI.  That is the background for both of
your questions about why xterm and console behave differently.  It's
a bit more complicated than that because the GUI usually occupies
one of the virtual consoles, but this is windy enough already.

(In DOS, roughly speaking, things go directly from the OS driver to
the I/O layer and skip everything I listed in between, which is why
there is so little variation or complexity in behavior.)

In many cases there's also a special language-dependent keyboard
input layer in there somewhere, to handle ideogram compositing in
Chinese or translating an English keyboard to input in Cyrillic, or
what have you.

Each of these layers gets a chance to handle the event before the
one below it may do so.  Ctrl-Alt-Del is usually handled in the BIOS
or the OS device driver.  Caps Lock is a hardware thing on some old
keyboards and sent no event to the motherboard.  Key repeat is often
a hardware thing but is frequently emulated (or mediated) by one of
the software layers instead.  Ctrl-Alt-Fn is handled by the X server
(usually; could be one of the other manager layers) whereas Alt-Fn
is handled by the virtual console manager.  Etc.

There are two other things about the stuff [< here >].  First, each
above the terminal emulator sees a separate event for every key on
your keyboard; there isn't a single event for e.g. "Ctrl+Alt+F7": 

- Ctrl press
- Alt pres
- F7 press
- F7 release
- Alt release
- Ctrl release

which of course can happen in a variety of orders depending on your
typing style and speed, though at least the first two must precede
the third.  Each layer can choose to act (or not) on each event, and
to pass along (or not) (or both) each event, though passing along a
"press" without also passing "release" is bad form (happens sometimes
though, often by accident).

The terminal emulator gets sent the events that trickle through the
layers above it, and keeps track of state so that it can send the key
(or key sequence) as one "event" to the TTY device at the time of the
appropriate "press" (or sometimes release) event, and then unwind that
state as the rest of the release events arrive.

Second, in a GUI environment there's a lot more meaning associated
with those events than just keyboard input.  Ctrl with a mouse click
or drag may mean something, the pointer position at the instant the
key is pressed is important, etc., etc.  Everything up and down the
stack of layers has to cooperate.

So "who designed this" is "different people at different times" and
"what were they thinking?" is generally "what works best for user
control of each layer he's allowed to control, without screwing up
all the old stuff that everyone is already familiar with?"

Of course in the case of terminal emulators they were also thinking
"how do I make this work as much like an <thingus> terminal as it
can while still playing nicely with everything else?"

As for whether the assignments are changeable: yes!  At effectively
every layer from the session manager down to the terminal emulator;
though exactly what they are allowed to do at each layer varies,
and you might have to change several layers to get a particular key
combination to be visible to the terminal emulator, which may break
something else in ways you don't expect.

Does that clear things up? :-)

Re: key codes table.

[Ray Andrews]

On 02/28/2014 09:08 PM, Bart Schaefer wrote:
> Eventually Ray is going to regret asking me these questions ...
Eventually Bart is going to give up in despair ;-)
> Unfortunately the set of key sequences you've listed here is likely
> very specific to the environment you just described.  As you've noticed,
> it's not even the same for the console terminals on the same OS.
No surprise there. I know this is a layer cake sort of thing with 
hardware/kernel/zsh/X/xfce/app each having their
own kick at the keyboard. Anyway, it was an interesting exercise seeing 
what I have here on a grey colored PC runing debian/zsh/xfce in Canada 
on Tuesday.
> Do you begin to see why we don't bother attempting to create a static
> table of all this?
I sure do! Still some automated way of coughing it all up as a table 
would be nice. It would
be good to know what KB resources one has at one's disposal in any given 
situation, remembering that it
could all change on Wednesday. That's what I was trying to accomplish.
Sorta like 'bindkey' shows what bindings are currently active, one might
have a dump of all possible bindings in the current environment. One 
might then plan some sort of
personal coordinated keyboard layout that can plan around existing keys. 
Mean time, I wrote a sort of
souped up 'showkey'

pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ . ./x

Type the keycode you want, then 'space' to see what it is bound to.
TAB exits the program.

Key ... ^A
                 "^A" bound to:  beginning-of-line
Key ... ^Z
                      (unused)
Key ... ^Zc
                      (unused)
Key ... ^Xc
                "^Xc" bound to:  _correct_word
Key ... ^Xnuns
             "^Xnuns" bound to:  "Nuns fret not at their convents narrow 
room"
Key ... z

output (cat /tmp/keys_tmp):

                 "^A" bound to:  beginning-of-line
                      (unused)
                      (unused)
                "^Xc" bound to:  _correct_word
             "^Xnuns" bound to:  "Nuns fret not at their convents narrow 
room"

pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ l

==============================


  Could be an artifact of some other (possibly historical/disused) keyboard
layout such as the Sun keyboard that zkbd partly supports.  Could even be
related to the wiring of the circuit board in some keyboard from the 80s
that became a defacto standard.  A lot of this stuff was invented when
most Unix keyboards were an integral part of the terminal device and
there was no such thing as separate, independent monitor and keyboard.

Eventually those things will be lost in the mists of time. It's hardly 
important.
> } Don't forget that:
> }
> } /-Shift-Ctrl = Bksp      = '^?'
>
> Actually that is ASCII DELete not Backspace.  Backspace is ^H ... but
> of course the Del key might send any of ^? or ^H or ^[[3~ etc., and
> the key labeled Backspace often sends ^?.
Mere anarchy.
>
> Consider all the layers that a key press has to pass through to reach
> your shell or other program running in your xterm:
>
> - Circuit board in the keyboard itself
> - Motherboard or graphics card hardware
> - BIOS
> - Operating system device driver
> - Input event device
>    [<
> - X server event handler
> - Session manager
> - Desktop manager
> - Window manager
> - Terminal emulator
>    >]
> - (Pseudo-) TTY device
> - Kernel I/O layer
> - User-space system call interface
I AM sorry I asked ;-)
> (In DOS, roughly speaking, things go directly from the OS driver to
> the I/O layer and skip everything I listed in between, which is why
> there is so little variation or complexity in behavior.)
That's right. I actually understood all this stuff in DOS. Now we have 
'XKB' which the Devil
himself probably does not understand.
....
> As for whether the assignments are changeable: yes!  At effectively
> every layer from the session manager down to the terminal emulator;
> though exactly what they are allowed to do at each layer varies,
> and you might have to change several layers to get a particular key
> combination to be visible to the terminal emulator, which may break
> something else in ways you don't expect.
>
> Does that clear things up? :-)
>
That made it about as clear as it could be, which is still somewhat 
beyond my abilities. Sheesh,
this started when I noticed that the key between my left Ctrl and Alt 
keys (which currently outputs '<')
produces a different scan code than the other '<' which is the shifted 
comma key,
and I was wondering if I could morph it into a 'Meta' key. And never in 
my life have I been so sorry
that I looked into something ;-) I know how Pandora felt. This is not 
something that an ordinary mortal
should get involved with.

Re: key codes table.

[shawn wilson]

[-- Attachment #1: Type: text/plain, Size: 5222 bytes --]

If you want that chart, you should be able to come up with a script that
gets key bindings for \x00 - \x255 (or more realistically 80~200 -
printable characters) and we can run it through common environments? I
think that's what you're looking for anyway?
On Mar 1, 2014 3:45 PM, "Ray Andrews" <rayandrews@eastlink.ca> wrote:

> On 02/28/2014 09:08 PM, Bart Schaefer wrote:
>
>> Eventually Ray is going to regret asking me these questions ...
>>
> Eventually Bart is going to give up in despair ;-)
>
>> Unfortunately the set of key sequences you've listed here is likely
>> very specific to the environment you just described.  As you've noticed,
>> it's not even the same for the console terminals on the same OS.
>>
> No surprise there. I know this is a layer cake sort of thing with
> hardware/kernel/zsh/X/xfce/app each having their
> own kick at the keyboard. Anyway, it was an interesting exercise seeing
> what I have here on a grey colored PC runing debian/zsh/xfce in Canada on
> Tuesday.
>
>> Do you begin to see why we don't bother attempting to create a static
>> table of all this?
>>
> I sure do! Still some automated way of coughing it all up as a table would
> be nice. It would
> be good to know what KB resources one has at one's disposal in any given
> situation, remembering that it
> could all change on Wednesday. That's what I was trying to accomplish.
> Sorta like 'bindkey' shows what bindings are currently active, one might
> have a dump of all possible bindings in the current environment. One might
> then plan some sort of
> personal coordinated keyboard layout that can plan around existing keys.
> Mean time, I wrote a sort of
> souped up 'showkey'
>
> pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ . ./x
>
> Type the keycode you want, then 'space' to see what it is bound to.
> TAB exits the program.
>
> Key ... ^A
>                 "^A" bound to:  beginning-of-line
> Key ... ^Z
>                      (unused)
> Key ... ^Zc
>                      (unused)
> Key ... ^Xc
>                "^Xc" bound to:  _correct_word
> Key ... ^Xnuns
>             "^Xnuns" bound to:  "Nuns fret not at their convents narrow
> room"
> Key ... z
>
> output (cat /tmp/keys_tmp):
>
>                 "^A" bound to:  beginning-of-line
>                      (unused)
>                      (unused)
>                "^Xc" bound to:  _correct_word
>             "^Xnuns" bound to:  "Nuns fret not at their convents narrow
> room"
>
> pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ l
>
> ==============================
>
>
>  Could be an artifact of some other (possibly historical/disused) keyboard
> layout such as the Sun keyboard that zkbd partly supports.  Could even be
> related to the wiring of the circuit board in some keyboard from the 80s
> that became a defacto standard.  A lot of this stuff was invented when
> most Unix keyboards were an integral part of the terminal device and
> there was no such thing as separate, independent monitor and keyboard.
>
> Eventually those things will be lost in the mists of time. It's hardly
> important.
>
>> } Don't forget that:
>> }
>> } /-Shift-Ctrl = Bksp      = '^?'
>>
>> Actually that is ASCII DELete not Backspace.  Backspace is ^H ... but
>> of course the Del key might send any of ^? or ^H or ^[[3~ etc., and
>> the key labeled Backspace often sends ^?.
>>
> Mere anarchy.
>
>>
>> Consider all the layers that a key press has to pass through to reach
>> your shell or other program running in your xterm:
>>
>> - Circuit board in the keyboard itself
>> - Motherboard or graphics card hardware
>> - BIOS
>> - Operating system device driver
>> - Input event device
>>    [<
>> - X server event handler
>> - Session manager
>> - Desktop manager
>> - Window manager
>> - Terminal emulator
>>    >]
>> - (Pseudo-) TTY device
>> - Kernel I/O layer
>> - User-space system call interface
>>
> I AM sorry I asked ;-)
>
>> (In DOS, roughly speaking, things go directly from the OS driver to
>> the I/O layer and skip everything I listed in between, which is why
>> there is so little variation or complexity in behavior.)
>>
> That's right. I actually understood all this stuff in DOS. Now we have
> 'XKB' which the Devil
> himself probably does not understand.
> ....
>
>> As for whether the assignments are changeable: yes!  At effectively
>> every layer from the session manager down to the terminal emulator;
>> though exactly what they are allowed to do at each layer varies,
>> and you might have to change several layers to get a particular key
>> combination to be visible to the terminal emulator, which may break
>> something else in ways you don't expect.
>>
>> Does that clear things up? :-)
>>
>>  That made it about as clear as it could be, which is still somewhat
> beyond my abilities. Sheesh,
> this started when I noticed that the key between my left Ctrl and Alt keys
> (which currently outputs '<')
> produces a different scan code than the other '<' which is the shifted
> comma key,
> and I was wondering if I could morph it into a 'Meta' key. And never in my
> life have I been so sorry
> that I looked into something ;-) I know how Pandora felt. This is not
> something that an ordinary mortal
> should get involved with.
>
>

Re: key codes table.

[Bart Schaefer]

On Mar 1,  5:50pm, shawn wilson wrote:
}
} If you want that chart, you should be able to come up with a script that
} gets key bindings for \x00 - \x255 (or more realistically 80~200 -
} printable characters) and we can run it through common environments?

The problem is getting the keyboard to send those characters.  In an
XKB environment you might be able to read out the keyboard definitions
but that won't help for consoles, ssh connections, etc.  It would be
(was, in the past, IIRC) a large security problem if there were a way
to script a keyboard to send back arbitrary keystrokes.

Re: key codes table.

[shawn wilson]

[-- Attachment #1: Type: text/plain, Size: 969 bytes --]

Hummm, I know this should be possible with qemu but a quick Google is
failing to find an easy way to do this. There's probably a fake serial
device kernel module though... I'm not going to try so hard as to go
through a VM but if this is possible without I'll write something.
On Mar 2, 2014 12:28 PM, "Bart Schaefer" <schaefer@brasslantern.com> wrote:

> On Mar 1,  5:50pm, shawn wilson wrote:
> }
> } If you want that chart, you should be able to come up with a script that
> } gets key bindings for \x00 - \x255 (or more realistically 80~200 -
> } printable characters) and we can run it through common environments?
>
> The problem is getting the keyboard to send those characters.  In an
> XKB environment you might be able to read out the keyboard definitions
> but that won't help for consoles, ssh connections, etc.  It would be
> (was, in the past, IIRC) a large security problem if there were a way
> to script a keyboard to send back arbitrary keystrokes.
>

Re: key codes table.

[Ray Andrews]

On 03/02/2014 10:18 AM, shawn wilson wrote:
> Hummm, I know this should be possible with qemu but a quick Google is
> failing to find an easy way to do this. There's probably a fake serial
> device kernel module though... I'm not going to try so hard as to go
> through a VM but if this is possible without I'll write something.
> On Mar 2, 2014 12:28 PM, "Bart Schaefer" <schaefer@brasslantern.com> wrote:
>

I dunno, but it seems to me that there would have to be some sort of 
'receiver' apparatus somewhere.
I can understand that there is probably no way of forcing the KB to send 
all it's scancodes, but on the other end,
when I tell this machine that I have a 101 KB, it would seem that it's 
prepping itself to receive this that and the other scancodes IOW it 
knows what my KB can and can't do and is equipped to receive anything 
that the KB is
able to send. *that* should be findable, I'd say.  Why else would there 
be a hundred different KB defs unless to have an exact list of every 
KB's potential.
>> On Mar 1,  5:50pm, shawn wilson wrote:
>> }
>> } If you want that chart, you should be able to come up with a script that
>> } gets key bindings for \x00 - \x255 (or more realistically 80~200 -
>> } printable characters) and we can run it through common environments?
>>
>> The problem is getting the keyboard to send those characters.  In an
>> XKB environment you might be able to read out the keyboard definitions
>> but that won't help for consoles, ssh connections, etc.  It would be
>> (was, in the past, IIRC) a large security problem if there were a way
>> to script a keyboard to send back arbitrary keystrokes.
>>

Re: completion fails if dir referenced via variable.

[Oliver Kiddle]

Bart wrote:
> On Feb 25, 10:25am, Ray Andrews wrote:
> }
> } It seems intuitive that one should be able to have more than one 
> } expansion and/or completion per line, not just one, does it not? Why the 
> } artificial limitation?
> 
> It's not a limitation, it's that way so that two tabs in a row enters
> menu completion on the same set of answers.  You have to do something

Menu completion is only an option because _expand adds both
all-expansions and original as matches. When there's only one match,
that gets inserted and a subsequent tab will start completion anew.

original is always fairly useless because a key bound to undo gets you
back to the original fairly easily. So does the following help?

  zstyle ':completion:*:expand:*' tag-order all-expansions

Oliver

Re: completion fails if dir referenced via variable.

[Ray Andrews]

On 02/25/2014 12:02 PM, Oliver Kiddle wrote:
> zstyle ':completion:*:expand:*' tag-order all-expansions 

> Oliver 

Glorious success! I still have to press TAB twice, but no need to 'do 
something else' between presses. I'd still like to see a 'one TAB does 
it all' option tho. And when " _expand " is set, it seems to me there's 
nothing to ask -- just do it.

BTW another strange thing: if I start a fresh shell, I can't expand a 
variable unless I 'echo' it first. The variable is certainly set, and it 
echos to screen, but without echoing it, it will not expand nohow. Any 
reason of that?

Re: completion fails if dir referenced via variable.

[Bart Schaefer]

On Feb 25,  1:57pm, Ray Andrews wrote:
}
} BTW another strange thing: if I start a fresh shell, I can't expand a 
} variable unless I 'echo' it first. The variable is certainly set, and it 
} echos to screen, but without echoing it, it will not expand nohow. Any 
} reason of that?

I'm guessing this is going to depend on which variable you're trying.
Some variables are autoloaded from modules and appear when you reference
them with $varname, but wouldn't be around yet to be completed when you
first attempt it.

Re: Access command that called a function within the function.

[Ray Andrews]

On 04/02/14 07:46 PM, Bart Schaefer wrote:

Bart,

> If you're only worried about knowing the line that was entered at the
> interactive prompt, which seems to be the case because you are asking
> about the history:  Use a preexec hook to copy one of the arguments to
> a parameter declared with typeset -g, and then reference the parameter.
> The value of $1 during preexec is the closest you'll get to the string
> that is going to be written to the history.  The value of $3 might be
> more useful depending on what you want to do with it.
>

After some reading, I came up with this:

autoload -U add-zsh-hook
typeset -g last_command
hook_function() { last_command=$1; }
add-zsh-hook preexec hook_function

... and it works perfectly so far as I can see--I can grab the litteral 
command line verbatim without any further trouble which makes passing 
the command tail, unexpanded, to history easy.

Many thanks.