add 'auto cd new terminal' config option

[chrysos349]

I am among the few users who dislike the new behavior introduced in the ticket #3088 (https://midnight-commander.org/ticket/3088), which is enabled by default with no option to disable it.

I would like to request an option for Midnight Commander to ignore the OSC 7 sequence, ensuring that all my tabs open to $HOME. Please consider adding this configuration option.

P.S. egmont did all the work to make the patch possible; I merely voiced my concerns here. :P

[zaytsev]

I explained why I don't want an option in #3088.

Also, it seems wrong to do it in mc. If you don't like mc reporting OSC 7, then you won't like other software like vim doing it. So the right place to configure this would be the terminal emulator.

Finally, Egmont suggested a workaround (cd to $HOME in the profile) if your terminal doesn't have this option and you don't want to implement it. Why wouldn't you want to implement this solution?

[pinchartl]

I've also been annoyed by OSC 7 support disturbing my workflow, but I'm not sure whether the issue is on midnight commander's side, or in my terminal emulator (yakuake). The main problem in my case is that mc doesn't restore the current working directory through OSC 7 when it exits. It creates a discrepancy between the current directory as shown in the shell, which is the directory mc was started from (I don't use mc-wrapper.sh), and the current directory known to the terminal emulator.

For instance, if I start mc from ~, and then enter ~/src, yakuake will correctly show ~/src as being the current directory in its status bar. I then exit mc, and the shell shows ~ as being the current directory. Opening a new tab in yakuake then starts in ~/src, which is very confusing.

Something is missing here, but I can't tell which component is at fault.

[zaytsev]

Hmmm, that's interesting. So maybe we should remember where we were started and emit OSC 7 just before we shutdown? Egmont, does it make sense to you?

[egmont]

So maybe we should remember where we were started and emit OSC 7 just before we shutdown? Egmont, does it make sense to you?

No, this doesn't make sense to me.

Some shells are configured to emit OSC 7 on directory change, or upon printing the prompt; some aren't. Some other apps, maybe similar ones to mc, similarly may or may not emit OSC 7 when they change the directory.

OP here claims that an app like mc should not (or at least should have an option not to) emit OSC 7. Along these lines, it's reasonable to assume that such users would want their other apps, and presumably also their shell, not to emit OSC 7.

Therefore, whenever mc starts up, the actual working directory and the terminal's OSC 7 idea about it might be different. Emitting OSC 7 upon quitting would just further complicate the situation and not fix anything. E.g. if mc was started up from /etc, but no OSC 7 seen yet (because the shell is configured not to emit any), OSC 7 would set /etc whenever you quit mc and thus from this point onwards your new terminal tabs would open in /etc.

It's not possible to query the current OSC 7 value, only to set a new value. So the only "source of truth" could be the working directory at startup, which is already potentially different from OSC 7 at that time.

---

Just occurred to me: What could maybe make sense IMO, is to update OSC 7 in mc-wrapper.sh whenever it changes the actual working directory for one last time. Technically this would require duplicating the escaping logic in shell script. Also, since the invoking shell is likely to follow up by printing its prompt, in practice this probably wouldn't make much difference. And it wouldn't solve OP's current problem. So I guess we can ignore this idea for now.

---

Also, it seems wrong to do it in mc. If you don't like mc reporting OSC 7, then you won't like other software like vim doing it. So the right place to configure this would be the terminal emulator.

I agree. In practice, however, terminal emulators usually don't provide such an option. I wonder why not. Maybe it should be a feature request against them.

In practice, cd'ing to HOME from the shell startup file is an easy and robust workaround.

I'm not firmly against adding an option to mc, but in the grand scheme of things I just don't think this is the desired place to fix it. This also wouldn't protect against scenarios when the terminal emulator itself is started up with a different working directory.

Both the terminal emulator and the shell sound better places to me than mc to fix this.

[egmont]

OP didn't reveal their choice of terminal emulator. Just FYI, the one that I'm the most familiar with, namely GNOME Terminal, has had a corresponding config option for about 5 years now (Preferences -> choose the desired profile -> Command -> Preserve working directory).

Also: most terminal emulators allow you to configure the command it launches, and a custom command like env --chdir=/home/username bash could also do the trick.

[egmont]

Okay, just realized that the original post and the followup comment were made by two different people.

@pinchartl I'm not sure what happens exactly: Does your shell update OSC 7 when printing its prompt or does it not?

If not then I guess you go out of sync as soon as you cd to any directory, with no mc involved at all.

If it does then why doesn't it immediately emit the proper OSC 7 after mc quits?

We need more info to understand the entire setup, and thus whether there's anything mc could do to improve it.

[pinchartl]

Replying to egmont:

Okay, just realized that the original post and the followup comment were made by two different people.

@pinchartl I'm not sure what happens exactly: Does your shell update OSC 7 when printing its prompt or does it not?

I don't think it does, but I'm not entirely sure how to check that. There's no OSC 7 sequence in $PS1 at least.

If not then I guess you go out of sync as soon as you cd to any directory, with no mc involved at all.

yakuake can still track the current directory of the shell even when no OSC 7 is emitted. I dug in the source code, and this is implemented in the Konsole::Session class by getting the current directory of the process running in the terminal. When a working directory is reported through OSC 7, it will take precedence forever.

As it is based on the same KPart, the konsole terminal emulator exhibits the exact same behaviour.

As implemented today, the Konsole::Session class seems to assume that either nothing reports OSC 7, or everything does. Is that a valid assumption to make ?

If it does then why doesn't it immediately emit the proper OSC 7 after mc quits?

We need more info to understand the entire setup, and thus whether there's anything mc could do to improve it.

Thanks for trying to understand it with me :-)

[egmont]

Replying to pinchartl:

I don't think it does, but I'm not entirely sure how to check that. There's no OSC 7 sequence in $PS1 at least.

Let's assume then that it doesn't.

yakuake can still track the current directory of the shell even when no OSC 7 is emitted. I dug in the source code, and this is implemented in the Konsole::Session class by getting the current directory of the process running in the terminal. When a working directory is reported through OSC 7, it will take precedence forever.

This is semi-surprising. It didn't occur to me that it could do this; although Ubuntu still patches their GNOME Terminal to also do the same.

As implemented today, the Konsole::Session class seems to assume that either nothing reports OSC 7, or everything does. Is that a valid assumption to make ?

Honestly, I don't know.

This escape sequence, to my best knowledge, originates from the macOS Terminal.app, and I don't know (probably noone knows) what the intent was regarding the big picture, i.e. who is responsible of doing what exactly.

One possibility would be to emit an empty OSC 7, that is, with an empty URL. I don't know if terminals handle it as a means of unsetting it, i.e. behaving as if no previous OSC 7 had ever been encountered. So this is only an option if someone verifies that the vast majority of the terminals interpret it this way. Also, even in that case, if someone wants to have full OSC 7 experience, there'd be a brief moment when mc is quitting when the value is unset, thus opening a new terminal at that moment wouldn't preserve the directory.

We could also check how certain resetting escape sequences (e.g. the standard "hard" reset which clears the screen and stuff, so would be way too intrusive; or the "soft reset" which would be acceptable to emit) clear the OSC 7 value. This could be another approach to consider.

I don't have access to a mac to check the originator Terminal.app's behavior wrt. both of these questions (empty OSC 7, or various resetting sequences), nor do I know off the top of my head what GNOME Terminal does in these cases (let alone with its Ubuntu patch that us mainsteram devs really frown upon).

A potential problem with Yakuake's approach is that anyone can emit such an OSC 7. It could be yet another app that you don't regularly use, just start up maybe by accident and then quit suddenly. Or could be a script log that you replay. Or a text file that you cat. An escape sequence shouldn't be able to have an effect for the rest of the terminal session. At the very least a "hard reset" escape sequence should revert to the default behavior. But that's not good for mc to emit. So the question is more whether a "soft reset" or an empty OSC 7 could be used as a workaround.

I don't know what OSC 7's designers had in mind (if they thought about this question at all). That being said, relying on no application ever to emit that sequence because then the terminal is broken for the rest of its lifetime, really doesn't sound good to me; and if that's indeed the case then I'm probably tempted to argue that that's a bad design in the terminal. But, alas, if a hard reset resets this probably then we're out of luck: the terminal's behavior is reasonable, after all you can easily fix up a broken scenario; however, this approach is too intrusive for mc to use.

Not sure if we got closer to seeing what the proper solution would be.

[egmont]

I've just tried Yakuake.

In its profile editing dialog, under General -> General Settings there's a checkbox, enabled for me, labeled "Start in same directory as current session".

Isn't it just a matter of disabling this option?