Here's maybe a better question than the last one: bindkey "\e[A" history-beginning-search-backward ... use this in the old install and the new install of Debian 11, same config files exactly. But now, the up arrow has no sense of completion of a command that's partially typed, it just gives the last command typed and overwrites whatever command you've partially typed before hitting the up arrow. $ bindkey ... shows: "^[[A" history-beginning-search-backward ... which seems to show that it's been set properly. I wonder what could have changed. Mind, this is the 'apt-get install zsh' version so perhaps there's some other config file somewhere making mischief.
On Sun, Sep 25, 2022 at 2:14 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> bindkey "\e[A" history-beginning-search-backward
>
> ... use this in the old install and the new install of Debian 11, same
> config files exactly. But now, the up arrow has no sense of completion
> of a command that's partially typed, it just gives the last command
Chances are that the default terminal setting for "keypad transmit
mode" has changed.
Type ctrl-v and then press up arrow, I'll bet you don't see ^[[A (and
if you do, there's something more insidious going on, such as your
setting of $KEYTIMEOUT)
To be more thorough, run
autoload -Uz zkbd
zkbd
(If anyone tries this and sees something wrong or incomplete with the
explanatory output, please let us know.)
On 2022-09-25 15:31, Bart Schaefer wrote: > > Type ctrl-v and then press up arrow, I'll bet you don't see ^[[A (and > if you do, there's something more insidious going on, such as your > setting of $KEYTIMEOUT) I get: " ^[OA " but the " ^[ " is highlighted -- black text on white background. $ echo $KEYTIMEOUT 40 > > To be more thorough, run > > autoload -Uz zkbd > zkbd Here's what I get: 0 /root/.config/geany/colorschemes 0 $ zkbd Enter current terminal type: [xterm-256color] We will now test some features of your keyboard and terminal. If you do not press the requested keys within 10 seconds, key reading will abort. If your keyboard does not have a requested key, press Space to skip to the next key. Hold down Ctrl and press X: ^X Your Meta key may have a Microsoft Windows logo on the cap. Hold down Meta and press X: x Your keyboard or terminal does not recognize the Meta key. Hold down Alt and press X: ^[x# 0 /root/.config/geany/colorschemes 0 $ 3:44PM Sun 25 execute: _ > (If anyone tries this and sees something wrong or incomplete with the > explanatory output, please let us know.) >
On 2022-09-25 15:46, Ray Andrews wrote:
> On 2022-09-25 15:31, Bart Schaefer wrote:
Here's a clue. I have a non-Debian download of 5.8 and I fire it up and
the up arrow completes just fine, so the problem is internal to the
Debian version of zsh ... so it seems. I'm presuming that the
configuration proceeds the same way, via finding .zshrc in the user's
home directory and so on and so forth, so all the various scripts should
be the same, no?
Some config issue I think. 'good' version is: " zsh 5.8 (x86_64-pc-none) " ... that's the 'non-Debian'. But if I do: $ zsh -f; . /root/.zshrc ... I'm expecting basically an identical result to just: $ zsh ... but the latter gives me the working up arrow key and the former does not. So there's some other file being accessed that I don't even know is there. Is there some way of tracing the entire process?
On Sun, Sep 25, 2022, at 9:16 PM, Ray Andrews wrote:
> Some config issue I think.
> 'good' version is: " zsh 5.8 (x86_64-pc-none) " ... that's the
> 'non-Debian'. But if I do:
>
> $ zsh -f; . /root/.zshrc
>
> ... I'm expecting basically an identical result to just:
>
> $ zsh
The first command runs a NO_RCS shell and then sources /root/.zshrc
*in the calling shell, after the NO_RCS shell exits*. It is not
analogous to the second command at all.
outer% PS1='inner%% ' zsh -f; . <(print print done)
inner% exit
done
outer%
--
vq
On 2022-09-25 18:58, Lawrence Velázquez wrote:
>
> The first command runs a NO_RCS shell and then sources /root/.zshrc
> *in the calling shell, after the NO_RCS shell exits*. It is not
> analogous to the second command at all.
>
Thanks. I'll find out what NO_RCS is. I thought 'zsh -f' was 'a clean'
startup, nothing sourced at all. Then I could just feed it the scripts
that I choose.
> I get: " ^[OA " but the " ^[ " is highlighted the highlighted part is actually \e. it's more obvious when you use xxd: echo <c-v><the key> |xxd so what about this? bindkey "\eOA" history-beginning-search-backward regards -- Marc Chantreux Pôle de Calcul et Services Avancés à la Recherche (CESAR) http://annuaire.unistra.fr/p/20200
On Sun, Sep 25, 2022, at 11:15 PM, Ray Andrews wrote: > On 2022-09-25 18:58, Lawrence Velázquez wrote: >> >> The first command runs a NO_RCS shell and then sources /root/.zshrc >> *in the calling shell, after the NO_RCS shell exits*. It is not >> analogous to the second command at all. >> > Thanks. I'll find out what NO_RCS is. I thought 'zsh -f' was 'a clean' > startup, nothing sourced at all. Not quite; the global zshenv (/etc/zshenv by default) is always run. > Then I could just feed it the scripts that I choose. Regardless of what type of shell you launch, the command you suggested earlier does not do that. Running cmd1; cmd2 executes 'cmd1' and then executes 'cmd2' after 'cmd1' has exited. This is basic shell behavior that is not affected by whether 'cmd1' is 'zsh -f' or anything else (alias shenanigans aside). -- vq
On Mon, Sep 26, 2022 at 3:17 AM Ray Andrews <rayandrews@eastlink.ca> wrote: > > Some config issue I think. > 'good' version is: " zsh 5.8 (x86_64-pc-none) " ... that's the > 'non-Debian'. But if I do: > > $ zsh -f; . /root/.zshrc > > ... I'm expecting basically an identical result to just: > > $ zsh > > ... but the latter gives me the working up arrow key and the former does > not. So there's some other file being accessed that I don't even know > is there. Is there some way of tracing the entire process? If the non-Debian version is https://github.com/romkatv/zsh-bin, then you need to keep in mind that it does not read global rc files. This is a statically built binary, so it has no way of knowing where global rc files are. Another reason is that I have little respect for global rc files, including those in Debian. You can use the following command to list all files sourced by login interactive zsh, including those sourced from the first precmd and zle-line-init hooks (if any): zsh --sourcetrace -lis <<<exit If you run that on Debian with the system zsh, you'll see among other things /etc/zsh/zshrc. If you look inside, you'll find awful things. Some of them you can disable by defining special parameters in ~/.zshenv, others can only be avoided by turning off global rc completely. If you decide to keep using global rcs, I highly recommend adding `skip_global_compinit=1` to ~/.zshenv. If you don't do that, zsh will start super slow if you change fpath in ~/.zshrc because zcompdump will be regenerated _twice_ every time you start a new interactive shell. There are several ways to make basic keys work in zsh. My favorite is to translate key codes from other terminals/modes to xterm equivalents in raw mode and then bind only the latter. Here's an example: for 1 in emacs viins vicmd; do # If NumLock is off, translate keys to make # them appear the same as with NumLock on. bindkey -M $1 -s '^[OM' '^M' # enter bindkey -M $1 -s '^[OX' '=' bindkey -M $1 -s '^[Oj' '*' bindkey -M $1 -s '^[Ok' '+' bindkey -M $1 -s '^[Ol' '+' bindkey -M $1 -s '^[Om' '-' bindkey -M $1 -s '^[On' '.' bindkey -M $1 -s '^[Oo' '/' bindkey -M $1 -s '^[Op' '0' bindkey -M $1 -s '^[Oq' '1' bindkey -M $1 -s '^[Or' '2' bindkey -M $1 -s '^[Os' '3' bindkey -M $1 -s '^[Ot' '4' bindkey -M $1 -s '^[Ou' '5' bindkey -M $1 -s '^[Ov' '6' bindkey -M $1 -s '^[Ow' '7' bindkey -M $1 -s '^[Ox' '8' bindkey -M $1 -s '^[Oy' '9' # If someone switches our terminal to application # mode (smkx), translate keys to make them appear # the same as in raw mode (rmkx). bindkey -M $1 -s '^[OA' '^[[A' # up bindkey -M $1 -s '^[OB' '^[[B' # down bindkey -M $1 -s '^[OD' '^[[D' # left bindkey -M $1 -s '^[OC' '^[[C' # right bindkey -M $1 -s '^[OH' '^[[H' # home bindkey -M $1 -s '^[OF' '^[[F' # end # Non-graphical Linux TTY sends different key # codes. Translate them to xterm equivalents. bindkey -M $1 -s '^[[1~' '^[[H' # home bindkey -M $1 -s '^[[4~' '^[[F' # end # Tmux sends different key codes. Translate # them to xterm equivalents. bindkey -M $1 -s '^[[1~' '^[[H' # home bindkey -M $1 -s '^[[4~' '^[[F' # end bindkey -M $1 -s '^[^[[A' '^[[1;3A' # alt+up bindkey -M $1 -s '^[^[[B' '^[[1;3B' # alt+down bindkey -M $1 -s '^[^[[D' '^[[1;3D' # alt+left bindkey -M $1 -s '^[^[[C' '^[[1;3C' # alt+right bindkey -M $1 -s '^[^[[1~' '^[[1;3H' # alt+home bindkey -M $1 -s '^[^[[4~' '^[[1;3F' # alt+end bindkey -M $1 -s '^[^[[3~' '^[[3;3~' # alt+delete done # Bind keys with xterm codes. bindkey -M emacs '^[[H' beginning-of-line # home bindkey -M viins '^[[H' vi-beginning-of-line # home bindkey -M emacs '^[[F' end-of-line # end bindkey -M viins '^[[F' vi-end-of-line # end (It should read better with a monospace font.) I lifted this code from https://github.com/romkatv/zsh-bench/blob/master/configs/minimal/skel/.zsh/keys.zsh. You can find more bindings in there. This code in turn was lifted from zsh4humans. The two common objections to binding keys this way are clashes and performance. Neither applies in practice: there are no clashes and virtually no performance impact on zsh startup time. On my machine the code I posted above takes about 10 times less time to evaluate than invoking /bin/true. Roman.
On 2022-09-25 23:28, Roman Perepelitsa wrote: > > If the non-Debian version is https://github.com/romkatv/zsh-bin, then > you need to keep in mind that it does not read global rc files. This > is a statically built binary, so it has no way of knowing where global > rc files are. Didn't know, but I'm glad to hear it, I want all my config to start from a single script that I know about (/root/.zshrc in this case which your version does seem to find) but don't go sourcing this and that without asking. Yes, when I first got involved the remember hunting down all the little things that zsh might go looking for and I killed them all -- after moving whatever functionality into *my* config path. > zsh --sourcetrace -lis <<<exit > Fabulous, that's just what one wants to figure this kind of thing out. > If you run that on Debian with the system zsh, you'll see among other > things /etc/zsh/zshrc. If you look inside, you'll find awful things. Yep. I renamed that directory and now the Debian zsh configs itself properly and the up arrow is fine. So now I'll look into those files and see what Debian thinks is good for me. > Some of them you can disable by defining special parameters in ... The rest is way over my head but I'll save it play with it. For now the /etc/zsh files are on ice and so far so good. Thanks Roman, solved. Hey, supposing we concluded solved threads with some indication, like I'm experimenting with in my subject line?
On 2022-09-26 06:59, Ray Andrews wrote:
> Hey, supposing we concluded solved threads with some indication, like
> I'm experimenting with in my subject line?
>
A wee bit more trouble but at least I figgered it out myself. HOME and
END stopped working.
Used to work:
bindkey "\eOH" beginning-of-line
bindkey "\eOF" end-of-line
... but now:
# 2022-09-26: These are the new values for HOME and END:
bindkey "\e[H" beginning-of-line
bindkey "\e[F" end-of-line
Why does this happen? Who does this, and why do they do it? Is this
something built into the keyboard or does Debian do this? IIRC the
actual hardware signals to the computer are not what '^v' shows us,
there's a few levels of interpretation involved, so could be the
keyboard itself, or Debian or Linux. But why bother? Why do they hate us?
On Mon, Sep 26, 2022 at 8:05 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> On 2022-09-26 06:59, Ray Andrews wrote:
>
> > Hey, supposing we concluded solved threads with some indication, like
> > I'm experimenting with in my subject line?
> >
> A wee bit more trouble but at least I figgered it out myself. HOME and
> END stopped working.
>
> Used to work:
>
> bindkey "\eOH" beginning-of-line
> bindkey "\eOF" end-of-line
>
> ... but now:
>
> # 2022-09-26: These are the new values for HOME and END:
> bindkey "\e[H" beginning-of-line
> bindkey "\e[F" end-of-line
Different terminals send different byte sequences when you press keys.
See my previous email for a solution that will render you immunite to
this.
Roman.
P.S.
Your changing the subject broke threading. I think it's not a good idea
to do that. Posting "yeah, it works" is a good idea though.
On Mon, 2022-09-26 at 20:13 +0200, Roman Perepelitsa wrote:
> Your changing the subject broke threading. I think it's not a good idea
> to do that.
Actually, a poll of three local clients --- one desktop, one browser-based,
one Android --- suggests it didn't universally break it, since they all
handled it, so there is a bit of wiggle room here. I would say it's an area
where there isn't a definite right or wrong --- there are just too many
different client behaviours to worry about to be too dogmatic. Having
said that, I tend to keep subject lines unaltered until the subject
has actually changed --- and by the same token, you don't know even
that's going to make your client use a new thread if it's going by
message IDs.
In summary, bleugh.
pws
P.S. Evolution, Vivaldi's internal client, and K9 Mail, in case you're
wondering.
On 9/26/22, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Mon, 2022-09-26 at 20:13 +0200, Roman Perepelitsa wrote:
>> Your changing the subject broke threading. I think it's not a good idea
>> to do that.
>
> Actually, a poll of three local clients --- one desktop, one browser-based,
> one Android --- suggests it didn't universally break it, since they all
> handled it, so there is a bit of wiggle room here. I would say it's an
> area
> where there isn't a definite right or wrong --- there are just too many
> different client behaviours to worry about to be too dogmatic. Having
> said that, I tend to keep subject lines unaltered until the subject
> has actually changed --- and by the same token, you don't know even
> that's going to make your client use a new thread if it's going by
> message IDs.
>
> In summary, bleugh.
>
> pws
>
> P.S. Evolution, Vivaldi's internal client, and K9 Mail, in case you're
> wondering.
For all its virtues (probably countable on one hand), GMail still has
no support for threads after all these years. Trying to read lkml or
git is nigh impossible since all the PATCH x/50 threads are completely
disjointed. It simply groups mails naively by subject which is pretty
much objectively the wrong thing to do. (This also leads to a lot of
confusion when getting automated mails with the same subject line but
which aren't strictly related).
</rant>
--
Mikael Magnusson
On 2022-09-26 11:13, Roman Perepelitsa wrote: > > Different terminals send different byte sequences when you press keys. > See my previous email for a solution that will render you immunite to > this. That's saved and will be studied, for now I'm just wanting to get this upgrade working. > Your changing the subject broke threading. I think it's not a good idea > to do that. Posting "yeah, it works" is a good idea though. I'm just thinking that when you're googling for something or other and something from here pops onto the list, as often happens for me, knowing that the question is actually solved would be a useful clue to whoever is searching for an answer not just a question. I guess that functionality isn't available here tho. Some fora have 'solved' buttons, it's a good thing.
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --] If Google is your concern, put the text in your message, as an SEO would. Please don't retitle the subject (although a proper mail agent would ignore that). On Mon, Sep 26, 2022 at 5:48 PM Ray Andrews <rayandrews@eastlink.ca> wrote: > On 2022-09-26 11:13, Roman Perepelitsa wrote: > > > > Different terminals send different byte sequences when you press keys. > > See my previous email for a solution that will render you immunite to > > this. > That's saved and will be studied, for now I'm just wanting to get this > upgrade working. > > Your changing the subject broke threading. I think it's not a good idea > > to do that. Posting "yeah, it works" is a good idea though. > I'm just thinking that when you're googling for something or other and > something from here pops onto the list, as often happens for me, knowing > that the question is actually solved would be a useful clue to whoever > is searching for an answer not just a question. I guess that > functionality isn't available here tho. Some fora have 'solved' > buttons, it's a good thing. > > > > [-- Attachment #2: Type: text/html, Size: 1587 bytes --]
On 2022-09-26 15:27, Vin Shelton wrote:
> If Google is your concern, put the text in your message, as an SEO would.
What's an SEO? Anyway I take your point. Saying 'solved' in the body
might be sufficient. People are after all more likely to be looking for
solved problems.
On Sun, Sep 25, 2022 at 3:46 PM Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> 0 /root/.config/geany/colorschemes 0 $ zkbd
> Enter current terminal type: [xterm-256color]
>
> We will now test some features of your keyboard and terminal.
>
> If you do not press the requested keys within 10 seconds, key reading will
> abort. If your keyboard does not have a requested key, press Space to
> skip to the next key.
>
> Hold down Ctrl and press X: ^X
>
> Your Meta key may have a Microsoft Windows logo on the cap.
> Hold down Meta and press X: x
> Your keyboard or terminal does not recognize the Meta key.
>
> Hold down Alt and press X: ^[x#
> 0 /root/.config/geany/colorschemes 0 $ 3:44PM Sun 25
> execute: _
THAT should not happen. It looks like something killed the function
and returned you to the top-level prompt. Here's what I get (starting
after identical preliminaries):
Hold down Meta and press X: x
Your keyboard or terminal does not recognize the Meta key.
Hold down Alt and press X: ^[x
---------
You are using zsh in MULTIBYTE mode to support modern character sets (for
languages other than English). To use the Meta or Alt keys, you probably
need to revert to single-byte mode with a command such as
unsetopt MULTIBYTE
(then more questions follow)
On 2022-09-26 17:30, Bart Schaefer wrote:
>
> You are using zsh in MULTIBYTE mode to support modern character sets (for
> languages other than English). To use the Meta or Alt keys, you probably
> need to revert to single-byte mode with a command such as
>
> unsetopt MULTIBYTE
>
> (then more questions follow)
>
I think for now I'm going to let sleeping dogs lie. 'showkey' reports
that the meta key does something so maybe I'll bring it to some use one
day but for now I have other irons in the fire. I haven't reinstalled
my system for several years and there's much to do.