0.15.0 adds -v to the ls aliases on linux/gnu coreutils.
ls -v ignores locale and sorts things quite differently (upper case letters before lower case, letters with and without diacritics not together etc).

Notice: no deltochar available :(
Notice: no mathfunc available :(
root@turris ~ #

It would be nice to have an option to suppress such warnings. There's nothing I can do about these missing modules as the OS I'm running grml-zsh-config on is OpenWRT.

OS: Debian sid
Zsh version: 5.7.1

First, the LANG variable was set as "zh_CN.UTF-8".

On Bash and Zsh without the config, all the locale variables (such as LC_CTYPE and LC_TIME) can be set as "zh_CN.UTF-8".

but when I add the Zsh config, only the LANG variable was set, and others are "C".

Confusingly, the problem can not happen on Ubuntu.

When I cd into a deeply nested NFS mount the current path is somehow broken via the VCS module.

[root@client] ~ # showmount -e server
Export list for server:
/mnt/storage/share/Pictures     192.168.0.99
/mnt/storage/share/Programs     192.168.0.99
/mnt/storage/share/Downloads    192.168.0.99
/mnt/storage/share/Books        192.168.0.99
/mnt/storage/share/Clips        192.168.0.99
/mnt/storage/share/Music        192.168.0.99
/mnt/storage                    192.168.0.99

(The nested exports are because those are BTRFS subvolumes which require manually setting fsids)

[root@client] ~ # cd /mnt/server/share/Music/X-Mas

[root@client] /mnt/server/share/Music/X-Mas # /bin/ls
bin  boot  checkout  dev  esp  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

[root@client] /mnt/server/share/Music/X-Mas # /bin/ls $PWD
'Die Stars Der Hitparade Feiern Weihnachten (2009)'  'RTL Weihnachten 2008'  'The Ultimate Christmas Music Collection'  'Various Artists'
'Frank Schöbel'                                      'Roland Kaiser'         'Top Christmas Songs of All Time'          'von Wilfried'

You can clearly see the difference between ls and ls $PWD, which should not exist.

Removing the VCS module from :prompt:grml:left:setup fixes this, but I can't determine why it happens in the first place.

VTE (which is the base of many Linux terminal emulators like GNOME Terminal, Terminator, Xfce Terminal, etc.) now supports identifying prompts using OSC codes, and therefore jumping between prompts in the terminal output. This is quite useful when lookup back through commands with voluminous output, as you can just press CtrlShift← to jump directly to the previous prompt (and so the start of the output). For this, the /etc/profile.d/vte.sh file adds some customization to PS1, which is naturally lost when using the grml themes:

# Enclose the primary prompt between
# ← OSC 133;D;retval ST (report exit status of previous command)
# ← OSC 133;A ST (mark beginning of prompt)
# → OSC 133;B ST (mark end of prompt, beginning of command line)
# [snip]
PS1=$'%{\e]133;D;%?\e\\\e]133;A\e\\%}'"$PS1"$'%{\e]133;B\e\\%}'

I can work around this by doing something like:

zstyle ':prompt:grml:*:items:user' pre $'%{\e]133;D;%?\e\\\e]133;A\e\\%}'
zstyle ':prompt:grml:*:items:sad-smiley' post $'%{\e]133;B\e\\%}%f'

But it would be nice if these could be added by GRML itself, maybe as a configurable theme item.

Looking at it a bit more, something like this seems to be more in the spirit of things:

__vte_prompt_start () {
	if [[ ${VTE_VERSION:-0} -ge 7600 ]]
	then
		REPLY=$'%{\e]133;D;%?\e\\\e]133;A\e\\%}'
	fi
}
__vte_prompt_end () {
	if [[ ${VTE_VERSION:-0} -ge 7600 ]]
	then
		REPLY=$'%{\e]133;B\e\\%}'
	fi
}
grml_theme_add_token prompt_start -i __vte_prompt_start '' ''
grml_theme_add_token prompt_end -i __vte_prompt_end '' ''
zstyle ':prompt:grml:left:setup' items prompt_start rc user at host path vcs percent
zstyle ':prompt:grml:right:setup' items sad-smiley prompt_end

Would it be fine to make a PR adding tokens like these?

I use grml zsh config in my debian, It's so cool.
But when I install silver_searcher-ag.
The cmd ag alread alias apt-get upgrade in debian.

If you don't wanna change, ignore this issue.

The silver_searcher
https://github.com/ggreer/the_silver_searche
A code searching tool similar to ack, with a focus on speed.

A recent update on Arch Linux has caused the following warnings to appear directly after issuing a prompt command:

% prompt adam1 yellow 
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/%(K{ <-- HERE .*?}|k)/ at -e line 1.
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/%(K{ <-- HERE .*?}|k)/ at -e line 1.

Arch runs version 0.12.1 of grml-zsh-config.

I believe this warning coinsided with the perl 5.20.2 -> 5.22.0 update but I cannot be sure.

jkirk@executor ~ % echo https://github.com/grml/grml-etc-core/blob/24e8d3be9f59a015d4292b09beb38ea707a260be/etc/zsh/zshrc#L1577
zsh: no matches found: https://github.com/grml/grml-etc-core/blob/24e8d3be9f59a015d4292b09beb38ea707a260be/etc/zsh/zshrc#L1577
jkirk@executor ~ % url-quote                                                      
jkirk@executor ~ % echo https://github.com/grml/grml-etc-core/blob/24e8d3be9f59a015d4292b09beb38ea707a260be/etc/zsh/zshrc#L1577
zsh: no matches found: https://github.com/grml/grml-etc-core/blob/24e8d3be9f59a015d4292b09beb38ea707a260be/etc/zsh/zshrc#L1577

(Please note: you have to paste the URL after each echo. Do not use your history to reuse the command.)

According to sorin-ionescu/prezto#978 and https://github.com/zsh-users/zsh/blob/master/Functions/Zle/url-quote-magic#L11 the fix is simple:

alias url-quote='autoload -Uz url-quote-magic bracketed-paste-magic; zle -N self-insert url-quote-magic; zle -N bracketed-paste bracketed-paste-magic'

With this the URL is quoted automatically:

% url-quote
% echo https://github.com/grml/grml-etc-core/blob/24e8d3be9f59a015d4292b09beb38ea707a260be/etc/zsh/zshrc\#L1577
https://github.com/grml/grml-etc-core/blob/24e8d3be9f59a015d4292b09beb38ea707a260be/etc/zsh/zshrc#L1577

In our grml-zshrc we have:

# If a new command line being added to the history list duplicates an older
# one, the older command is removed from the list
is4 && setopt histignorealldups

This causes the following behavior in zsh history:

root@grml ~ # echo foo
foo
root@grml ~ # echo bar
bar
root@grml ~ # history -E 0
    1  14.10.2020 15:48  exec zsh
    2  14.10.2020 15:48  echo foo
    3  14.10.2020 15:48  echo bar
root@grml ~ # echo foo
foo
root@grml ~ # history -E 0
    1  14.10.2020 15:48  exec zsh
    3  14.10.2020 15:48  echo bar
    5  14.10.2020 15:48  echo foo

So the 2nd issue from the zsh history got removed, this is expected with histignorealldups being set.

But this means it's hard to reconstruct the order of commands that have been executed.

If we'd unset histignorealldups by default, the behavior would be instead:

root@grml ~ # setopt nohistignorealldups
root@grml ~ # echo foo
foo
root@grml ~ # echo bar
bar
root@grml ~ # echo foo
foo
root@grml ~ # history -E 0
    1  14.10.2020 15:49  exec zsh
    2  14.10.2020 15:50  setopt nohistignorealldups
    3  14.10.2020 15:50  echo foo
    4  14.10.2020 15:50  echo bar
    5  14.10.2020 15:50  echo foo

This indeed isn't so nice when browsing through history (e.g. via <cursor-up> since then you have all the duplicates), but instead it gives a better/full picture of what has been executed, which is especially useful for sysadmins IMO. I'm therefore suggesting to use setopt nohistignorealldups by default in grml-zshrc.

Opinions? /cc @grml/team-grml-developers

FTR, I'm not really sure what this completion setting is for:

    # ignore duplicate entries
    zstyle ':completion:*:history-words'   remove-all-dups yes
    zstyle ':completion:*:history-words'   stop yes

@ft maybe you could enlighten me here? Maybe you also have any further ideas how to improve our grml-zshrc to get (closer to) the behavior I'm proposing? :)

After upgrading my setup from v0.16.0 to v0.19.6 Vim does not evaluate modelines anymore. I have lines from Kconfig or Make files like those:

# vim: ft=kconfig noet tw=72 ts=8 sw=8

or

# vim: ft=make noet tw=72 ts=8 sw=8

When switching back and forth between the above mentioned versions of grml-etc-core the Vim 8.2 of my venerable Debian GNU/Linux 11 (bullseye) considers the modeline when starting Vim or not. Manually entering those things in Vim with :set … works as expected.

I have some things in ~/.vimrc.local but I can not see if they are related. (It's public here.)

I'm using the grml vimrc like this: I have a symlink ~/.vimrc to grml-etc-core/etc/vim/vimrc …

Maybe related to #92 which was a major rework?

Hello, I am packaging grml-zsh-config for Voidlinux and I have noticed that https://deb.grml.org/pool/main/g/grml-etc-core/grml-etc-core_0.18.0.tar.gz has vanished. This is not the first time this has happened. The 0.17.4 version has also disappeared from the pool. Why is this happening? Package build fails with Not found because of this.

Let the following prompt:

$ $(foo) bar
       ^

where ^ indicates the cursor position. When inserting | followed by space, the resulting prompt is the following:

$ $(foo| )
         ^

This demonstrates that editing the command line might result in losing a significant part of the command.

GRML revision: af65087
zsh version: zsh 5.4.2 (x86_64-debian-linux-gnu)
Distribution: Debian GNU/Linux testing (buster)

Our __start_stop function, which is used as helper function within our Start, Stop, Restart,... functions doesn't provide native support for systemd. While usage of service still works, it would be nice if we could support systemctl usage.

Also our _grmlinitd function doesn't complete systemd unit files, but only init scripts. This means that e.g. Start N<tab> doesn't detect/complete NetworkManager.service, as the network-manager Debian package ships a systemd unit file but not an init script.

Currently zshrc sets a number of useful aliases, including color output for ls and grep if available.
I would like an alias for ip (from iptoute2) to be introduced, it supports the same option --color=auto since May 2015 and release 4.1.0.

I'm using grml-zsh-config from Arch repo grml-zsh-config 0.16.1-1.

ESC-e: Edit the current line in$EDITOR works in emacs mode but not in vi mode.

I am having an issue with the zshrc config. It seems that the autocompletion for mount is broken?

Steps to reproduce:

mkdir test && cd test
touch archlinux-2018.07.01-i686.iso
touch archlinux-2019.03.01-x86_64.iso
mount ./arch<tab> # completes to: mount ./archlinux-201.0.01-<|>.iso, where <|> is the cursor

https://asciinema.org/a/A28U4Snpkv4qFDEsXIlRzmnuT

In situations where the hosts file is used for ad/malware blocking (e.g. utilizing Steven Black's hosts file), grml-zshrc's generation of _etc_hosts can severely impact performance, especially on underpowered systems with low-end CPUs and HDDs, leading to very long loading times for the shell.

It would be nice if grml-zshrc ignored setting up _etc_hosts if it was too big (>1MiB maybe?) or allowed for it to be disabled through .zshrc.pre.

Once a decision is reached, I can make a simple PR with that

% prompt -h grml
[...]
    The actual configuration is done via zsh's `zstyle' mechanism. The
    context, that is used while looking up styles is:

        ':prompt:grml:<left-or-right>:<subcontext>'

    Here <left-or-right> is either `left' or `right', signifying whether the
    style should affect the left or the right prompt. <subcontext> is either
    `setup' or 'items:<item>', where `<item>' is one of the available items.

    The styles:

        - use-rprompt (boolean): If `true' (the default), print a sad smiley
          in  if the last command a returned non-successful error code.
          (This in only valid if <left-or-right> is "right"; ignored otherwise)
[...]

But trying to do so does not disable the right prompt / sad smiley:

jkirk@executor ~ % /bin/false
1 jkirk@executor ~ % zstyle ':prompt:grml:right:setup' use-rprompt false           :(
jkirk@executor ~ % zstyle -T ':prompt:grml:right:setup' use-rprompt
1 jkirk@executor ~ %                                                              :(

The current workaround is this:

jkirk@executor ~ % zstyle ':prompt:grml:right:setup' items
jkirk@executor ~ % /bin/false
1 jkirk@executor ~ % 

(Putting zstyle ':prompt:grml:left:setup' use-rprompt false in ~/.zshrc.local works.)

New version of grep (3.8) shows a warning

grep: warning: stray \ before 0

Obviously there is a typo here

0\.0\.0.\0

I think intended code should be

0\.0\.0\.0

When starting tmux in the current Grml daily ISO the following error message is shown:

/etc/tmux.conf:19: unknown key: confirm-before

The latest Grml daily ISO ships tmux 3.1b-1. In Debian/buster where tmux 2.8-3 is used the error is not shown with the very same configuration file.

We ran into this problem on a customer system, where a NFS mountpoint was referenced in the .zdirs file (via DIRSTACKFILE feature enabled by default), while the NFS share wasn't available when trying to login via SSH. Only once the zdirs file got updated/removed, we could login via ssh to our ZSH again.

We need to ensure that the default behavior of grml-zshrc can't cause such a behavior, reporting to not forget about it. :)

Hi,

Starting a xterm window that is relatively narrow causes errors to be printed on screen before the prompt.

troff: <standard input>:37: warning [p 1, 8.3i]: cannot adjust line
troff: <standard input>:65: warning [p 2, 4.7i]: cannot adjust line
troff: <standard input>:69: warning [p 2, 5.7i]: cannot adjust line
troff: <standard input>:69: warning [p 2, 5.8i]: cannot adjust line
troff: <standard input>:69: warning [p 2, 6.0i]: cannot adjust line
troff: <standard input>:166: warning [p 5, 1.5i]: cannot adjust line
troff: <standard input>:166: warning [p 5, 1.7i]: can't break line
troff: <standard input>:171: warning [p 5, 3.5i]: cannot adjust line
troff: <standard input>:176: warning [p 5, 5.3i]: can't break line

I have not found one reference to troff in /etc/zsh/* so I'm not sure where to look.

OpenSSH 9.0 changed the default scp protocol from scp to sftp. This also changes how remote path have to be quoted and leads to broken autocompletion on Arch Linux where OpenSSH 9.0 is already the default. Example:

% touch test\ a
% scp test\ a remote:
test a                                                                                                                       100%    0     0.0KB/s   00:00    
% scp test\ a remote:test\\\ a #with tab completion
test a                                                                                                                       100%    0     0.0KB/s   00:00    
% ssh remote ls
test a
test\ a

This also affects rsync completion.

I'm proposing to disable our smiley which appears if exit code != 0 on the right side of the prompt, like:

mika@lunge /tmp/tmp.kvMVtGqka4 % false
1 mika@lunge /tmp/tmp.kvMVtGqka4 %                                                          :(

IMO it's totally annoying for c/p.
I'm aware that users can control this behavior via:

# disable smiley
zstyle ':prompt:grml:right:setup' use-rprompt false

... in their personal zsh configuration, but I'd prefer to disable this by default, so folks don't have to manually remove it in c/p for docs etc.

If someone objects, please speak up! :)

See my hints:
flobee@a9e10c8

downloaded zshrc files from https://grml.org/zsh/ this way:

# IMPORTANT: please note that you might override an existing
# configuration file in the current working directory! =>
wget -O .zshrc https://git.grml.org/f/grml-etc-core/etc/zsh/zshrc

# Optionally also grab the user configration:
# wget -O .zshrc.local  https://git.grml.org/f/grml-etc-core/etc/skel/.zshrc

Edit in kate and kate says: BOM exists and Line 335 (#getanchors) look damaged.
But the browser tell also weired chars.: https://github.dev/grml/grml-etc-core/blob/master/etc/skel/.zshrc#L335C40-L335C47

Version: 0.17.0
zsh: 5.8
Reproduce step:

git clone --bare --depth=1 https://github.com/grml/grml-etc-core
cd grml-etc-core.git

get following error after refresh prompt

fatal: this operation must be run in a work tree

zshrc unconditionally exports COLORTERM=yes. I can see the use case for setting it if the variable is missing.

However many terminal emulators set COLORTERM=truecolor. zshrc shouldn't overwrite this.

Last week, I deleted my root file system (/) by issuing an rm -rf * in
a zsh with grml config. I am reporting this here, because I could not reproduce
the issue with a plain zsh (zsh -f) or with a plain bash.

Here is what I did:

1. Insert a USB drive/SD card into the system
2. Gnome automounts it in /run/media/<username>/<partition>
3. Navigate in a zsh into that folder (cd /run/media/<username>/<partition>)
4. Remove the USB drive/SD card physically from the system
5. Gnome unmounts it automatically
   5.1 (optional) plug the drive back in, doesn't really matter
6. Enter pwd into the open zsh (in the now unexisting folder)
   -> output will be /run/media/<username>/<partition>
7. Enterls
   -> Prints the content of /
8. Enter echo *
   -> Prints the content of /
9. DO NOT DO THIS ON A LIVE SYSTEM!!!: Enter sudo rm -rf *
   -> Deletes your whole root file system

Basically zsh (with grml config) tells you in the prompt, in pwd and
in $PWD that you are in the mounted drive while all commands are
executed with / as working directory.

In my case the mounted drive was another linux root file system so doing
ls did show a root fs as expected, but it was my own one, not the one
of the USB drive.

Other shells (plain zsh and bash) raise errors on ls instead of
silently redirecting to / and also do not expand the * to all files in /.

I hope you can track down this bug, as it is extremely dangerous and
destroys all confidence in what the shell shows me...

After some years I got a bit bored with the prompt and wanted to try a "new" one, so I have:

autoload -Uz promptinit && promptinit
unset PS1 PROMPT
PS1='%B%(!.%F{red}%n%f.%F{green}%n%f)%F{white}@%f%F{green}%m%f %40<..<%~%<< %(!.%F{red}# %f.%F{green}$ %f)%b'
PROMPT="$PS1"

in ~/.zshrc
But the prompt doesn't change! Only if I mv/rm /etc/zsh/zshrc, then my changes are applied.
AFAIK ~/.zshrc is sourced after /etc/zsh/zshrc, so am wondering why the system file is overriding my local user settings.
Or should I change it through the zstyle ':prompt:grml:...' , given I have no clue how to do it that way.
I tried exporting only PS1, then PROMPT, then both. Still no change :(

zsh v5.8
grml-zsh-config v0.17.4

Hi,

Zsh does not delete duplicate commands anymore if the option HISTCONTROL=ignoreboth is present in .zshrc.

This problem appeared with version grml-zsh-config-0.19.0-1.
Version grml-zsh-config-0.18.0-1 is OK.

Regards.

After updating to zsh 5.7 on macOS 10.14.3 via Homebrew, I am now getting the following warning in the terminal after every command:

VCS_INFO_detect_p4:79: maximum nested function level reached; increase FUNCNEST?

It does not display, however, if I'm in a folder which is a Git repository, for example. Too deep recursion somewhere perhaps?

FUNCNEST is 500 on my system by default. Increasing it to, say, 800 crashes zsh (terminal window suddenly closes).

Reproduced with the latest .zshrc from grml-zsh-config with empty .zshrc.local.

Would be nice to get support for what's mentioned by Vincent at https://vincent.bernat.ch/en/blog/2019-zsh-async-vcs-info in our grml-zshrc

Forwarding this from a personal mail I received:

Could you make it possible to shorten the prompt paths in grml zsh?
For inspiration, please look at a plugin from oh-my-zsh:
https://github.com/robbyrussell/oh-my-zsh/tree/master/plugins/shrink-path

We cut the path at 40 characters already, if that would be more configurable and possibly also support a zstyle setting to use something like in the shrink-path plugin (without having to use oh-my-zsh :)) that might be indeed nice.

If someone knows how to properly do that, I'd be more than happy to accept patches. :)

I am using Arch Linux with systemd and have downloaded the .zshrc config from here.

It was shown a warning, that "hostname" was not found, which is true, because it is not installed. And because i did not want to install another package, I have "fixed" this on my machine by replacing

$(hostname)

with

$(hostnamectl --static)

I would appreciate, if you could add a check for hostname and hostnamectl.

I use grml-zshrc as /etc/zsh/zshrc. If I state in my $HOME/.zshrc

autoload bashcompinit
bashcompinit

I still don't get the complete-command.

Hello,
I added the grml-zsh-config as my .zshrc file. However, as soon as I open a new terminal, all of my previous commands are gone. None of my previous command line entries are saved, and that's a huge detriment as I use zsh-autosuggestions. Is this an issue others have reported, or is there something extra I need to do?

I need to modify few default tokens (items) and add new, for example:

'%n ' (extra-space) instead of '%n' for user.

Each of the 2 commands below is giving me the same the desired effect (added to ~/.zshrc.local):

Modify item:

zstyle ':prompt:grml:*:items:user' token '%n '
or
grml_prompt_token_default[user]='%n '

Add new:

zstyle ':prompt:grml:*:items:window' token 'window '
or
grml_theme_add_token window 'window '

Which option from above [grml_* or zstyle) is preferred (assuming, each give the same result)?

On a custom Grml ISO build as of today with most recent grml-etc-core and vim-tiny package only (so not vim/vim-runtime)

% vim /some/file
Error detected while processing /usr/share/vim/vimrc:
line   30:
E319: Sorry, the command is not available in this version: let g:skip_defaults_vim=1
% ls -la /usr/share/vim/vimrc
lrwxrwxrwx 1 root root 14 May 12 02:37 /usr/share/vim/vimrc -> /etc/vim/vimrc

For most zstyles, I can set them any time and then they apply.

But in d005e0b, the if zstyle -T ':grml:chpwd:dirstack' enable is on the top-level of .zshrc, so it will only be read once at the time of .zshrc evaluation:

I believe this means that it must be done in .zshrc.pre; later invocations setting that zstyle will have no effect at all.

Is this correct?

If yes, could it be changed such that zstyle ':grml:chpwd:dirstack' enable false works also in the user's normal .zshrc.local?

If not, it might make sense to extend the explanation in d005e0b#diff-0e012aed4e549254b0e807a707638324d4a262e96dc61bdcf75f10c6b17ce017R139 to explain this restriction.

I have a systemd automount, which is an external USB drive and thus not always available. If I have switched to the mount point recently and it is listed in .zdirs, but currently the drive is not available, zsh hangs while loading /etc/zsh/zshrc.

I assume this should also work with any other directories which are not available anymore.

How to reproduce

1. Create an automount for /mnt/usb
2. cd /mnt/usb
3. Close the terminal
4. Umount /mnt/usb and unplug the device
5. Start a new terminal and load the profile from /etc/zsh/zshrc

Expected behavior

The script should detect that /mnt/usb is no longer available and skip calling cd /mnt/usb.

Actual behavior

In line 1625 of the profile file, cd /mnt/usb is called. The call hangs because the device is longer available. Even after the automount times out, the terminal still doesn't finish loading the profile.

When running multiline commands in urxvt, parts of the command are re-echoed.

Example:

me@system ~/foo % ls \
\`> -l

-ltotal 0
-rw-r--r-- 1 me users 0 Feb 27 20:36 bar1
-rw-r--r-- 1 me users 0 Feb 27 20:36 bar2
me@system ~/foo %

Note the '-l' be re-echoed in front of 'total'.

After some debugging it turned out that the problems is in the function info_print() which is called by set_title(). urxvt seems to wrongly handle the newline character. A fix would be to replace line 2484 in zshrc which is

printf '%s' "$*"

with

printf '%s' "${*//[$'\n']}"

Since this problem seems to be limited to urxvt, this might be something which need to be actually fixed in urxvt. I just wanted to bring it up here. Others seem to have come across the same issue:
https://stackoverflow.com/questions/16120888/grmls-zsh-config-multiline-command-re-echoing

Noted on a currenty grml64-small unstable daily ISO:

root@grml ~ # vim foo
E1187: Failed to source defaults.vim
Press ENTER or type command to continue

FTR:

root@grml ~ # dpkg --list vim-\* grml-etc-core 
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
+++-==============-============-============-==================================================
ii  grml-etc-core  0.19.2       all          core etcetera files for the Grml system
ii  vim-common     2:8.2.4793-1 all          Vi IMproved - Common files
un  vim-gtk3       <none>       <none>       (no description available)
un  vim-motif      <none>       <none>       (no description available)
un  vim-nox        <none>       <none>       (no description available)
ii  vim-tiny       2:8.2.4793-1 amd64        Vi IMproved - enhanced vi editor - compact version
root@grml ~ # grml-version 
grml64-small_sid build3874 Release Codename autobuild-build3874 [2022-07-11]

When I press "Ctrl e", there is a delay before positioning on the last character.
"Ctrl a" works normally.

grml-zsh-config 0.14.2 from Arch.