On Mon, Jun 27, 2022 at 02:45:04PM +1000, Mark Jamsek wrote:
> I really like the idea of making TOG_VIEW_SPLIT_HEIGHT relative--I think
> it's a great idea! Certainly much saner and also more comprehensible;
> It's more common to think, "I want the bottom split about half my screen
> height."
> 
> > > So if the user does nothing the only change in existing behaviour is
> > > that we'll open a horizontal split when COLUMNS < 120 (i.e., when we
> > > would normally open child views in fullscreen mode now).
> > > 
> > > Horizontal splits are supported in log -> diff, tree -> blame, ref ->
> > > log, and blame -> commit. So all the main views will open their primary
> > > child view in a horizontal split, but we haven't yet got some of the
> > > secondary child views (e.g., 't' or 'r' key maps from log view).
> > 
> > Ideally, horizontal split would happen wherever vertical split happens now.
> > Otherwise the new behaviour is inconsistent and will be confusing people.
> 
> Okay. How about something like this:
> 
>   - TOG_VIEW_SPLIT_MODE is not set (i.e., user does nothing): keep the
>     current behaviour (i.e., views open in vsplits when terminal is wide
>     enough).
>   - TOG_VIEW_SPLIT_MODE is set to 'h': open child views in hsplits
>     (vsplits are never opened).
>   - TOG_VIEW_SPLIT_MODE is set to 'a' (auto): open child views in
>     vsplits if the terminal is wide enough, otherwise we open them in
>     hsplits. I would use this mode myself as I like vsplits when I run
>     wide terminals, which is most of the time. But when I open vertical
>     panes in tmux and they're no longer wide enough for a vsplit, I'd
>     like a hsplit to open instead. This way I don't need to keep
>     resetting TOG_VIEW_SPLIT_MODE from v to h when I'm in different
>     sized tmux panes. I can just set it to auto and forget.
> 
> So this way if the user does nothing, the behaviour stays the same. If
> they explicitly set hsplits then only hsplits are opened instead of
> vsplits so behaviour remains consistent. And only if they explicitly set
> auto mode then we get dynamic sizing.

This seems a bit complex. There is a lot of choice on offer here, and
to figure out what's best the user would have to try the various options.
With configuration in environment variables, users need to keep restarting
tog to play with the settings. I don't think many people will invest a lot
of time into this. Rather, they will probably start with whatever defaults
we pick and probably keep using those.

How about we forget about user-visible configuration, and make it behave
in only one way, for now. The code shpould of course be written to avoid
hard-coded behaviour, such that we can use compile-time constants to tweak
things and find settings that everyone of us would be fine to live with.

Later, instead of requiring users to set window-splitting parameters upfront,
we could offer keybindings to shrink/grow them as needed (much like tmux
handles dynamic resizing of panes).