Atuin, bash, and ble.sh

[tessus]

@akinomyoga

For this reason, a complicated PR like rcaloras/bash-preexec #143 that is unlikely to get a review from third-party voluntary people is unlikely to be merged. I’m recently one of third-party reviewers, but I’m not fully convinced by both versions of ignoreboth workarounds so hesitate to approve either one.

What is the solution?

e.g. can I just revert Remove ignorespace from $HISTCONTROL · rcaloras/bash-preexec@3458480 · GitHub and Follow up commit for issue #6 · rcaloras/bash-preexec@7e55ac1 · GitHub and all is good again? I mean before these changes, preexec did not ignore the HISTCONTROL, correct?

@akinomyoga

The bash-preexec project seems to require a third person to approve the PR.

Hmm, but isn’t an approval only valid when it is done by the owner or collaborator? (grey check mark vs a green check mark.)

[akinomyoga]

@tessus

What is the solution?

There is no perfect solution that fully satisfies the expectations of applications that use preexec for different purposes. At least, it’s not known.

However, for a specific case (such as history recording), we may have a workaround to satisfy the limited expectation.

@tessus

e.g. can I just revert Remove ignorespace from $HISTCONTROL · rcaloras/bash-preexec@3458480 · GitHub and Follow up commit for issue #6 · rcaloras/bash-preexec@7e55ac1 · GitHub and all is good again?

I think that that mostly works in your case (except for the command duration) as far as you wouldn’t introduce another framework relying upon bash-preexec.

@tessus

Hmm, but isn’t an approval only valid when it is done by the owner or collaborator? (grey check mark vs a green check mark.)

The grey one is considered a valid review too by the maintainer, I guess.

edit: To make it more precise, I vaguely feel the rough role separation of (1) the owner @rcaloras, (2) the PR submitter, and (3) the others including both the other maintainer @dimo414 and outsiders. But it’s actually not so strict.

[tessus]

@akinomyoga

If you still have the energy to look into that, you can simply use the integration settings provided by ble.sh instead of (directly) sourcing those three files. In your case, you can have a switch for the blesh’s integration in your /etc/bashrc.

if [[ ${BLE_VERSION-} ]]; then
  ble-import -d integration/fzf-completion
  ble-import -d integration/fzf-key-bindings
else
  [ -f /etc/bash_completion.d/fzf ] && . /etc/bash_completion.d/fzf
  [ -f /usr/share/fzf/shell/key-bindings.bash ] && . /usr/share/fzf/shell/key-bindings.bash
fi
[ -f /opt/completion/fzf_git.sh ] && . /opt/completion/fzf_git.sh

Please make sure to source ble.sh before sourcing /etc/bashrc in your ~/.bashrc so that BLE_VERSION is visible from /etc/bashrc when ble.sh is loaded.

I tried your changes for ble.sh, but there is still one last issue:

When I press ctrl+r, the fzf key-binding wins, even though the atuin eval runs after the ble-import.

If I comment out this line, the atuin tui shows up, when pressing ctrl+r:

#ble-import -d integration/fzf-key-bindings

[akinomyoga]

@tessus

When I press ctrl+r, the fzf key-binding wins, even though the atuin eval runs after the ble-import.

Ah, that is because of the option -d specified to ble-import. When -d is specified, ble-import defers the loading of the file. The loading of the file is registered to the background task list, and it will be run in the background after the line editor is ready.

You can simply omit -d in ble-import. Or the Atuin initialization may also be performed in the background by

ble/util/idle.push 'eval "$(atuin init bash)"'

[akinomyoga]

Anyway, thank you for testing!

[tessus]

@akinomyoga

You can simply omit -d in ble-import.

Thanks that did the trick.

There was no performance difference between omitting -d and pushing it to the background. Btw, if I use ble/util/idle.push for starship, it is never initialized and my old prompt appears. This is mot important, I just wanted to mention it.

I’m currently using ble.sh with a minimal config. I am quite happy with it. Thanks.

But I am rather annoyed (not your fault) by the fact that all these evals (ble, startship, atuin, …) take quite some time in total. They add up. When I now open an iTerm it takes almost a second before the prompt shows up.

[akinomyoga]

@tessus

if I use ble/util/idle.push for starship, it is never initialized and my old prompt appears

I think the prompt setting by Starship will apply after running the first user command.

This is because the background processing is performed in the idle time while waiting for the user’s inputs after the first prompt is shown. The prompt settings PS1, etc. are only reflected in the first prompt evaluation after setting them.

What can be deferred is initializations related to aliases, keybindings, and completions that are unlikely to be used immediately after the prompt appears (like within 0.5 seconds).

Anyway, I think I’ll later update the documentation to clarify those matters.

@tessus

I’m currently using ble.sh with a minimal config.

I think you can use bash-preexec with the patch I submitted upstream. Ah, but there are also other unmerged fixes for HISTCONTROL.

@tessus

They add up. When I now open an iTerm it takes almost a second before the prompt shows up.

Yeah, it is inevitable, but one second seems admittedly long. Anyway, the initialization time with ble.sh seems to largely depend on the environment.

I measured it in my environment (Fedora 39) with ble.sh (vi mode + extra settings) + starship + fzf (deferred) + atuin (deferred). It was 0.40s from the first line of bashrc to the first prompt, and additional 0.42s to start processing the user’s input. It took even additional 0.55s to complete all the background initialization, though it is invisible to the user. For reference, with plain ble.sh, they were 0.19s / 0.05s / 0.14s.

[tessus]

Yea, the ble init takes on my MacBook around 140-160ms. But with all the other stuff I’m close to a second. So it certainly is not ble’s fault…

850-900ms is not a long time, but it’s a noticeable lag that annoys me greatly, but I also understand that there is no way to fix this.

[agentofchaos-rsc]

Hey, sorry to revive this old thread. Apparently I am having the same issue with ble.sh as you. You mentioned in previous messages that you have been using some minimal configuration of ble. Could you mind sending that, it would help a lot.

[tessus]

My .blerc currently looks like this:

# Disable syntax highlighting
bleopt highlight_syntax=

# Disable highlighting based on filenames
bleopt highlight_filename=

# Disable highlighting based on variable types
bleopt highlight_variable=

# Disable auto-complete (Note: auto-complete is enabled by default in bash-4.0+)
bleopt complete_auto_complete=
# Tip: you may instead specify the delay of auto-complete in millisecond
#bleopt complete_auto_delay=300

# Disable auto-complete based on the command history
bleopt complete_auto_history=

# Disable ambiguous completion
bleopt complete_ambiguous=

# Disable menu-complete by TAB
#bleopt complete_menu_complete=

# Disable menu filtering (Note: auto-complete is enabled by default in bash-4.0+)
bleopt complete_menu_filter=

# Disable EOF marker like "[ble: EOF]"
bleopt prompt_eol_mark=''
# Tip: you may instead specify another string:
#bleopt prompt_eol_mark='⏎'

# Disable error exit marker like "[ble: exit %d]"
bleopt exec_errexit_mark=
# Tip: you may instead specify another string:
#bleopt exec_errexit_mark=$'\e[91m[error %d]\e[m'

# Disable elapsed-time marker like "[ble: elapsed 1.203s (CPU 0.4%)]"
#bleopt exec_elapsed_mark=
# Tip: you may instead specify another string
#bleopt exec_elapsed_mark=$'\e[94m[%ss (%s %%)]\e[m'
# Tip: you may instead change the threshold of showing the mark
#bleopt exec_elapsed_enabled='sys+usr>=10*60*1000' # e.g. ten minutes for total CPU usage

# Disable ble exit marker
bleopt exec_exit_mark=

I have to say though that many of these features are actually quite nice. It’s just that they are distracting when you are not used to them and can also be a bit overwhelming, which is why I have deactivated them. But I might start using them one after one and see, whether I’ll keep them active.

[agentofchaos-rsc]

Thanks , that was very helpful.
I know some of the features might be very useful, but for now I dont think I just need them.
I changed my blerc to yours, apparently its still taking < 650 miliseconds for initializing ble.
I guess I have to look for some more optimizations.