So it rejects hooks that have the exact same name and params.
I’m not worried about malicious code, but about my own code, if I use the counter mechanism in a lot of places. For example, here’s a with-tmpfile
mechanism:
def defp -params .. %{
def -override -params .. %arg{@}
} -override
declare-option int tmpcnt
defp with-tmpfile %{
set -add global tmpcnt 1
%arg{@} "/tmp/kak_tmp_%opt{tmpcnt}"
hook -group tst -once add NormalIdle .* %{
nop %sh{ rm -f "/tmp/kak_tmp_%opt{tmpcnt}" }
}
}
defp tst-cmd-hist %{
echo -debug %arg{1}
echo -to-file %arg{1} -quoting shell -- set -- %reg{:}
nop %sh{
. "$1" # load prologue, overwrites $@
echo 1>&2 "Second command was $2"
}
}
with-tmpfile tst-cmd-hist
This code avoids the issue with potentially limited environ
size on various systems, as pointed out by @Screwtapello in a previous topic, by saving them to a temp file (which should be a RAM-only operation) and loading the file inside the shell into shell (not environment) variables.
Regarding the shell, I know it’s a controversial topic. I actually love the shell, as is probably apparent from my posts here. Now, a lot of people say calling the shell doesn’t matter — and it doesn’t, on a desktop, or for infrequent hooks. On a laptop, for “on-every-keystroke”, or “on-timer-msecs” hooks, there’s battery life and thermal (and possibly fan → unbearable noise) to consider.
Also, TBH, it’s fun to figure out how to do things differently