Improper prompt calculations

0neGal commented 3 years ago

ble version: 0.3.3+7fa584c Bash version: 5.1.4(1)-release, x86_64-pc-linux-gnu

As the title describes and the gif below shows, ble seems to fail calculate my prompt correctly, this occurs either when autocomplete happens, or when I switch mode in vi mode. This is likely an issue with my prompt but what in the prompt that's causing it idk.

As you may also notice in the gif, doing ^L fixes the prompt.

akinomyoga commented 3 years ago

What is your prompt setting? Could you give me the result of the following commands?

$ cat -A <<< "${PS1}"
$ cat -A <<< "${PS1@P}"

0neGal commented 3 years ago

1. \[\[\e[33m\]\]\[M-nM-^BM-6\]\[\e[7m\]\[\[\W\]\]\[\]\[\]\[\e[0m\]\[\[\e[33m\]\]\[M-nM-^BM-4\]\[\e[0m\] $
2. ^A^A^[[33m^B^B^AM-nM-^BM-6^B^A^[[7m^B^A^A~^B^B^A^B^A^B^A^[[0m^B^A^A^[[33m^B^B^AM-nM-^BM-4^B^A^[[0m^B $

akinomyoga commented 3 years ago

Thank you for the quick response! It is caused by incorrectly quoted prompt strings by unneeded \[\]. Now the question is where do these \[\] come from. To find the cause, I have additional questions:

May I ask how do you set the prompt? Do you set up PS1 manually? Or, do you set it through some framework?
When ble.sh is not loaded, what is the result of the same commands (I mean cat -A <<< ... in my previous reply)?

0neGal commented 3 years ago

My prompt is custom made as I prefer to make things myself. I already ble loaded when issuing the cat commands.

I'm not near my computer right now so I can't do debugging on my prompt, I only got those results from SSH to my server through my phone, so I'll have a look at it tomorrow.

I have a small idea of what could possibly be triggering this.

On an unrelated note! Is there any way to have a status at at the bottom, that is making the Vi modes always appear at the bottom of the screen. I haven't had time to look into the options of ble as I found the documentation to be slightly verbose at the time, so I may just have missed something.

Also I tried to go about changing the label for the modes like how the documentation tells me to do it but couldn't quite figure it out, some guidance would be appreciated!

akinomyoga commented 3 years ago

My prompt is custom made as I prefer to make things myself.

Thank you!

I already ble loaded when issuing the cat commands.

Maybe there is miscommunication? I'm actually interested in the results when ble.sh is NOT loaded. I just want to isolate whether these redundant \[..\] in PS1 have something to do with ble.sh or not.

Or, maybe I can ask a different but related question: Does a similar problem reproduce with typing up or down in normal Bash (without ble.sh)?

I'll have a look at it tomorrow.

OK!

I have a small idea of what could possibly be triggering this.

OK!

Re: Mode name at the bottom line

Is there any way to have a status at at the bottom,

Currently no such option. Maybe you could do something by hacking Readline options and PS0. I've never thought about that, but I think you can show mode names at the bottom line with the following setting (which works even with a normal Bash without ble.sh), but I think it is not robust: it only shows the mode name for the normal and insert mode, it can overprint the mode name on the multiline command-line text, and it can cause rendering position shift with the full-screen completion menus.

# Readline & PS0 settings
bind 'set show-mode-in-prompt on'
bind $'set vi-cmd-mode-string \1\eD\eM\e7\e[9999B\r\e[K\e[1m~\e[m\e8\2'
bind $'set vi-ins-mode-string \1\eD\eM\e7\e[9999B\r\e[K\e[1m-- INSERT --\e[m\e8\2'
PS0=$'\1\e7\eD\eM\e[9999B\e[2K\e8\2'

# Turn off ble.sh mode names
bleopt keymap_vi_mode_show:=

Maybe later I'll think about a robust implementation for the bottom line in ble.sh.

Re: Vim mode names

Also I tried to go about changing the label for the modes like how the documentation tells me to do it but couldn't quite figure it out, some guidance would be appreciated!

There is a brief explanation at Mode lines (Vi (Vim) editing mode · akinomyoga/ble.sh Wiki). The related options are

bleopt keymap_vi_mode_show=1
bleopt keymap_vi_mode_string_nmap=$'\e[1m~\e[m'
bleopt keymap_vi_mode_name_blockwise=BLOCK
bleopt keymap_vi_mode_name_insert=INSERT
bleopt keymap_vi_mode_name_linewise=LINE
bleopt keymap_vi_mode_name_replace=REPLACE
bleopt keymap_vi_mode_name_select=SELECT
bleopt keymap_vi_mode_name_visual=VISUAL
bleopt keymap_vi_mode_name_vreplace=VREPLACE

Those options need to be called in the keymap_vi_load hook, whose usage can be found in blerc. You can write these settings in a function, and register the function as a hook by calling blehook/eval-after-load keymap_vi YourFunctionName.

Instead of using the keymap_vi_load hook, you can directly write them in .blerc by changing = to := (which skips the option name checks). Something like

bleopt keymap_vi_mode_show:=1
bleopt keymap_vi_mode_string_nmap:=$'\e[1m~\e[m'
bleopt keymap_vi_mode_name_blockwise:=BLOCK
# [...]

Each option is described in the following page in the manual:

You may be also interested in the setting example \q{contrib/vim-mode} though this is not the setting for the mode line but the mode name in the prompt. You could see the implementation here: blesh-contrib/prompt-vim-mode.bash at akinomyoga/blesh-contrib.

0neGal commented 3 years ago

My suspicions as to what was causing the issues in my prompt was correct, meaning I solved the issue.

Maybe there is miscommunication? I'm actually interested in the results when ble.sh is NOT loaded. I just want to isolate whether these redundant [..] in PS1 have something to do with ble.sh or not.

The command gave the same output with and without ble.

Or, maybe I can ask a different but related question: Does a similar problem reproduce with typing up or down in normal Bash (without ble.sh)?

Funnily enough it did not, which was what caught my attention, because I spent a day or two some time ago fixing my prompt in normal Bash, and when I then started using Ble and I started having problems I could only assume it was Ble, I'm guessing normal Bash ignores unnecessary escaped characters by stripping them out somehow no clue really, but in the end this was an issue on my side.

I'll have a look at the wiki and try to read it a little closer, in short issue is fixed and I'll be closing it.

akinomyoga commented 3 years ago

OK! Thank you!

akinomyoga commented 3 years ago

Re: Mode name at the bottom line

On an unrelated note! Is there any way to have a status at at the bottom, that is making the Vi modes always appear at the bottom of the screen.

Hi! In the previous reply, I have shown a hack to show the mode line at the bottom of the screen, but also noted that it is merely a hack. In the latest master branch, I added true support for the mode line at the bottom. If you are interested, you can try it with the following setting:

bleopt info_display=bottom

Thank you!

0neGal commented 3 years ago

This seems to work wonders, I used to use:

bind 'set show-mode-in-prompt on'
PS4=$'\1\e7\eD\eM\e[9999B\e[2K\e8\2'
bind $"set vi-cmd-mode-string \1\eD\eM\e7\e[9999B\r\e[K\e[1m$CMD\e[m\e8\2"
bind $"set vi-ins-mode-string \1\eD\eM\e7\e[9999B\r\e[K\e[1m$INSERT\e[m\e8\2"

Which worked pretty well apart from when there's no more empty lines on the screen in the has issue where sometimes it doesn't remove the status after a command

As as an example

$ echo test # becomes ↓
testNSERT --

It's understandable why it happens... Also switching from PS3 to PS4 helped with some other issues. And so I'll keep this code in my bash config but only execute it when Ble isn't loaded :)

However I have a slight issue with setting the strings for the modes. Using this simply produces errors, I'm likely doing something wrong, here so a slight bit of guidance would help :p

bleopt: unknown bleopt option `keymap_vi_mode_string_nmap'
bleopt: unknown bleopt option `keymap_vi_mode_name_blockwise'
bleopt: unknown bleopt option `keymap_vi_mode_name_insert'
bleopt: unknown bleopt option `keymap_vi_mode_name_linewise'
bleopt: unknown bleopt option `keymap_vi_mode_name_replace'
bleopt: unknown bleopt option `keymap_vi_mode_name_select'
bleopt: unknown bleopt option `keymap_vi_mode_name_visual'
bleopt: unknown bleopt option `keymap_vi_mode_name_vreplace'

Also unrelated to all of this, I have a weird error appearing only when Ble is loaded, and it even happens without my config.

bash: ((: 4 0: syntax error in expression (error token is "0")

I'm uncertain what could be causing this. This is on version 0.4.0-devel3+3588158

akinomyoga commented 3 years ago

Thank you for the report!

Mode name at the bottom (PS0 hack)

As as an example
$ echo test # becomes ↓
testNSERT --
It's understandable why it happens... Also switching from PS3 to PS4 helped with some other issues. And so I'll keep this code in my bash config but only execute it when Ble isn't loaded :)

OK, I could reproduce it. I tried to fix it, and I think the following setting should work (for non-ble.sh session):

bind 'set show-mode-in-prompt on'
bind $"set vi-cmd-mode-string \1\eD\eM\e7\e[9999B\r\e[K\e[1m$CMD\e[m\e8\2"
bind $"set vi-ins-mode-string \1\eD\eM\e7\e[9999B\r\e[K\e[1m$INSERT\e[m\e8\2"
PS0=$'\1\e7\e[9999B\e[2K\e8\2'

Error "Unknown bleopt option"

However I have a slight issue with setting the strings for the modes. Using this simply produces errors, I'm likely doing something wrong, here so a slight bit of guidance would help :p

These errors happen because keymap/vi module is not yet loaded when ~/.blerc is loaded (this is to shorten the loading time of ble.sh). The settings for Vim mode need to be performed through hook:keymap_vi_load (which will be fired when the keymap/vi module is loaded). You can follow the description at the top of §6.3: something like

# In blerc

function my-mode-line-settings-for-blesh {
  bleopt keymap_vi_mode_name_insert='INSERT'
  bleopt keymap_vi_mode_name_replace='REPLACE'
  bleopt keymap_vi_mode_name_vreplace='VREPLACE'
  bleopt keymap_vi_mode_name_visual='VISUAL'
  bleopt keymap_vi_mode_name_select='SELECT'
  bleopt keymap_vi_mode_name_linewise='LINE'
  bleopt keymap_vi_mode_name_blockwise='BLOCK'
}
blehook/eval-after-load keymap_vi my-mode-line-settings-for-blesh

This question is actually frequently asked, so I think I should improve the explanation of the manual!

Thank you!

0neGal commented 3 years ago

These errors happen because keymap/vi module is not yet loaded when ~/.blerc is loaded

I see. I does in fact work now. Something I find odd is the mode strings:

Does not seem to allow for colors with escape sequences
Are inconsistent
- The normal mode has a string to change the whole string that is the suffix and prefix (the -- part of the string), whereas the other ones only change what's inside it.
- Furthermore the blockwise and linewise aren't separate from the visual string instead they get added to it. So if I wanted my mode to be "V-BLOCK" when in blockwise that'd be impossible, as the visual mode would be put in front of it.

In short what I'd be requesting is:

Support for escape sequences
Allow users to change the full string for all the modes

akinomyoga commented 3 years ago

Thank you for the suggestions! #57 is a related discussion.

I actually just intended to emulate the mode strings of Vim.

In Vim, the mode strings (except for the normal mode) are dynamically generated based on the combination of current states. In the default Vim, each word VISUAL or BLOCK is translated separately depending on the locale. So, actually, the settings keymap_vi_mode_name_* are primarily for the translation of each word into each language. (For example, INSERT is 挿入, VISUAL is ビジュアル, and BLOCK is 矩形 in Japanese.)
For the normal mode, there is no mode string in the default Vim, which is the reason that I provided a way to configure the string of the normal mode as an exception.

I think the inconsistency comes from the gap between a mental model for modes that users embrace in their minds and the actual logical model in Vim. For example, the visual block mode isn't really a stand-alone mode as some users might think, but just the combination of two modes "visual" and "block". Some naive implementation of vi mode (such as vi mode of Readline) implements a simplified naive mental model, but ble.sh aims at implementing the real Vim modes. To fill the gap, I think we need to think about a better design for the mode-string user settings in more detail.

Support for escape sequences

These settings keymap_vi_mode_name_* support raw ESC sequences. They don't convert backslash sequences of the form \e..., but these backslash sequences should be processed by Bash's feature---$'...'. For example,

# hook:keymap_vi_load

bleopt keymap_vi_mode_name_insert=$'\e[91mINSERT\e[;1m'

Allow users to change the full string for all the modes

The non-trivial point is that there are actually 30 different mode combinations. I don't want to prepare an option for each of 30 different combinations but rather would like to organize them in some way. The current design is my current choice, which is actually the same as the decision of Vim. The default Vim replaces the words VISUAL and BLOCK separately depending on the current locale.

I would like to hear what you think. Do you have any suggestions? For example, do you still think it's better to prepare 30 options? Or, maybe we can discuss a better design based on what kind of results you want to achieve by using the mode-string configurations.
I searched for whether there are already any attempts to provide more flexible configurations for mode strings in Vim and found that vim-airline provides a way to configure V-BLOCK. Maybe I need to investigate how vim-airline deals with these 30 different states.
Maybe I can expose a new hook for the mode strings for which the hook function can freely generate the mode strings.

0neGal commented 3 years ago

Of course yes having 30 options would be simply overkill.

The main thing I was trying to achieve is give most mode's a different color, so a subset like

Normal = Grey
Insert = Blue
Visual and its subsidiaries = Cyan
etc...

As that's how my Vi(m) config is set up. And it's also how I've done it in every app that support its, besides that I prefer the strings for the modes to also be the same, ofc only in the apps that support it (I'm talking to you QuteBrowser how dare you not support it)

So all my apps have the more string with the same colors and look in the same position of the window, which gives a very unified look.

I'm not sure what the best way to implement it is however.

akinomyoga commented 3 years ago

OK! Thank you! That information is exactly what I wanted to know in order to think about the design!

As that's how my Vi(m) config is set up.

May I ask how you set it up? I'm actually not a heavy user of Vim but using it with almost the default setting... I would like to observe how Vim or its plugins provide interfaces for the mode-string settings.

So all my apps have the more string with the same colors and look in the same position of the window, which gives a very unified look.

I see. Sounds nice!

I'm not sure what the best way to implement it is however.

I'm going to think about what would be the best design for this based on your use case. Even if nothing comes up, anyway, for maximal flexibility I can expose a hook so that users can write a shell function to produce the mode string.

Or, it is maybe also possible by combining bleopt prompt_status_line (which I recently renewed) and the user-defined prompt sequence \q{my/vim-mode}. But bleopt prompt_status_line is now under debugging.

0neGal commented 3 years ago

May I ask how you set it up? I'm actually not a heavy user of Vim but using it with almost the default setting... I would like to observe how Vim or its plugins provide interfaces for the mode-string settings.

Put the following in your ~/.vimrc or ~/.config/nvim/init.vim for NeoVim

set noshowmode " This hides the normal mode line
set laststatus=2 " Enables the statusline

" Names for each mode (used for the statusbar)
let g:currentmode={
       \ 'n'  : '-- NORMAL --',
       \ 'v'  : '-- VISUAL --',
       \ 'V'  : '-- V-LINE --',
       \ '^V' : '-- V-BLOQ --',
       \ 'i'  : '-- INSERT --',
       \ 'ic' : '-- INSERT --',
       \ 'ix' : '-- INSERT --',
       \ 'R'  : '-- RPLACE --',
       \ 'Rv' : '-- VPLACE --',
       \ 'c'  : '-- PROMPT --',
       \ '!'  : '-- !SHELL --',
       \ 't'  : '-- TSHELL --',
       \ 'r'  : '-- PROMPT --',
       \ 'r?' : '-- ACCEPT --',
       \}

" Sets the statusline
set statusline=%{g:currentmode[mode()]}

" And unless you wanna go insane when going between modes I recommend this
set ttimeoutlen=0 " Which eliminates the annoying delay when switching modes (This is only for normal Vim)

As you can see all the mode strings have the same number of characters which imo, looks very good. And as I said earlier I've implemented this over quite a few of my programs (The only one missing is QuteBrowser dahm you! I might have to modify the source code for that... :p)

The only thing that's not implemented here is color, as I haven't had time to make that, not that it'd be hard.

Or, it is maybe also possible by combining bleopt prompt_status_line (which I recently renewed) and the user-defined prompt sequence \q{my/vim-mode}. But bleopt prompt_status_line is now under debugging.

I'm mildly confused what the purpose of this feature is but I'm probably just a little dumb. Which reminds me how at some point perhaps when writing a command the cursor should be moved here or something similar? Or at the very least move to where the mode line is?

akinomyoga commented 3 years ago

Thank you for the information and the Vim setting! OK, in this Vim setting, the mode line is turned off, and the mode strings are instead shown in the status line whose contents can be configured through the setting statusline. Actually, the idea is exactly the same as

Or, it is maybe also possible by combining bleopt prompt_status_line (which I recently renewed) and the user-defined prompt sequence \q{my/vim-mode}. But bleopt prompt_status_line is now under debugging.

Also, the key point in Vim is that the current mode can be obtained by the function mode() in the form of a simple string. I'll later investigate how the result of mode() changes depending on different internal states.

I'm mildly confused what the purpose of this feature is

The status line is just another "prompt" area (which is turned off by default). Currently there is some bug in prompt_status_line, so after I fixed it, I'll show you how to use it by translating your Vim settings using bleopt prompt_status_line.

0neGal commented 3 years ago

Currently there is some bug in prompt_status_line, so after I fixed it, I'll show you how to use it

Sounds great, I'll definitely be interested in it when it's possible to do what my Vim config does :)

akinomyoga commented 3 years ago

I added a fix for the status line (b424fa5).

I added a function ble/keymap:vi/script/get-mode which can be used from user codes to identify the current mode (f25a6e8).

Details on ble/keymap:vi/script/get-mode

To design the result string of `ble/keymap:vi/script/get-mode`, I checked the results of `mode()` in Vim script for 30+1 modes. I initially intended to exactly follow Vim's `mode()`, but I decided to change the result to later provide it for the hook for the normal mode names. Here is the table for the results of `mode()` and `ble/keymap:vi/script/get-mode`: | Mode | Vim script `mode()` | `ble/keymap:vi/script/get-mode` | |---------------------------:|--------------------:|----------------------------:| | `INSERT ` | `i` | `i` | | `REPLACE ` | `R` | `R` | | `VREPLACE ` | `R` | `^R` | | `NORMAL ` | `n` | `n` | | `(insert)` | `n` | `in` | | `(replace)` | `n` | `Rn` | | `(vreplace)` | `n` | `^Rn` | | `VISUAL ` | `v` | `v` | | `(insert) VISUAL ` | `v` | `iv` | | `(replace) VISUAL ` | `v` | `Rv` | | `(vreplace) VISUAL ` | `v` | `^Rv` | | `VISUAL LINE ` | `V` | `V` | | `(insert) VISUAL LINE ` | `V` | `iV` | | `(replace) VISUAL LINE ` | `V` | `RV` | | `(vreplace) VISUAL LINE ` | `V` | `^RV` | | `VISUAL BLOCK ` | `^V` | `^V` | | `(insert) VISUAL BLOCK ` | `^V` | `i^V` | | `(replace) VISUAL BLOCK ` | `^V` | `R^V` | | `(vreplace) VISUAL BLOCK ` | `^V` | `^R^V` | | `SELECT ` | `s` | `s` | | `(insert) SELECT ` | `s` | `is` | | `(replace) SELECT ` | `s` | `Rs` | | `(vreplace) SELECT ` | `s` | `^Rs` | | `SELECT LINE ` | `S` | `S` | | `(insert) SELECT LINE ` | `S` | `iS` | | `(replace) SELECT LINE ` | `S` | `RS` | | `(vreplace) SELECT LINE ` | `S` | `^RS` | | `SELECT BLOCK ` | `^S` | `^S` | | `(insert) SELECT BLOCK ` | `^S` | `i^S` | | `(replace) SELECT BLOCK ` | `^S` | `R^S` | | `(vreplace) SELECT BLOCK ` | `^S` | `^R^S` | - `^V`, `^S`, and `^R` are control characters C-v, C-s, and C-r, respectively.

Here is an example to configure the status line for the vim mode strings (Edit: Please replace ^V, ^S, and ^R with corresponding control characters!):

# blerc

function 0neGal/set-up-status-line {

  # Hide the normal mode name
  bleopt keymap_vi_mode_show=

  # Update prompts on the mode change
  bleopt keymap_vi_mode_update_prompt=1

  function ble/prompt/backslash:0neGal/currentmode {
    local mode; ble/keymap:vi/script/get-mode
    case $mode in
    (*n)  ble/prompt/print $'\e[1m-- NORMAL --\e[m' ;;
    (*v)  ble/prompt/print $'\e[1m-- VISUAL --\e[m' ;;
    (*V)  ble/prompt/print $'\e[1m-- V-LINE --\e[m' ;;
    (*^V) ble/prompt/print $'\e[1m-- V-BLOQ --\e[m' ;;
    (*s)  ble/prompt/print $'\e[1m-- SELECT --\e[m' ;;
    (*S)  ble/prompt/print $'\e[1m-- S-LINE --\e[m' ;;
    (*^S) ble/prompt/print $'\e[1m-- S-BLOQ --\e[m' ;;
    (i)   ble/prompt/print $'\e[1m-- INSERT --\e[m' ;;
    (R)   ble/prompt/print $'\e[1m-- RPLACE --\e[m' ;;
    (^R)  ble/prompt/print $'\e[1m-- VPLACE --\e[m' ;;
    (*)   ble/prompt/print $'\e[1m-- ?????? --\e[m' ;;
    esac

    # Change the default color of status line
    case $mode in
    (*n)          ble-face prompt_status_line='bg=gray,fg=white' ;;
    (*[vV^VsS^S]) ble-face prompt_status_line='bg=teal,fg=white' ;;
    (*[iR^R])     ble-face prompt_status_line='bg=navy,fg=white' ;;
    (*)           ble-face prompt_status_line='bg=240,fg=231' ;;
    esac
  }

  # In this example, we put the mode string, date and time, and the
  # current working directory in the status line.
  bleopt prompt_status_line='\q{0neGal/currentmode} \D{%F %H:%M} \e[96m\w\e[m'

}
blehook/eval-after-load keymap_vi 0neGal/set-up-status-line

Edit (2022-07-10) I have changed ble-color-setface in the above example to ble-face following the updates in ble.sh.

0neGal commented 3 years ago

This is perfect, probably better than perfect. I tweaked the code a little to better suite my colors and simplicity (the date, and current directory had to be removed :p), and also suited the code to be more like my code (as I prefer tabs over spaces in 99% of cases)

function status/set-up-status-line {
    bleopt keymap_vi_mode_show=
    bleopt keymap_vi_mode_update_prompt=1

    function ble/prompt/backslash:status/currentmode {
        local mode; ble/keymap:vi/script/get-mode
        case $mode in
            (*n)    ble/prompt/print $"-- NORMAL --" ;;
            (*v)    ble/prompt/print $"-- VISUAL --" ;;
            (*V)    ble/prompt/print $"-- V-LINE --" ;;
            (*^V)   ble/prompt/print $"-- V-BLOQ --" ;;
            (*s)    ble/prompt/print $"-- SELECT --" ;;
            (*S)    ble/prompt/print $"-- S-LINE --" ;;
            (*^S)   ble/prompt/print $"-- S-BLOQ --" ;;
            (i) ble/prompt/print $"-- INSERT --" ;;
            (R) ble/prompt/print $"-- RPLACE --" ;;
            (^R)    ble/prompt/print $"-- VPLACE --" ;;
            (*) ble/prompt/print $"-- ?????? --" ;;
        esac

        # Change the default color of status line
        case $mode in
            *n)
                ble-color-setface prompt_status_line fg=silver
                ;;
            i)
                ble-color-setface prompt_status_line fg=magenta
                ;;
            *[vV^VsS^S])
                ble-color-setface prompt_status_line fg=cyan
                ;;
            *[iR^R])
                ble-color-setface prompt_status_line fg=red
                ;;
            *)
                ble-color-setface prompt_status_line fg=gray
                ;;
        esac
    }

    bleopt prompt_status_line="\q{status/currentmode}"
}
blehook/eval-after-load keymap_vi status/set-up-status-line

So everything with the status(line/bar) is now working as it should.

However (And I glossed over this before but I presume you accidentally didn't read it) I keep having this weird error everytime Ble loads

bash: ((: 4 0: syntax error in expression (error token is "0")

And I'm not sure what's causing it. However as far as I can tell it has nothing to do with my config, in any way and seems to be Ble itself.

akinomyoga commented 3 years ago

However (And I glossed over this before but I presume you accidentally didn't read it)

Oh, sorry. I saw that there is an additional message when I first saw the reply, but later I completely forgot about that section. Thank you for reminding me of that.

bash: ((: 4 0: syntax error in expression (error token is "0")

This is not reproduced in my environment, but I'll check if there is a suspicious point in recent changes.

And I'm not sure what's causing it. However as far as I can tell it has nothing to do with my config,

The original report says that "it even happens without my config." Does this "my config" mean your .blerc or also contain your other configurations in .bashrc? Also, what about .inputrc? It is also possible that some interference between different configurations causes the problem.

It is also possible that some cache files of ble.sh are broken by some broken commit at some point. In this case, maybe you can try to clear the cache files:

$ rm -rf "$_ble_base_cache"

0neGal commented 3 years ago

It is also possible that some cache files of ble.sh are broken by some broken commit at some point. In this case, maybe you can try to clear the cache files

This had no effect.

Does this "my config" mean your .blerc

More or less, it's just my equivalent of .blerc aka a script that executes after Ble is loaded which changes Ble settings, the reason for not using .blerc is I like having configs in my .config folder and what not. But it operates the same as .blerc

However simply loading Ble without the rest of my bash config it seems to actually work properly. So I think I'll just have to experiment with what could be wrong, I'll be closing the issue once it's solved.

akinomyoga commented 3 years ago

Ah, OK. I was also experimenting, and now I could reproduce it with IFS= before ble-attach. I'll later fix it! Thank you!

0neGal commented 3 years ago

Okay that's interesting it does seem to be caused by IFS being set, even tho I am unsetting it before loading Ble

akinomyoga commented 3 years ago

I pushed fixes 5f9adfe. Can you check if it works? Thank you

- First problem was that `ble.sh` have failed to restore the unset state of `IFS`. `ble.sh` temporary sets `IFS=$' \t\n'` for its internal processing and tries to restore the state of `IFS` after the processing. However, when `IFS` is originally in the unset state, it failed to correctly restore the unset state but reset `IFS` to be an empty string. - Another problem is that some functions in `ble.sh` require `IFS=$' \t\n'`, but some functions do not require. Because of this inconsistency, a function `ble/textmap#getxy.cur` which requires `IFS=$' \t\n'` has been used in the context of an arbitrary `IFS`, which caused the error message `bash: ((: 4 0: ...`. To resolve the inconsistency, I tried to modify functions so that all of them work for an arbitrary `IFS`.

0neGal commented 3 years ago

Indeed this fixes it.

akinomyoga commented 3 years ago

OK! Thank you for your feedback and reports!

akinomyoga / ble.sh