character based scrollbars

[mgrant0]

I have long wondered, has any thought been given to a character based scrollbar to scroll around in the copy buffer by clicking and dragging in the scrollbar? Scrolling using the mouse wheel works great. This seems like a logical extension of that. What I am imagining is a second pane or sub-pane (if that's the correct term) which contained a single column or two with a reverse color block or so (as in a space character with foreground and background colors inverted) forming the elevator part of the scrollbar. Clicking and dragging in the scrollbar would act similar to using the mouse wheel to scroll around in the copy buffer.

[nicm]

Would be possible but seems a bit of a waste of space to me. mintty has escaped sequences to let the application control the real window scrollbar which may be a better bet.

[mgrant0]

No not a waste! Please don't close this. I started looking at this but had some questions trying to figure out how it might be done.

Could such a thing be similar to cmd-split-windows where the new window is essentially 1 or 2 characters wide or tall. Inside this single character window, mouse clicks and drags would affect a scrollbar made of inverse space characters on an empty background.

It is a useful convenience to be able to scroll around the copy buffer. Sure you could argue it's not useful because you can use the keyboard to scroll around. But this gets tedious. And if the window were local, like a local xterm, you would be able to scroll around it with the scroller. But tmux is doing all this remotely which is super useful. So a remote scroller would also be useful in this same way.

[nicm]

You'd just do it in copy mode so make the area of the copied text one column narrower and draw the scrollbar in this space like how it draws the x/y position in the top right. Look at window-copy.c.

[mgrant0]

Mintty is based on PuTTY without the networking. Any idea if PuTTY supports these escape sequences to let applications control the copy buffer scrolling? How might I try and enable that in tmux? If that indeed works in PuTTY, then you're right, this would be better. If not, I will still like to try and implement this.

[nicm]

Wrong mintty (there are two), it is this one https://github.com/mintty/mintty/wiki/CtrlSeqs#application-scrollbar.

Something usable on every terminal would probably be better in the end I guess.

[anazachide]

I would enjoy such feature, maybe it would be good to reopen this thread?

[mgrant0]

Here is a mock-up of what I imagined this looking like:

I envision a couple of new tmux commands which enable and disable a scrollbar in a particular pane.

I see no reason there couldn't also be a horizontal scrollbar in a pane as well, but what would control the horizontal size of a window? Would it be possible to automatically set the width of the window based on the longest line in the window so it never wrapped? I have to admit I never saw a terminal program do that.

To be clear, the scrollbar is there all the time regardless of being in copy mode or not. If you scroll up, then, you are in copy mode. The idea being that you can trivially just scroll up and look back at what's above. Hit a key and you're at the bottom again, back at the prompt. Very much like a real scrollbar.

Maybe if tmux reacted to the escape sequences for scrollbars like mintty reference you sent above, I wonder if programs like emacs would be able to put scrollbars on each buffer. That...would...be..cool...

If you still think this should be done in window-copy.c, let me know. Any hints appreciated. It's going to take me a bit to understand the innerworkings of tmux to do this. I may need help....

[mgrant0]

xterm -leftbar
xterm -rightbar

[nicm]

Right but it is in a minority, I don't think you can do it on most major platforms. But I don't mind allowing it, it can work like the pane status line where you specify the position per window, and in the same fashion - if you set it to left it adds the extra border to the left of the leftmost pane and the left border of every pane is its scrollbar; if you set it right it adds the extra border to the right of the rightmost pane and the right border of every pane is its scrollbar. I think the scrollbar should definitely be part of the border but whether you want to make it always right or configurable is up to you. It will be more work to do both because to add column to the left you will need to adjust the horizontal position of every pane rather than just reducing the size of the rightmost panes.

[nicm]

I don't think X and xterm are great examples since the UI has not been changed much since about 1985. Can I do it on macOS? Windows? Android? Chrome or Firefox? Even Qt? If this was something lots of people wanted they would have support. Hardly any non-GUI applications have scrollbars at all...

But I don't really mind either way, it will make more work though so I would probably get right-only working first.

[mgrant0]

In your opionion, should this be enabable on a pane by pane basis? Or would this be on all panes being displayed? My feeling is it should be off by default. Something settable can turn it on for new windows, or an option to the new-window cmd, and a tmux cmd that can turn it on or off in a specific pane.

Also, getting into vi or other program that would normally disable the scrollbar should disable it (not necessarily make it go away and regain the realestate but disable it like it does in PuTTY). Is this the tty's alternate terminal screen? I don't think it is because I have that option disabled in PuTTY and vi does this anyway.

The reason I bring this up is does it make more sense to try and implement this like an extension of the terminal window like mintty? What is the correct way to allow a program such as vi control whether the scrollbar is active as in PuTTY's scrollbar.

[nicm]

You will need to do these things I think:

• Add an option like pane-border-scrollbar.

• In layout.c, do the same sort of dance as for pane-border-status but for your new option. Look for pane-border-status and how layout_add_border is used. That will give you a blank column on right (or left if you choose to add it too) to draw the border for rightmost (or leftmost) pane.

• In screen-redraw.c adjust whatever is needed to draw your new border, probably need to change several of the functions to take the new column into account, and add a function like screen_redraw_draw_pane_status to draw the scrollbars.

• Handle mouse clicks on the scrollbar. I think nicest would be to add a key like MouseScrollBarJump or something which stores the scroll position in the struct mouse_event and then fires the key binding like a normal mouse key (this would all be in server-client.c). That way people can change the flags they pass to copy-mode when copy mode is entered, and inside copy mode you can just handle the key binding directly. If you want Up and Down parts of the scrollbar I'd add MouseScrollBarUp as well and make it fire copy-mode -u or copy-mode \; send -X halfpage-up or a new flag or something. And once inside copy mode handle it directly.

• Looks like will need some changes in format.c, window.c and cmd-resize-pane.c - look for PANE_STATUS_TOP and PANE_STATUS_BOTTOM.

I think the incremental redraw will just work because it will realize the pane doesn't end a the edge of the terminal, so won't try to wrap. And likewise I think overside windows will just work.

[nicm]

In your opionion, should this be enabable on a pane by pane basis? Or would this be on all panes being displayed? My feeling is it should be off by default. Something settable can turn it on for new windows, or an option to the new-window cmd, and a tmux cmd that can turn it on or off in a specific pane.

Not each pane, all panes in a window or none. No flag to new-window, just an option.

Also, getting into vi or other program that would normally disable the scrollbar should disable it (not necessarily make it go away and regain the realestate but disable it like it does in PuTTY). Is this the tty's alternate terminal screen? I don't think it is because I have that option disabled in PuTTY and vi does this anyway.

I think entering the alternate screen should disable the scrollbar but not hide it. That is, the pane should stay the same size.

The reason I bring this up is does it make more sense to try and implement this like an extension of the terminal window like mintty? What is the correct way to allow a program such as vi control whether the scrollbar is active as in PuTTY's scrollbar.

I think this is premature. mintty has had this extension for years and so far no applications use it. I would make it work for tmux's own copy mode and then see about implementing mintty's application escape sequences.

[mgrant0]

Ok so I thought I'd try putting the scrollbar inside the border. I added code to only add a border if the panel was on the edge exactly like the pane-border-status. And now something weird is happening. With 1 column is stolen from the pane, the empty space looks like this:

With no extra columns, but just adding the scrollbar on the right if enabled, the empty space looks like:

but if there's 2 panes stacked vertically, the empty space looks like this:

Why is it using the ├ character, shouldn't it be │ (except for where it joins the horizontal border)? It doesn't do this when there's an extra column next to the border. Even the case where it's just a ·, it should really be a │.

When I draw the scrollbar, should I overwrite the entire vertical extent of the pane border, in other words, recreate the border myself? I'd prefer not to do that. tmux already handles the borders and styles, so I'd definitely not like to reinvent that wheel.

It seems like the panel status just overwrites a part of the border, it seems like the scrollbar should do the same. This way, I don't have to recreate the code which draws those lines. I just have to concentrate on dropping a scrollbar elevator somewhere. I wonder if the border will get refreshed if the elevator moves, meaning, if I move the elevator up, will the border reappear where it was? I guess we'll see.

After thinking about this a bit, I'm guessing there's an unintended display bug at the edge of the screen that needs fixing and I should just drop an elevator over the border.

[nicm]

screen_redraw_pane_border or screen_redraw_cell_border are where it decides what part of the border each cell belongs to. You are adding a new case that could not previously happen so probably they don't understand it - previously if a pane's righthand edge was not at the right of the screen, there must be a pane to the right. You will need to change them to differentiate your new "border at edge" from either empty space (first screenshot) or a join to a pane on the right (second screenshot).

You can overwrite what tmux puts there, that's what the pane statue line does.

[mgrant0]

Ok, should be able to deal with that.

Meanwhile, I may have found a bug in sceen-redraw.c. Have a look at this diff:

diff --git a/screen-redraw.c b/screen-redraw.c
index ce79b41f..c75b990e 100644
--- a/screen-redraw.c
+++ b/screen-redraw.c
@@ -131,11 +131,10 @@ screen_redraw_pane_border(struct window_pane *wp, u_int px, u_int py,
        /* Left/right borders. */
        if (pane_status == PANE_STATUS_OFF) {
                if (screen_redraw_two_panes(wp->window, 0) && split) {
-                   if (wp->xoff == 0 && px == wp->sx && py <= wp->sy / 2)
+                 if (wp->xoff == 0 && px == wp->sx)
                                return (SCREEN_REDRAW_BORDER_RIGHT);
                        if (wp->xoff != 0 &&
-                       px == wp->xoff - 1 &&
-                       py > wp->sy / 2)
+                     px == wp->xoff - 1)
                                return (SCREEN_REDRAW_BORDER_LEFT);
                } else {
                        if ((wp->yoff == 0 || py >= wp->yoff - 1) && py <= ey) {

It makes sense to divide by 2 when the screen is split top/bottom, but when you divide by 2 here when the screen is split left/right, it does something very strange when I reduce the size of the panes. Is this a bug?

Here's what it looks like before I made the above change:

[nicm]

Can you put your diff in ```` or ~~~~ since I can't see what you are doing?

[mgrant0]

done, i noticed that too on reload!

[nicm]

This is for the split line, note the && split. If you apply your diff the colouring will go missing, the central border here is half the left border of the right pane and half the right border of the left pane.

[mgrant0]

Ok, hmm, I literally never even noticed that on my screen! Is it important to keep that? Assuming yes, I wonder if I can fix the border issue if this will fix this too and keep the split colour. Or do you have a suggestion what to do here?

[nicm]

yes it is important to keep it at least when the scrollbar is off

[mgrant0]

Ok I read through and think I understand screen_redraw_pane_border() now. So I see, there's no lower border on one pane and no upper border on the other. When I pulled the panes apart, it's obvious now what's going on.

I played around with some ideas here. It definitely helped me understand what was going on. For example, this:

if (wp->xoff == 0 && px == wp->sx) { 
    if (py <= wp->sy / 2)
        return (SCREEN_REDRAW_BORDER_RIGHT);
    else
        return (SCREEN_REDRAW_BORDER_LEFT);
    }
}

and also tried commenting out the subsequent if that draws the right border. I was hoping by returning SCREEN_REDRAW_BORDER_LEFT for the lower half it would be a different colour but nope.

I can make it indicate the active pane by flipping the colour on the whole border but not half when there's a scrollbar.

Can we move the pane-border-indicators to somewhere else in the code that chooses which colour or character to use? Then, this option would likely work on all panes, not just on 2 side-by-side panes. For example into screen_redraw_draw_borders_cell(). But I don't yet fully understand that function. Or maybe in screen_redraw_draw_borders(), check the x or y and if pane-border-indicators is colour or arrows, and send in an extra arg into screen_redraw_draw_panes()? Or do you have any cleaner ideas?

As soon as I can get past these border issues and have a space to draw the scrollbars in, then, the fun begins...

[mgrant0]

Could you please tell me what controls whether the border is white or green? As in, when it's a left or right border, what controls what colour to make the border character?

[nicm]

One is pane-active-border-style and one pane-border-style and it picks the first one if the cell is part of the active pane and the latter if it is not, look at screen_redraw_draw_borders_style.