Control whether to preserve working directory
When opening a new tab/window from a previous one, the working directory of the previous one (set via OSC 7) is preserved when the default shell is run, but ignored when a custom command is defined.
There are cases when it's desirable to keep the working directory, e.g. when there's a thin wrapper (such as luit
or env FOO=bar
) in front of the shell. We've also seen users requesting not to keep the working directory with their shells but to be dropped in their home all the time.
As per some off-gitlab discussion, we agreed to introduce a config option whether to preserve the working directory.
Not sure how much 706927 is related or not. I guess in that case the directory is defined as the actual cwd of the caller, rather than an OSC 7 string, but other than that, the very same config option could be respected.
Shall we make it a UI option?
Pro: It's more discoverable, user friendly, reaches more users, less questions on forums.
Con: It might make it harder (or impossible?) to clearly communicate the legacy "autodetected" behavior, or even to preserve the previous behavior.
Con: How to phrase the UI label? The feature of preserving cwd requires OSC 7 to be hooked up to PROMPT_COMMAND properely, which is not always the case. Will we get user complaints about the checkbox not working as expected?
How shall the underlying config option look like?
We can make it a boolean, defaulting to True (preserve cwd). In that case profiles with custom commands change their behavior, the user needs to adjust if it really matters.
Or we can make it a tri-state "maybe boolean", the default being the legacy autodetected behavior. Makes it harder (or impossible?) to hook up to a checkbox on the UI. Or, upon starting gnome-terminal, it could resolve the unset value to True/False according to the legacy autodetection (whether custom command is defined), and store the new value, so it's formally (in the schema) a "maybe boolean" but in practice a boolean. Is it worth it?
Or any other ideas?