Allow different `window-inherit-working-directory` behavior for tabs and windows

[adrianord]

I would like to have different behaviors for the window-inherit-working-directory option, either through a new option like tab-inherit-working-directory or a command that can be bound through a keybind option.

Use case would allow for news tabs to inherit the working directory while a new window would open the home directory, or vice versa.

[mitchellh]

My recommendation would be to change window-inherit-working-directory to an enum, with possible values: false (never), true (always), tab (only new tabs), window (only on new windows) or something like that. We may have to use a packed struct to allow multiple options too, so you can set tab, window, split, etc. That'd require slightly new config parsing code but it's not significant. I think that's better than a new option.

[jparise]

I started working on this. The configuration aspect was straightforward, but I slowed down implementing the actual logic (in newConfig). My initial feeling was to do something like:

        const inherit_pwd = switch (config.@"window-inherit-working-directory") {
            .true => true,
            .false => false,
            .tab => is_tab,
            .window => !is_tab,
        };
        if (inherit_pwd) {
            if (try p.pwd(alloc)) |pwd| {
                copy.@"working-directory" = pwd;
            }
        }

... but I'm not sure how to derive an is_tab value here or thread it through as an option. It seems like the Surface type doesn't know whether it's being presented as a tab or a window, and that's handled by the various "rt" implementations without a common interface?

Or maybe we should set the new config's @"working-directory" value elsewhere?

I'm happy to finish implementing this with a little more guidance on what other bits should change.

[mitchellh]

It seems like the Surface type doesn't know whether it's being presented as a tab or a window, and that's handled by the various "rt" implementations without a common interface?

That's right.

I think that the answer is that newConfig needs to take a surface kind enum. Looking quickly at the code, newConfig is only triggered by apprts via more specific callbacks like newTab, newWindow, etc. so it doesn't seem difficult to make that information available to it.

I'd try to limit the core's actual knowledge about this and keep it within the apprts.

I'm not 100% sure that'll work, its hard to say without actually trying to go through it myself, but that's what I'd try first.

[clason]

We may have to use a packed struct to allow multiple options too, so you can set tab, window, split, etc.

I would second that suggestion; personally, I would like for new tabs to "start fresh", while a split is more like a second "view" on the current context (i.e., should inherit cwd).