Statusline disappears when doing "o" in split

[lobre]

I am not sure I can talk about a "statusline" as it might not exactly be implemented as such in neatvi.

But from what I understand, this line (that looks like "myfile" [-133] L5 C1) that is reserved for printing status is not permanent when there is a single window. So when doing <escape> or when a redraw is done, it disappears. That can make sense for single-window, as it makes the interface cleaner. If the user wants to see which file is currently displayed, he can do ^G. I don't know if it could be a desired feature to always have this "statusline"/name-of-current-file displayed at all times, but that is a topic for another issue.

However, when there are two splits, it seems neatvi is implemented so that this "statusline"/name-of-current-file is displayed at all times to clearly show the physical separation between the splits. Am I right?

If that is the case, when I enter insert mode with o (adding one line), it hides this "statusline" until back to normal mode. I find this weird and looks like a glitch. If I simply enter insert mode with i (not adding additional lines), this "statusline" stays.

[aligrudi]

But from what I understand, this line (that looks like "myfile" [-133] L5 C1) that is reserved for printing status is not permanent when there is a single window. So when doing <escape> or when a redraw is done, it disappears. That can make sense for single-window, as it makes the interface cleaner. If the user wants to see which file is currently displayed, he can do ^G. I don't know if it could be a desired feature to always have this "statusline"/name-of-current-file displayed at all times, but that is a topic for another issue.

The reason that neatvi updates the status line only when necessary is that it tries to reduce screen updates as much as possible.

However, when there are two splits, it seems neatvi is implemented so that this "statusline"/name-of-current-file is displayed at all times to clearly show the physical separation between the splits. Am I right?

Yes, exactly.

If that is the case, when I enter insert mode with o (adding one line), it hides this "statusline" until back to normal mode. I find this weird and looks like a glitch. If I simply enter insert mode with i (not adding additional lines), this "statusline" stays.

I agree that it looks odd, specially when showing multiple windows. This makes the implementation simpler. Neatvi defines a terminal region for each window and if the status line is not included in it, we need to reset the region whenever it is updated, or when entering insert mode; none of which seem very clean.

Ali

[lobre]

This makes the implementation simpler.

Makes sense if it is to keep the code clean.

One difference also that I see between single window vs two windows:

With two windows, if I try to enter a command such as :!echo hey, after the command has been executed, the statusline goes back to displaying the file name (same as what ^g does).

However, in single window mode, the statusline stays empty after a command.

Generally speaking, the statusline is cleaner when I have two splits. Otherwise, the filename often disappear when in single window mode. I don't know if this is also because you want to keep the code clean? But the inconsistencies feel weird.

PS: I still have `set nohl'.

[aligrudi]

Loric Brevet @.***> wrote:

This makes the implementation simpler.

Makes sense if it is to keep the code clean.

One difference also that I see between single window vs two windows:

With two windows, if I try to enter a command such as :!echo hey, after the command has been executed, the statusline goes back to displaying the file name (same as what ^g does).

However, in single window mode, the statusline stays empty after a command.

In single window mode, status line gives information about the current file, only if the last command causes the window to show another file.

To update the status line after every vi command, the following patch can be applied:

diff --git a/vi.c b/vi.c index f1f51d2..7f215a6 100644 --- a/vi.c +++ b/vi.c @@ -1640,7 +1640,7 @@ static void vi(void) if (msg[0]) strcpy(vi_msg, msg); }

• if (!vi_msg[0] && (w_cnt > 1 || opath != ex_path()))

• if (!vi_msg[0]) vc_status(); if (mod || xleft != oleft) { vi_drawagain(xcol, mod == 2 && xleft == oleft && xrow == orow);

  Ali

[lobre]

Thank you for the patch.

Maybe I am dumb, but I don't understand why the behaviour is not the same for multiple windows. Why is it redrawn permanently with 2 windows, but not with one?

I understand your argument about reducing the number of redraws, but on this occasion, why is it redrawn more often in 2-windows mode?

[aligrudi]

Loric Brevet @.***> wrote:

I understand your argument about reducing the number of redraws, but on this occasion, why is it redrawn more often in 2-windows mode?

When more than one window is visible, it usually helps to see what file is being edited in each of the windows.

Ali

[aligrudi]

Loric Brevet @.***> wrote:

If that is the case, when I enter insert mode with o (adding one line), it hides this "statusline" until back to normal mode. I find this weird and looks like a glitch. If I simply enter insert mode with i (not adding additional lines), this "statusline" stays.

Now the status line must remain visible. It won't be updated, however, until Neatvi returns to normal mode.

Ali

[lobre]

Now the status line must remain visible.

Thank you a lot, this fixes the issue and seems more consistent now.

I still struggle to adapt to having the status line always here on split and not always here on a full window, but this is another topic.

Should I close this issue then?

[aligrudi]

Loric Brevet @.***> wrote:

Now the status line must remain visible.

Thank you a lot, this fixes the issue and seems more consistent now.

I still struggle to adapt to having the status line always here on split and not always here on a full window, but this is another topic.

Should I close this issue then?

We can add an option for that. As the change to vi.c is trivial, I have not yet convinced myself that the option is really necessary though.

Ali

[lobre]

We can add an option for that.

I would personally appreciate having an option, even if enabling this behaviour is "opt-in", the user can still decide if he wants a more verbose xp vs a more performant one.

[aligrudi]

Loric Brevet @.***> wrote:

We can add an option for that.

I would personally appreciate having an option, even if enabling this behaviour is "opt-in", the user can still decide if he wants a more verbose xp vs a more performant one.

OK. Just added the ruler option. README explains its possible values.

Ali

[lobre]

Awesome, thank you a lot!!

Just out of curiosity, what does the x refer to in your variable? What is its meaning? I see you have multiple variables starting with x.

int xru = 1;

[aligrudi]

Loric Brevet @.***> wrote:

Awesome, thank you a lot!!

Just out of curiosity, what does the x refer to in your variable? What is its meaning? I see you have multiple variables starting with x.

int xru = 1;

It just shows that it is an ex edit option.

Ali

[lobre]

I understand, thank you. I am closing this issue as the initial problem has been tackled.