On 22-06-27 11:06am, Stefan Sperling wrote:
> On Mon, Jun 27, 2022 at 02:45:04PM +1000, Mark Jamsek wrote:
> > 
> > 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.

Good point. I didn't really consider the overabundance of choice but
only narrowed in on the one I would use, which masked the fact we'd be
asking the user to make choices that they shouldn't have to worry about.
You just reminded me of one of Spolsky's articles about this :)

> 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).

I like the idea about making these key maps eventually too.


-- 
Mark Jamsek <fnc.bsdbox.org>
GPG: F2FF 13DE 6A06 C471 CA80  E6E2 2930 DC66 86EE CF68