Vim-airline emulation [Vim info pane, more customization and refresh]

[ghost]

It would be nice to let users customize more freely their vim info pane. In $_ble_base/keymap/vi.sh, the vim's mode name is surrounded by "--"

    name=$'\e[1m-- '$name$' --\e[m'

Maybe that line can be omitted or maybe just be surrounded by $' and \e[m'. Then users can make their own color sequences and put special characters as if it was a regular prompt. For example I thought it would be nice to show the current directory in the vim pane in insert mode rather than in the prompt (which would declutter the terminal from repetitive output); so by deleting that line and putting this in the blerc:

bleopt info_display=bottom
bleopt keymap_vi_mode_name_insert=$'\e[1;37;41m INSERT \e[40;31;43m\uE0B0\e[37m'" ${PWD} "$'\e[33;40m\uE0B0\e[m'

one can have a nice looking pane, similar to something like vim-airline (I would post a screenshot but Github is not letting me); and of course users can customize this to their liking. However, one other thing is that this function does not get refreshed and so ${PWD} always shows just the working directory when ble was sourced. A workaround that kind of works is to put that function into a PROMPT_COMMAND (or a bash-preexec precmd), but this only refreshes the $PWD if you first change to another vim mode and back again to insert mode, could this be adressed so it reads environment variables every time it's printed?

EDIT: Funny, I just noticed ble has a blehook PRECMD that also does preexecution of functions, but it also doesn't refresh the $PWD on every prompt, maybe it's easier to change that blehook function?

[akinomyoga]

Thank you for the discussion! I'll later write detailed explanations, but you can also look at the following settings:

• akinomyoga/blesh-contrib \q{contrib/vim-mode}
• #85 (comment) bleopt prompt_status_line

[akinomyoga]

Actually, there were similar requests twice or three times in the past. I think I should describe it somewhere in Wiki.

In $_ble_base/keymap/vi.sh, the vim's mode name is surrounded by "--"

This is what Vim does; In Vim, the mode-line content is hardcoded. The primary reason I prepared the options keymap_vi_mode_name_xxx was actually for internationalization. For example, Vim shows -- 挿入 -- instead of -- INSERT -- in the Japanese locale (LC_MESSAGES=ja_JP.*).

For more flexible customization, I would recommend just turning off the default mode names and instead setting up a status line as vim-airline is doing internally. The following is an example for you! Please replace ^V, ^S, and ^R with the real control characters (or you may write $'\026', $'\023', and $'\022', respectively). You can freely customize it. Any suggestions for new customization user interfaces/utilities are also welcome.

# blerc

function huresche/set-up-status-line {

  # Hide the default mode name in the info pane
  bleopt keymap_vi_mode_show=

  # Update prompts on the mode change
  bleopt keymap_vi_mode_update_prompt=1

  # Define a named prompt sequence \q{huresche/vim-mode}
  function ble/prompt/backslash:huresche/vim-mode {
    local mode; ble/keymap:vi/script/get-mode
    case $mode in
    (*n)  ble/prompt/print $'\e[1;37;41m NORMAL \e[m' ;;
    (*v)  ble/prompt/print $'\e[1;37;41m VISUAL \e[m' ;;
    (*V)  ble/prompt/print $'\e[1;37;41m V-LINE \e[m' ;;
    (*^V) ble/prompt/print $'\e[1;37;41m V-BLOQ \e[m' ;;
    (*s)  ble/prompt/print $'\e[1;37;41m SELECT \e[m' ;;
    (*S)  ble/prompt/print $'\e[1;37;41m S-LINE \e[m' ;;
    (*^S) ble/prompt/print $'\e[1;37;41m S-BLOQ \e[m' ;;
    (i)   ble/prompt/print $'\e[1;37;41m INSERT \e[m' ;;
    (R)   ble/prompt/print $'\e[1;37;41m RPLACE \e[m' ;;
    (^R)  ble/prompt/print $'\e[1;37;41m VPLACE \e[m' ;;
    (*)   ble/prompt/print $'\e[1;37;41m ?????? \e[m' ;;
    esac
  }

  ble-color-setface prompt_status_line none
  bleopt prompt_status_line='\q{huresche/vim-mode}\e[40;31;43m\uE0B0\e[37m \w \e[33;49m\uE0B0\e[m'
}
blehook/eval-after-load keymap_vi huresche/set-up-status-line

EDIT: Funny, I just noticed ble has a blehook PRECMD that also does preexecution of functions,

Maybe you don't need it anymore because we have prompt_status_line, but I think blehook CHPWD was actually the exact hook you wanted. It will be fired on the PWD change.

but it also doesn't refresh the $PWD on every prompt, maybe it's easier to change that blehook function?

Ah, that is because the content of the info pane is only updated on the mode change. When you just run commands, the mode remains in vi_imap, so the info pane is not updated. I actually haven't thought about the case that users want to change the mode names dynamically. I think I should trigger the update when keymap_vi_mode_name_xxxxx is changed. I'll modify the code later.

[akinomyoga]

You can also put several fields separated by \r to align fields to left, center, right, etc. (The behavior is similar to the text justification).

# Examples
bleopt prompt_status_line='left\rcenter\rright'
bleopt prompt_status_line='\q{huresche/vim-mode}\r\w'

You can find the detailed explanation of each option in the following pages:

• bleopt prompt_status_line
• bleopt prompt_status_align (Oh, the description here is outdated. The current default is $'justify=\r'. I shall update it.)
• face prompt_status_line
• bleopt keymap_vi_mode_update_prompt
• bleopt keymap_vi_mode_show

[akinomyoga]

I decided to make a vim-airline emulation.

[ghost]

For more flexible customization, I would recommend just turning off the default mode names and instead setting up a status line as vim-airline is doing internally.

Oh I see, that actually makes a more modular approach than rearranging the info pane, and also would make it easier to manage the mode combinations right?, since I saw that customizing the "visual block" mode in the info pane would result in 2 separate mode strings.

The function does update the $PWD correctly! However, I noticed that the "visual block" mode was not being detected, when I enter into it with Ctrl-V, I get the ?????? mode string. I tried changing the *^V part with *^v, ^V, ^v, but no luck, what could be causing this? I checked the ble/keymap:vi/script/get-mode function and there was this case statement that I think should be adding ^V but it doesn't?:

...
    case $kmap:${_ble_edit_mark_active%+} in 
         vi_xmap:vi_line)
             mode=$mode'V'
         ;;
         vi_xmap:vi_block)
             mode=$mode''      # ←There?
         ;;
         vi_xmap:*)
             mode=$mode'v'
...

Note: the \uE0B0 doesn't get interpreted inside bleopt prompt_status_line, but one can simply put the character itselft there:  or put the \uE0B0 in the ble/prompt/print part.

Maybe you don't need it anymore because we have prompt_status_line, but I think blehook CHPWD was actually the exact hook you wanted. It will be fired on the PWD change.

I saw that hook but I didn't understand it, so should I make a custom PWD function and add it with bleehook CHPWD+=custom-pwd-function ?, and are you saying that hook will be discarded? So for example I tried

precmd_new_cmd() { 
 NEW_PWD=${PWD/#$HOME/⌂}
}
blehook CHPWD+=precmd_new_cmd

and

...
  bleopt prompt_status_line='\q{huresche/vim-mode}\e[40;31;43m\e[37m ${NEW_PWD} \e[33;49m\e[m'
...

and it appears to update correctly as I expect it!, and so does blehook PRECMD. So what's the difference between blehook PRECMD and blehook CHPWD anyways?

[ghost]

I decided to make a vim-airline emulation.

That would be nice as it would make the terminal feel even more like vim withouth actually being in vim. (Of course vim has its own terminal mode but I still find it buggy with some terminals and multiplexers).

In #85 you said:

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.

In vim-airline one can just make a global dictionary to change how the mode strings look, for example I have:

let g:airline_mode_map = {
      \ '__'     : '-',
      \ 'c'      : 'C',
      \ 'i'      : 'I',
      \ 'ic'     : 'I',
      \ 'ix'     : 'I',
      \ 'n'      : 'N',
      \ 'multi'  : 'M',
      \ 'ni'     : 'N',
      \ 'no'     : 'N',
      \ 'R'      : 'R',
      \ 'Rv'     : 'R',
      \ 's'      : 'S',
      \ 'S'      : 'S',
      \ '^S'     : 'S',
      \ 't'      : 'T',
      \ 'v'      : 'V',
      \ 'V'      : 'V',
      \ '^V'     : 'V',
      \ }

This is similar to the keymap_vi_mode_name_xxxx in that it just changes the name, but it does not combine modes like in ble/keymap:vi/script/get-mode, so there's 'v' '^V', 's' and '^S'. I'm not sure which approach would be better; vim-airline has lots of little configurations that I always find a bit annoying to configure; but well ble's configurations are quite extensive as well so it would fit well as an extension that one can source within blerc. In any case, it would be nice to have the option of being able to manually configure the status-line like how it is at the moment

[ghost]

On a related note, I noticed that when characters are printed by ble, they don't get erased when something gets resized or removed from there, including the status line and the vim info pane. For example if one resizes down the terminal (make characters smaller), the status line does adjust and prints to the new bottom line, but the previous printing is still shown. I'd show a demo but Github is not letting me post it.

This issue also happens when you change the vim mode and the status line gets shrinked. For example if the status line is in normal mode and shows ノーマル, but then it's changed to insert mode 挿入 which has fewer characters; one would still see the マル part. Maybe this should be a separate issue that i didn't find it was discussed.

[akinomyoga]

Control characters

However, I noticed that the "visual block" mode was not being detected, when I enter into it with Ctrl-V, I get the ?????? mode string. I tried changing the *^V part with *^v, ^V, ^v, but no luck, what could be causing this?

Have you noticed this comment?

Please replace ^V, ^S, and ^R with the real control characters (or you may write $'\026', $'\023', and $'\022', respectively). #114 (comment)

^V in the above example is not the combination of the circumflex and the capital V, but an ASCII representation of a single control character (\x16). You can input control characters in the insert mode in Vim by pressing C-v C-v for ^V, C-v C-s for ^S, and C-v C-r for ^R. This is actually an intensional design so that each character represents one meaning.

I checked the ble/keymap:vi/script/get-mode function and there was this case statement that I think should be adding ^V but it doesn't?:

[...]
         vi_xmap:vi_block)
             mode=$mode''      # ←There?
         ;;
[...]

I think you have checked the function by type ble/keymap:vi/script/get-mode or declare -f ble/keymap:vi/script/get-mode, but in this way, control characters will not be printed in terminals. You can make control characters visible by feeding the output to less:

$ type ble/keymap:vi/script/get-mode | LESS= /bin/less

You can also play around by defining your function with control characters:

$ func() { echo $'\x16'; }; type func
func is a function
func ()
{
    echo ''
}
$ type func | LESS= /bin/less -XF
func is a function
func ()
{
    echo '^V'
}

\uE0B0 in prompt strings

Note: the \uE0B0 doesn't get interpreted inside bleopt prompt_status_line, but one can simply put the character itselft there:  or put the \uE0B0 in the ble/prompt/print part.

Ah, OK. \u actually means a user name in the prompt strings. Please use $'\uE0B0' instead.

[English] fire hooks?

Maybe you don't need it anymore because we have prompt_status_line, but I think blehook CHPWD was actually the exact hook you wanted. It will be fired on the PWD change.

I saw that hook but I didn't understand it, so should I make a custom PWD function and add it with bleehook CHPWD+=custom-pwd-function ?, and are you saying that hook will be discarded?

Oh, sorry. By "will be fired", I meant just "will be triggered" (but not "will be discarded"). Maybe this is not so common usage compared to "trigger" or "raise"... I searched and found the same question as mine:

• .net - Are events raised, triggered, or fired? - Stack Overflow

Interesting.

From comment under the answer: "A friend of mine forgot to remove some javascript debugging code from an internal timesheet application once: alert("Fired"); (he was making sure a particular event was raised). It caused quite a stir because when some employees logged on, they thought the alert box meant that they had been fired from the job. – Zachary Yates Feb 6 '14 at 19:28"

CHPWD

[...]

and it appears to update correctly as I expect it!, and so does blehook PRECMD. So what's the difference between blehook PRECMD and blehook CHPWD anyways?

PRECMD is called every time before the prompt is newly shown or updated. CHPWD is only called after the current working directory was changed after command execution.

$ blehook PRECMD+='echo PRECMD' CHPWD='echo CHPWD'
PRECMD
$ true
PRECMD
$ cd ~
CHPWD
PRECMD
$ true
PRECMD
$ cd bin
CHPWD
PRECMD
$

airline_mode_map

In vim-airline one can just make a global dictionary to change how the mode strings look, for example I have:

let g:airline_mode_map = {
      \ '__'     : '-',
      \ 'c'      : 'C',
      \ 'i'      : 'I',
[...]

Yeah, I have actually already implemented this one though the composition of the mode string is different.

In any case, it would be nice to have the option of being able to manually configure the status-line like how it is at the moment

Yeah, I just implement lib/vim-airline.sh on top of prompt_status_line. The users who want to customize the statusline can still continue to use prompt_status_line instead of importing lib/vim-airline.

On a related note, I noticed that when characters are printed by ble, they don't get erased when something gets resized or removed from there, including the status line and the vim info panel.

Ah, yes. Thank you for the report. I actually already noticed this issue. This issue only happens with ble-color-setface prompt_status_line none, so I haven't noticed it until I created an example for you.

---

I'm now testing the new lib/vim-airline.sh locally. Somehow it affects the highlighting of menu-complete... it's a strange bug...

[ghost]

Please replace ^V, ^S, and ^R with the real control characters (or you may write $'\026', $'\023', and $'\022', respectively). #114 (comment)

Right, my bad, I somehow missed that!

I think you have checked the function by type ble/keymap:vi/script/get-mode or declare -f ble/keymap:vi/script/get-mode, but in this way, control characters will not be printed in terminals. You can make control characters visible by feeding the output to less

I didn't know about that, interesting

Oh, sorry. By "will be fired", I meant just "will be triggered" (but not "will be discarded").

Oh, I misread that, now it makes sense, thanks for clarifying

Yeah, I just implement lib/vim-airline.sh on top of prompt_status_line. The users who want to customize the statusline can still continue to use prompt_status_line instead of importing lib/vim-airline.

Awesome!!

On a related note, I noticed that when characters are printed by ble, they don't get erased when something gets resized or removed from there, including the status line and the vim info panel.

Ah, yes. Thank you for the report. I actually already noticed this issue. This issue only happens with ble-color-setface prompt_status_line none, so I haven't noticed it until I created an example for you.

Ah, because if you set the background color, it overrides the previous printing of the status line, yes. But the issue still exists on terminal resizing.

[akinomyoga]

On a related note, I noticed that when characters are printed by ble, they don't get erased when something gets resized or removed from there, including the status line and the vim info panel.

Ah, yes. Thank you for the report. I actually already noticed this issue. This issue only happens with ble-color-setface prompt_status_line none, so I haven't noticed it until I created an example for you.

Ah, because if you set the background color, it overrides the previous printing of the status line, yes. But the issue still exists on terminal resizing.

da1d0ff I have pushed a partial support of lib/vim-airline (together with other fixes and workarounds 5c2edfc, a46fdaf, 2408a20). I also added a new interface ble-face to better manipulate a mass of face settings c94d292. You can now try it by ble-update & ble-import lib/vim-airline. I haven't wrote the documents, but you can check the related options by the following commands:

$ bleopt vim_airline_@
$ ble-face vim_airline_@
$ declare -p _ble_lib_vim_airline_mode_map

Note: _ble_lib_vim_airline_mode_map is supposed to be manipulated by ble/gdict#set _ble_lib_vim_airline_mode_map 'key' 'value', ble/gdict#unset _ble_lib_vim_airline_mode_map 'key', etc. I think you can guess what ble/gdict#* does by looking at its implementation by type ble/gdict#set, etc.

There are still several TODOs: Now I'm trying to extract themes from vim-airline-themes. I haven't supported _modified faces, etc. I need to improve the performance of git status extraction. Currently, all the prompts are recalculated every time a vim mode is updated or one goes to another history entry. I think I can add a mechanism to track the dependency of each element of prompts so that we can only update the necessary prompt elements.

---

Edit: I believe the afore-mentioned problems are also resolved in the commit da1d0ff:

I'm now testing the new lib/vim-airline.sh locally. Somehow it affects the highlighting of menu-complete... it's a strange bug...

I fixed this issue. It was caused by an old code that wasn't used recently but used by new codes.

This issue only happens with ble-color-setface prompt_status_line none, so I haven't noticed it until I created an example for you.
Ah, because if you set the background color, it overrides the previous printing of the status line, yes.

Right. I have updated to always clear the background

But the issue still exists on terminal resizing.

This was a separate problem. It turned out that Bash kills SIGWINCH when the former SIGWINCH is in processing. If terminal sends multiple SIGWINCH for smoother resizing, only the first SIGWINCH is ensured to reach ble.sh, but the other SIGWINCH's may be dropped by a race condition. I changed ble.sh so that it re-checks the values of $LINES and $COLUMNS at the end of the SIGWINCH trap to detect whether another (or more) SIGWINCH have reached while the trap handling. Now, the terminal content looks much stabler on resizing!

[ghost]

da1d0ff I have pushed a partial support of lib/vim-airline (together with other fixes and workarounds 5c2edfc, a46fdaf, 2408a20). I also added a new interface ble-face to better manipulate a mass of face settings c94d292. You can now try it by ble-update & ble-import lib/vim-airline.

Fantastic, it looks and works great, and the customizations are nice. So does that mean ble-color-setface will be deprecated in favor of ble-face?

Note: _ble_lib_vim_airline_mode_map is supposed to be manipulated by ble/gdict#set _ble_lib_vim_airline_mode_map 'key' 'value', ble/gdict#unset _ble_lib_vim_airline_mode_map 'key', etc. I think you can guess what ble/gdict#* does by looking at its implementation by type ble/gdict#set, etc.

Yes, great, simply including ble/gdict#set _ble_lib_vim_airline_mode_map n ノーマル in blerc and so on will do! Btw what is the difference between ble/dict#set and ble/gdict#set and the other pairs? Is it some safety measure when using eval or something?

But the issue still exists on terminal resizing.

This was a separate problem. It turned out that Bash kills SIGWINCH when the former SIGWINCH is in processing. If terminal sends multiple SIGWINCH for smoother resizing, only the first SIGWINCH is ensured to reach ble.sh, but the other SIGWINCH's may be dropped by a race condition. I changed ble.sh so that it re-checks the values of $LINES and $COLUMNS at the end of the SIGWINCH trap to detect whether another (or more) SIGWINCH have reached while the trap handling. Now, the terminal content looks much stabler on resizing!

I see, interesting. Indeed now it readjusts very smoothly, thanks very much for your work. The only very minor issue I still see is when quickly increasing the terminal font size and having a right prompt, it can still leave some of the printing wrongly readjusted on top of the command line; anyways it is a very minor thing since it doesn't happen when increasing the font slowly (could be a performance thing), and doing so would mess up the previous command's right prompt printing so one would have to clean up the terminal anyways.

For the TODO list I'd like to suggest showing the key pressed when there's a pending operation and also the current column like how vim does it.

[akinomyoga]

Fantastic, it looks and works great, and the customizations are nice. So does that mean ble-color-setface will be deprecated in favor of ble-face?

Thank you for testing it! ble-color-setface will not soon be deprecated, but will be removed from manual. Nevertheless, I think I won't remove the function because ble-face internally uses ble/color/setface which is almost a synonym to ble-color-setface except for argument checking.

Btw what is the difference between ble/dict#set and ble/gdict#set and the other pairs? Is it some safety measure when using eval or something?

They are an abstraction layer for Bash versions. ble/dict#xxx is used for associative arrays (aka "dict"ionary) defined locally inside functions, and ble/gdict#xxx for associative arrays defined "g"lobally.

• In Bash 4.2+, we can use built-in Bash associative arrays to implement both ble/dict#xxx and ble/gdict#xxx. In this case, all the operations of both versions are shared except for the declaration, so ble/gdict#xxx becomes a synonym of ble/gdict#xxx.
• However, in Bash 4.0-4.1, we can only reliably declare local associative arrays because the declare builtin in Bash 4.1 and lower doesn't have the option -g. For this reason, the implementation of ble/dict#xxx and ble/gdict#xxx in Bash 4.0-4.1 becomes different; ble/dict#xxx uses built-in Bash associative arrays, but ble/gdict#xxx uses a fallback implementation by ordinary indexed arrays (ble/adict#xxx).
• In Bash 3.2 or lower, there is no built-in Bash associative arrays, so both use the fallback implementation.

After I received this question, I remembered that ble/gdict#xxx was actually not designed to be called from the scripts loaded by ble-import, so I modified the implementations and also made refactoring 7732eed.

The only very minor issue I still see is when quickly increasing the terminal font size and having a right prompt, it can still leave some of the printing wrongly readjusted on top of the command line; anyways it is a very minor thing since it doesn't happen when increasing the font slowly (could be a performance thing), and doing so would mess up the previous command's right prompt printing so one would have to clean up the terminal anyways.

Unless we clear all the terminal contents on resizing, it is difficult to handle it properly. It is related to the text reflow of the terminal where the terminal itself rearranges its contents on resizing. But the reflow algorithm depends on the terminal and also on the current cursor position (which ble.sh doesn't track), so it is almost impossible to know how the previous prompts and status lines are reflowed. ble.sh may erase previous lines based on a guess, but the outputs of previous commands may be lost with a wrong guess.

For the TODO list I'd like to suggest showing the key pressed when there's a pending operation and also the current column like how vim does it.

Actually, this directly affects the performance. In the current implementation, we need to recalculate the prompt contents every time when it needs to be updated. Supporting the current column in the status line requires updating the prompt contents on every keystroke. For example, we don't want to run git diff --quiet for every keystroke. This is one of the reasons that I raised optimizations in the TODO list. Although I'll try to optimize the prompt calculation codes, there is a limitation in speed as far as it is implemented in Bash. I guess it won't be a problem if you are using a fast machine, but I cannot guarantee it.

[ghost]

They are an abstraction layer for Bash versions. ble/dict#xxx is used for associative arrays (aka "dict"ionary) defined locally inside functions, and ble/gdict#xxx for associative arrays defined "g"lobally.

• In Bash 4.2+, we can use built-in Bash associative arrays to implement both ble/dict#xxx and ble/gdict#xxx. In this case, all the operations of both versions are shared except for the declaration, so ble/gdict#xxx becomes a synonym of ble/gdict#xxx.

• However, in Bash 4.0-4.1, we can only reliably declare local associative arrays because the declare builtin in Bash 4.1 and lower doesn't have the option -g. For this reason, the implementation of ble/dict#xxx and ble/gdict#xxx in Bash 4.0-4.1 becomes different; ble/dict#xxx uses built-in Bash associative arrays, but ble/gdict#xxx uses a fallback implementation by ordinary indexed arrays (ble/adict#xxx).

• In Bash 3.2 or lower, there is no built-in Bash associative arrays, so both use the fallback implementation.
  After I received this question, I remembered that ble/gdict#xxx was actually not designed to be called from the scripts loaded by ble-import, so I modified the implementations and also made refactoring 7732eed.

Ah I see, thanks for the detailed explanation and the refactoring

Unless we clear all the terminal contents on resizing, it is difficult to handle it properly. It is related to the text reflow of the terminal where the terminal itself rearranges its contents on resizing. But the reflow algorithm depends on the terminal and also on the current cursor position (which ble.sh doesn't track), so it is almost impossible to know how the previous prompts and status lines are reflowed. ble.sh may erase previous lines based on a guess, but the outputs of previous commands may be lost with a wrong guess.

Yeah, I know tracking previous printed prompts of executed commands is very difficult and terminal related. I was more so referring that even when there was no previous command executed, quickly changing the terminal size (e.g. the window manager tiles it to half its size) causes some printing of the current right prompt (and sometimes the left prompt comes along) on top of the current command line.

As you said, erasing previous lines is not viable, and I'm still guessing it has to with performance of its recalculation since putting more complex functions in right prompt, or having vim-airline imported makes it more noticeable

For the TODO list I'd like to suggest showing the key pressed when there's a pending operation and also the current column like how vim does it.

Actually, this directly affects the performance. In the current implementation, we need to recalculate the prompt contents every time when it needs to be updated. Supporting the current column in the status line requires updating the prompt contents on every keystroke. For example, we don't want to run git diff --quiet for every keystroke. This is one of the reasons that I raised optimizations in the TODO list. Although I'll try to optimize the prompt calculation codes, there is a limitation in speed as far as it is implemented in Bash. I guess it won't be a problem if you are using a fast machine, but I cannot guarantee it.

Yes, totally understandable and answers the previous point, optimizations is the right thing to focus on. I wish bash supported right prompts natively, but until that comes ble's implementation is the best I've seen among bash prompts. I'll just close the issue, but feel free to reopen it for any updates on vim-airline

[akinomyoga]

I was more so referring that even when there was no previous command executed, quickly changing the terminal size (e.g. the window manager tiles it to half its size) causes some printing of the current right prompt (and sometimes the left prompt comes along) on top of the current command line.

Ah, OK. I misunderstood that the problem is in the previous lines. I'll later take a look at whether I could reproduce it on my side.

I'll just close the issue, but feel free to reopen it for any updates on vim-airline

I'm sorry, but I reopen it. I'll definitely update vim-airline for themes (I actually already have changes locally) and also for optimizations, but not now.

[akinomyoga]

I have added support for bleopt vim_airline_theme (73b037f) and optimizations (cf8d949, b2713d9) and a fix (321371f). There are still a few problems that need to be solved related to vim-airline. @huresche If you have a new GitHub account, could you try the latest version? Available themes can be found in the subdirectory contrib/airline. For more themes, you may checkout extra branch of the contrib submodule.

[akinomyoga]

It seems the OP @huresche has disappeared and doesn't seem to get back. I have been using this new vim-airline status line by myself and don't find serious problems. It works fine. So I'd now close the issue. Thank you!