Looks OK but I don't like the option name, it should be something starting with pane-border- to match the others.

I'm not sure about having WINDOW_PANESMODE rather than generic flags and if we do have it those fixes seem like they are separate?

In window_panes_mark_per_pane_borders, you need {} around the if bodies where they cross multiple lines.

In screen-redraw.c, we do not want to call options_get_number for every pane, this is a window option and can be cached.

I don't like pane-border-surround. Feels like this should be part of pane-border-lines but not sure I want to double the number of choices. Leave it as it is for the moment and I'll think about it.

Maybe pane-border-type (or -model or something?) and choices are joined or separate?

Yeah, pane-border-type with joined or separate sounds as good as any? Let me make that update.

New option needs to go in tmux.1 also.

OK a few minor issues:

• When I have two panes side by side or one above the other, only one of the borders works to resize when dragged with the mouse, the other border does not (behaves as if inside pane).

• selectp -U, -L etc do not work.

• {left}, {top} targets are also broken, probably for the same reason (selectp -t '{top}').

• main-vertical seem to place the right hand border of the right pane outside the window in some circumstances (seems to depend on what the width and height is). Same for main-horizontal with the bottom border.

• There are similar problems with placement of cells after resize, for example try this, the right pane is now outside the window:

tmux new \; set -g pane-border-type separate \; splitw -h \; resize-pane -x 1

I also think we could do with adding test coverage for this feature.

I did find another bug. When you have pane-border-status enabled, and click on x, it seems impossible to click on yes. But the bug seems to exist in master too so I didn't bring it up. Shall we include a fix for that too?

I do not see this problem in master, the menu works fine. How do you reproduce?

On master, set status-position to 'top' and pane-border-status to 'top' or 'bottom'.

It works OK for me but the mouse position is one line off, I'll fix it.

I have always wanted this feature, thanks for implementing it! I just tested it out on a local build and it seems to work great, <3

Thank you, very encouraging!

@nicm, I believe we've hit all points, yes?

I'm away but I'll look when I'm back on Monday, thanks.

Looks pretty good. Two other minor issues:

• splitw can still create panes that are too small, for example splitw -fh -l 1. These can end up with the border overwriting other pane borders instead of resizing them, for example:

• The same thing can happen with selectl -E, for example:

./tmux -vvLx new \; set -g pane-border-type separate \; splitw -h \; splitw -h \; splitw -h \; resizew -x10 \; selectl -E

Thanks! Pushed fixes and tests to address both.

If you do this:

./tmux -Lx new \; splitw -fhl1 \; set -g pane-border-type separate

You end up with the right pane wrong. Not sure if this is worth fixing if it isn't easy.

This does not work properly (the selectp -D does not change the pane):

./tmux -Lx new \; set pane-border-type separate \; set pane-border-status bottom \; splitw -v \; selectp -D

I think redraw_draw_ctx could do with a cached border_type as well for redraw_draw_border_span.

This may be an existing problem - this is an error:

./tmux -Lx new \; resizew -x 5 -y 8 \; set pane-scrollbars on \; set -g pane-border-type separate \; set pane-scrollbars-style 'width=2,pad=1' \; splitw -h

But this gets in a muddle instead:

./tmux -Lx new \; resizew -x 5 -y 8 \; set pane-scrollbars on \; set -g pane-border-type joined \; set pane-scrollbars-style 'width=2,pad=1' \; splitw -h

I think both cases should be an error.

Interesting, let me have a look.

Okay pushing updates:

For item 1: on options_push_changes for pane-border-type, reflow so cells under the new minimums grow.

For 2–4: fix select-pane wrap with separate + bottom status; cache border_type on the draw context; for always-on scrollbars, LEFTRIGHT space counts both bars so tiny splits fail cleanly instead of leaving broken pane sizes.

OK there are still some minor things with small windows, but TBH I am not wild about layout_rebalance_mins and friends, they seem like overkill. I wonder if we should access some weirdness to get away from having to do this, so long as tmux does not do anything really crazy or crash.

Let me spend a few more hours later to see if I can think of a cleaner fix?

OK thanks. TBH I think we could probably live with the borders overlapping at small sizes so long as tmux does not crash or behave incorrectly. Anyone with a window that is just too small for the panes can't really expect it to work usefully, so long as it goes back to normal when the window is big enough again.

When the window is big enough it should probably do the right thing with small panes though.

Just pushed updates that revert the layout rebalance helpers. Yeah, it is definitely an edge case (didn't want to miss the chance to use that pun).

The broken case seems to occur specifically when you do the split while in joined border type and then switch to separate. No odd borders when you do the split while already in pane-border-type separate:

  ./tmux -Lx new \; set -g pane-border-type separate \; splitw -fhl1

Chances are most users won't switch between joined and separate that often, or have enough splits in a tiny window to hit this. Happy to leave it as accepted weirdness for such edge cases.

I think this is OK but I am away next week so I will probably not look at it until I am home again. This will be a 3.9 feature in any case.

Thank you for taking care of this!