Tell the current directory to gnome-terminal

[egmont]

Gnome-terminal has had a cool feature for ages: when you open a new tab, it opens in the same directory as the one that was previously active. This gives a huge productivity boost. G-t used to achieve this by looking at the tab's immediately child (typically a shell), and checking its cwd under /proc. This way it was impossible for it to know MC's current directory.

G-t 3.7.0 (vte 0.34.0) changed the implementation: g-t no longer digs into /proc to figure it out automatically, it's the shells responsibility to tell it to g-t.

To test: if you have g-t >= 3.7.0 then execute this

echo -ne $'\e]7;file:///usr/bin\a'

and then open a new tab, it will open in /usr/bin.

The directory has to be URI-encoded, that is, prefixed by ​file:// and special characters encoded with %.

It would be really cool to have an option so that MC sets this whenever the directory is changed, pretty similar to the way it can update the window title. This way whenever you opened a new tab in g-t, it would open at the directory where you are in MC.

​https://bugzilla.gnome.org/show_bug.cgi?id=675987
​https://git.gnome.org/browse/gnome-terminal/commit/?id=7f185514f5fad3cea10bed6ee8057379e25a3573

[egmont]

The feature seems to originate from Mac terminal, here's a good description:
​http://superuser.com/questions/79972/set-the-title-of-the-terminal-window-to-the-current-directory/321733#321733

Apparently the hostname should also be included in the URI so that the terminal knows if the shell is running on a remote host.

There's also a way to set the current filename. It might make sense to set to the name of the file being viewed/edited, or maybe even to the file where the cursor is. I'm not sure how this is being used, as I don't have access to Mac.

[egmont]

Note: as opposed to the xterm window title, we should take care not to set it when on VFS.

[egmont]

first version

[egmont]

I've added a version that works nice, but maybe still needs to be cleaned up a bit.

The feature has to be enabled in Options -> Configuration -> Auto cd new terminal.

It's disabled by default because the escape sequence that it prints messes up the display of old gnome-terminal (vte < 0.34). Other graphical emulators I've tried (xterm, konsole, urxvt, putty) ignore the sequence. The Linux console also becomes messed up, hence I added a check for xterm-like terminal.

TODOs:

Find a good name for this option, and find a shortcut key in the config dialog.

Figure out where the code should go in the source tree. Right now it's in filemanager/layout.c because the work was heavily based on the "xterm window title" feature which is there. But this new feature has nothing to do with the "layout". For the same reason I decided not to put the config option next to the xterm one.

Figure out when to call the method. This might depend on ticket #3090. Right now I'm calling this whenever the xterm window title is also updated. But it might be a better place to call it when the command prompt is updated, or when mc actually performs a chdir(). Although mc seems to call chdir() back and forth for both panels which would impose a short race condition here.

Please test the patch with Mac Terminal.app (>= Lion) or Gnome-terminal (>= 0.34). Expected behavior: when opening a new terminal tab, it should open in mc's current directory (unless it's a remote directory or an archive file or such). It should work even if the path contains all kinds of weird special characters.

A note for Konsole: when opening a new tab, it seems to look not only at the immediate child of the current tab, but somehow digs deeper and finds the actual "active" (?) process and takes its cwd. So in konsole you see this behavior even without this patch.

[egmont]

Sorry, I meant: test with Gnome-terminal >= 3.7 (which depends on vte >= 0.34).

[egmont]

I've been happily using this patch for 2 months, it makes opening a new terminal tab much more convenient. I just press Ctrl+Shift+T in gnome-terminal, and the new tab opens in the directory where I navigated to in MC. A convenience feature I could hardly live without, once I got used to it.

Dear developers, could you please comment on this, would you accept this feature to MC? If so, could you please help finalize the implementation (as detailed in comment 3)?

[egmont]

Friendly ping - dear developers, any comments on this?

Note to myself: Should use g_filename_to_uri() rather than manually crafted code.

[mgedmin]

/etc/profile.d/vte.sh, shipped with the libvte package on Ubuntu, does an explicit check

# Not running under vte?
[ "${VTE_VERSION:-0}" -ge 3405 ] || return 0

Midnight Commander could look at this environment variable and determine whether it needs to emit the OSC 7 escape code whenever the current working directory changes.

This would help Mac terminals, but would autodetect gnome-terminal versions that support and need this escape.

[egmont]

updated to newest mc

[zaytsev]

Aha, so that's why this feature doesn't work in latest Ubuntu :-/

Maybe mooffie is right though and this kind of stuff should be all offloaded to the scripting engine? Of course, the engine should first get merged, and then a consistent effort has to happen to strip the auxiliary niceties, where auxilariness of features might become a subject of sharp debates, but maybe mc-4.6 could be a good baseline...

[egmont]

OSC 7 is now supported by:

• Mac:
  • the default Terminal.app
  • the extremely popular iTerm2
• VTE-based:
  • the standard GNOME Terminal
  • the well-known tiling emulator Terminator
  • the shiny brand new tiling emulator Tilix
• KDE's Konsole

The list may be incomplete.

I've also just filed feature requests for VTE-based emulators mate-terminal, xfce4-terminal, sakura and tilda.

Do you guys mind if I move forward and finalize the patch, aiming for 4.8.21?

I would even enable it by default, and wouldn't bother with any kind of autodetection. The only terminal emulator I'm aware of that does not at least silently ignore OSC 7 is the ancient Gtk2-based VTE, practically only used by Guake nowadays.

[zaytsev]

I don't mind, but could you please tell me what will happen in ancient Gtk2-based VTE? Sadly I still use it... Will it be broken in some way?

[egmont]

Yup, display corruptions will happen if this option is enabled.

I guess I can be convinced to keep this option disabled for now... but I'd also like to understand why you (or people in general) still use that ancient VTE version :-)

[egmont]

updated to current git, plus minor cleanups

[egmont]

Attached an updated version.

Issues from comment:3 are still to be addressed.

In particular, I don't like the name "Auto cd new terminal" in the config dialog and I cannot find a good (and short) one.

Also, we're pretty much out of hotkeys in the config dialog. In English, only 'j', 'q', 'x' and 'z' to go, and none of these letters appear in any of the existing option names, so we cannot shuffle the hotkeys around.

I wouldn't even want to refer to the escape sequence "OSC 7" on the UI (even though it would allow '7' as the hotkey) because that's so user-unfriendly.

Suggestions welcome :)

[zaytsev]

I can be likewise convinced to disable it for if it's a configurable option (it seems this is exactly your plan) or patch it out.

Unfortunately, there is no good reason for me to use an ancient VTE. It's just that I tend to throw away operating systems together with the hardware they're running on. In practice, this means that my 7yo private laptop is still running the same system I installed when I bought it, and I've been compiling from source to get newer versions of software I absolutely need. Given that I mostly only need a terminal, mc, alpine, irssi, a web browser + IDEA this has been a viable strategy for the last 15 years, and the stuff has grown so complex it's a project on its own to reinstall. Last time I reinstalled was some 5 years ago, when I gave now 12 years old laptop to my parents. I guess I will have to buy a new laptop in the coming years, because both 7 & 12 year old ones are starting to show their age... ;-) but I'm so busy I can't afford making time for it unless I'm really pressed against the wall and there is no way out :-/

I hope this answers your question, but I'm not sure if this would make you any happier; most likely you'll end up concluding that I'm nuts, which is not far from truth.

[egmont]

Thanks for your detailed answer :)

The pattern you describe is not really practical, at least in the sense that after so much time vendors typically stop supporting the system and stop shipping even critical security fixes. As such, I believe most people update at least a bit more frequently than you do.

More importantly: I believe that most people who update rarely (like you do) not only have a potentially quite old base system, but also have a correspondingly old mc. So this shouldn't stop us from introducing new stuff. Using a cutting edge mc on a 7 year old system is probably unique to you and maybe like a dozen folks around the globe.

However, mc seems to be quite conservative here, e.g. it tends to keep a window of 5-7 years before requiring newer glib. (I'd be totally okay with decreasing this window size to maybe like 1-2 years.)

What I see being more risky is people ssh'ing across systems, from and old one (old terminal emulator) to a new one (new mc). I'd guess the other way around is more typical, I'd guess desktops are typically upgraded more frequently than servers, but sure this direction happens as well.

The display corruption is not terribly unbearable, the current path overwrites the panel's header (".n Name Size Modify time") or clutters the command line entry. It doesn't interfere with opening the Config dialog and change the settings there. The problem is: how would people know that they can "fix" this corrupiton in Config?

The main dilemma is: A minor breakage for some users vs. a minor new convenience feature for more users?

I tend to be a new guy who prefers pushing new features to users, rather than just making it available for them. Here too I'd like this feature to become the default for them, not just an option. If we ship this option disabled by default, and enable by default in a couple of years, users who have saved their config just once in between will still have it disabled, I think mc has no way to do a one-shot change to users' configs.

A nasty workaround that occurred to me: Emit OSC 7 with the fake URI that spells "If you can see this message then disable this and that feature" followed by another OSC 7 with the actual URI. Do we want such a hack?

Or we could disable it by default, and add a "hint" entry.

[ossi]

it's kinda a pity that there isn't a standardized escape sequence that would make any terminal dump the terminfo (equivalent) for itself, huh?

i'd just enable it. the resulting potential problem will be trivially googleable, first this ticket here, and then stackoverflow.

[andrew_b]

Replying to egmont:

it tends to keep a window of 5-7 years before requiring newer glib. (I'd be totally okay with decreasing this window size to maybe like 1-2 years.)

Not quite. We try to require as low version of GLib as possible.

[zaytsev]

The pattern you describe is not really practical, at least in the sense that after so much time vendors typically stop supporting the system and stop shipping even critical security fixes.

As a matter of fact, it is a very practical pattern, only maybe not for an average desktop user:

​https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Product_life_cycle

I would push it even further and claim that I actually have 3 more years to think about the meaning of life on RHEL6 without buying into ELS, and about the same for RHEL5 with an ELS contract. Now, I'm not even mentioning Solaris, AIX, HP-UX, VMS and the like...

Anyways, at this point, I'm basically arguing for the sake of the argument, and now that your curiosity has been satisfied, I would suggest to forget about poor me and go ahead with enabling it by default.

My bigger concern about the patch is that the name for the option sucks, but I couldn't come up with a better suggestion yet.