Recent versions have cache update status presistently showing up

[Jai-JAP]

ble version: 0.4.0-devel4+b5938192 Bash version: 5.2.26(1)-release (x86_64-pc-linux-gnu)

GNU bash, version 5.2.26(1)-release (x86_64-pc-linux-gnu) [Manjaro Linux]
ble.sh, version 0.4.0-devel4+b5938192 (noarch) [git 2.43.2, GNU Make 4.4.1, GNU Awk 5.3.0, API 4.0, PMA Avon 8-g1, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
bash-completion, version 2.11 (hash:2d02f73e803daa87a06e94e33b2a7b3e672a2c0c, 76338 bytes) (noarch)
locale: LANG=en_IN.UTF-8
terminal: TERM=xterm-256color wcwidth=15.0-west/15.1-2+ri, vte:7402 (65;7402;1)

After updating ble.sh the recent versions show the cache update status persistently on the first run. Previously it showed up while preparing the cache and then returned normal which is just the prompt.

Same issue can be reproduced by deleting ~/.cache/blesh directory and starting a new terminal session.

I am not exactly sure whether the top line ble/term.sh updating tput cache for TERM=xterm-256color... done stayed after the cache refresh but the line after the bottom wasn't persistent before.

It was better when all the ble.sh init stuff was be above the prompt and I suggest adding a separator or making it completely disappear after initialization.

Thanks for this awesome project anyways. It makes my terminal bash setup more interactive than ever.

[akinomyoga]

Thanks for the report. I have to admit the latest push seems to be unstable.

The persistent line doesn't seem to reproduce in my environment, Fedora 39, bash-5.2.21.

Previously it showed up while preparing the cache and then returned normal which is just the prompt.

Yes, that's right.

I am not exactly sure whether the top line ble/term.sh updating tput cache for TERM=xterm-256color... done stayed after the cache

It's supposed to stay there. That's because moving the cursors and erasing the line depend on the terminfo database, but that line cannot depend on the terminfo database because it's the one to retrieve the necessary data from the terminfo database. It's the necessary bootstrap. Technically, it may be possible to retroactively erase the previous line after obtaining the terminfo database, but I'm comfortable with the current design as it seems natural.

It was better when all the ble.sh init stuff was be above the prompt and I suggest adding a separator or making it completely disappear after initialization.

I think it's not obvious to the users, but there is a "panel" below the command line in the ble.sh's layout model. Some additional context and information, such as completion candidates, the current mode, and other messages are all shown in that panel. In that sense, I still think it is natural to show the initialization messages there. Anyway, the initialization messages are supposed to disappear within less than a second in a typical system (such as Linux), so it shouldn't be so distracting in such a environment. We can discuss this point after fixing the persistent line.

---

Since I suspect this is a regression by a recent change, I would like to ask you about the previous version of ble.sh before the update, where the problem was not observed.

• Q1: Could you provide the first several lines in the output of the following command?

$ git -C "$_ble_base_repository" reflog

• Q1a: I'd appreciate it if you could bisect the commit that causes the persistent line observed in your environment.

edit:

• Q2: Could you tell me how you source ble.sh? Do you source ble.sh in a shell function? Do you redirect some streams when ble.sh is sourced? Where do you source ble.sh (at the top or the bottom of bashrc, etc.)?

[Jai-JAP]

Q1: Could you provide the first several lines in the output of the following command?

$ git -C "$_ble_base_repository" reflog

Q1a: I'd appreciate it if you could bisect the commit that causes the persistent line observed in your environment.

I installed blesh-git from AUR (I am on Manjaro) and have set it up to clean the sources after install. So I couldn't do the reflog. Is it required to keep the git repo even after installation?

Also for the bisect part. I am quite busy for a few days for University tasks. But I will give it a try later.

The regression might be quite a while ago as this is not the first time I have updated ble.sh and gotten this output.

Q2: Could you tell me how you source ble.sh? Do you source ble.sh in a shell function? Do you redirect some streams when ble.sh is sourced? Where do you source ble.sh (at the top or the bottom of bashrc, etc.)?

I have a custom.bashrc file that has all my customizations and is loaded at the end of distro provided bashrc. The contents of custom.bashrc are as follows

# customisations

if [[ $- == *i* ]]; then
  bind 'set completion-ignore-case on'
  shopt -s autocd
  shopt -s cdspell
  shopt -s dirspell
  shopt -s expand_aliases
  set -C

  HISTCONTROL=ignoreboth

  if [[ $EUID == 0 ]]; then
    PS1='${SUDO_USER:+(\033[01;33m$SUDO_USER\033[0m) }\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] \n \[\033[01;31m\]\$_\[\033[00m\] '
  else
    PS1='\[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\] \n \[\033[01;32m\]\$_\[\033[00m\] '
  fi

  if [[ "$PREFIX" =~ "com.termux" ]]; then
    . "$HOME/.local/share/blesh/ble.sh"
  elif [[ "$TERM_PROGRAM" != "vscode" ]]; then
    . "/usr/share/blesh/ble.sh"
  fi
fi

My .blerc

if [[ "$TERM_PROGRAM" != "vscode" ]]; then
  if [[ ! "$PREFIX" =~ "com.termux" ]]; then
    ble-import contrib/prompt-git
    bleopt prompt_rps1='\q{contrib/git-branch} \q{contrib/git-hash}'
  fi

  ble-bind -f 'C-h' delete-backward-cword
  ble-bind -m emacs -f 'C-w' ''
else
  ble-bind -m emacs -f 'C-w' delete-backward-cword
fi

bleopt edit_vbell= decode_error_char_vbell= decode_error_cseq_vbell= decode_error_kseq_vbell=
ble-face -s auto_complete fg=240

[Jai-JAP]

The issue is slightly different on Termux tho.

Notice the line before the prompt printing twice and the line after the prompt does disappear.

Both installations have the same config files.

Version info for termux installation.

GNU bash, version 5.2.26(1)-release (aarch64-unknown-linux-android)
ble.sh, version 0.4.0-devel4+b593819 (noarch) [git 2.43.2, GNU Make 4.4.1, GNU Awk 5.3.0, API 4.0, (GNU MPFR 4.2.1, GNU MP 6.3.0)]
bash-completion, version 2.11 (hash:9a8f685429d733bbb374bae7f8d22c3541200dfd, 76363 bytes) (noarch)
locale: LANG=en_US.UTF-8
terminal: TERM=xterm-256color wcwidth=14.0-west/15.1-2+ri, xterm:320 (41;320;0)

[akinomyoga]

I installed blesh-git from AUR (I am on Manjaro) and have set it up to clean the sources after install. So I couldn't do the reflog.

Ah, I see. I haven't thought about that case.

Is it required to keep the git repo even after installation?

No, it's actually not.

However, if a user installs ble.sh by git clone & make install, even if a user removes the original repository, ble.sh will clone the repository in its installation directory (such as ~/.local/share/blesh/src) when the user runs ble-update. In the case of the AUR helper, I think the repository is always removed, but it's not a problem.

The regression might be quite a while ago as this is not the first time I have updated ble.sh and gotten this output.

OK, so it's not related to the latest push.

The contents of custom.bashrc are as follows

Thanks for the contents of ~/.bashrc and ~/.blerc. I tried your settings, but the problem still doesn't seem to reproduce in my environment.

---

The issue is slightly different on Termux tho.

Notice the line before the prompt printing twice and the line after the prompt does disappear.

This is still an expected behavior. The duplication happens just because the width of the terminal is narrow, so the line is wrapped. Then, ble.sh reprints the line. This is again pre-initialization of the terminfo database, so ble.sh doesn't try to adjust it.

[Jai-JAP]

So the termux seems to have no issues

Does my terminal matter in this case? I use GNOME Console but will try with other terminals later.

[akinomyoga]

Does my terminal matter in this case? I use GNOME Console but will try with other terminals later.

I tried GNOME Terminal in two different systems with the settings you provided, but the problem doesn't seem to reproduce there.

[Jai-JAP]

Does my terminal matter in this case? I use GNOME Console but will try with other terminals later.

I tried GNOME Terminal in two different systems with the settings you provided, but the problem doesn't seem to reproduce there.

Gnome terminal is a different thing. I use GNOME Console.

[akinomyoga]

Hmm, OK. I actually don't think it is related to the terminal, but let me check GNOME Console.

[akinomyoga]

I installed GNOME Console 45.0 and tried it with your settings, but the problem doesn't reproduce. The messages of the cache initialization disappear after a few seconds.

(I was first confused by the fact that there doesn't seem to be any binary named gnome-console or console, but I checked the file list of the package and found that a binary kgx is installed. So I tried kgx assuming this is the binary of GNOME Console. Is this the correct one?)

but will try with other terminals later.

Have you tried other terminals?

[Jai-JAP]

I installed GNOME Console 45.0 and tried it with your settings, but the problem doesn't reproduce. The messages of the cache initialization disappear after a few seconds.

(I was first confused by the fact that there doesn't seem to be any binary named gnome-console or console, but I checked the file list of the package and found that a binary kgx is installed. So I tried kgx assuming this is the binary of GNOME Console. Is this the correct one?)

but will try with other terminals later.

Have you tried other terminals?

Yeah kgx is the correct binary.

I didn't get spare time to try that out. I'll try to get more info on this after I get some free time.

[Jai-JAP]

Looks like its solved in the latest revision. However I don't know what had caused it. Closing this as it is no longer reproducible. I'll try to bisect and identify the faulty commit later.

Thanks for the quick response.

[akinomyoga]

Hmm, I don't have an idea for now why it was caused. As far as I remember, I haven't touched anything related to the rendering of the message recently, but maybe I missed something. Anyway, thank you for raising the issue! If you could manage to bisect the culprit commit (or the fixing commit), the information is welcome!