This can easily be done in vte.sh. Although then your last paragraph, making it revertable via settings becomes tricky because the title is set by the shell, not by vte or gnome-terminal.

One possible approach to overcome this, mentioned in bug 709358 (initial report, last paragraph) is to have an option in g-t to display the current directory rather than the requested title in the title. (Background: OSC0 sets the title with no semantical meaning, it can be anything, it just defaults to user@host:dir if someone uses vte.sh and doesn't override, but it can be any arbitrary text not related to the current directory or anything else. There's no way g-t could parse that and figure out what the current directory is. OSC7 sets the working directory with exact semantics and exact syntax, g-t can easily parse it and know the working directory and display whichever parts it wants.) If we'd really prefer to display the working directory in the title, we might have a g-t option to ignore the requested title (OSC0) and override with the current directory (as known from OSC7) instead.

Yet another idea that occurred to me: What if we simply keep the current long title, but ellipsize at the beginning (or middle)? This can easily be a config option.

Created attachment 266907 [details]
title settings mockup

(In reply to comment #1)
... 
> Yet another idea that occurred to me: What if we simply keep the current long
> title, but ellipsize at the beginning (or middle)? This can easily be a config
> option.

That's still relatively hard to parse, since you'd be unsure where in the string each piece of information would begin.

One way it could work - have the terminal take over setting the title from vte.sh, but have a way to stop doing that (for legacy purposes). When the terminal is in control we could do things like:

 * Local terminals:
 - Show the working directory by default.
 - If the user name changes, prepend it.
 - If there is more than one terminal with the same working directory, show part of the path that differs.

 * Remote terminals
 - Use the host name as the title.
 - If there are remote terminals with different user names, prepend the user name.

 * Update the title with the running command (this is bug 711060).

I've attached a mockup for what the settings could look like for this.

(In reply to comment #2)

>  - If there is more than one terminal with the same working directory, show
> part of the path that differs.

I really dislike this one. Suppose you have a single tab in /usr/lib, the title is displayed as "lib". Then another one is opened at /lib, its title becomes "lib" and the other one becomes "usr/lib". Close the new one, the old one's title reverts back to "lib". You can never know what "lib" means, and its meaning varies based on what other tabs you have open and where you navigate in them. To me it's overengineered and not any more useful than something simpler. Simply ellipsizing the start of the complete path (assuming no other info, such as username is displayed) sounds a much cleaner solution to me. I'd expect the tab name not to depend on any other tabs I have open, just like in other apps.

(In reply to comment #3)
> (In reply to comment #2)
> 
> >  - If there is more than one terminal with the same working directory, show
> > part of the path that differs.
> 
> I really dislike this one. Suppose you have a single tab in /usr/lib, the title
> is displayed as "lib". Then another one is opened at /lib, its title becomes
> "lib" and the other one becomes "usr/lib".

In this case, neither tab title would change, since the paths are identical.

A better example might be a terminal in src. You move a different terminal to  a directory named src, and it might get a title like gnome-documents/src.

> Close the new one, the old one's
> title reverts back to "lib". You can never know what "lib" means, and its
> meaning varies based on what other tabs you have open and where you navigate in
> them. 

Yeah that's a good point - it wouldn't be good for terminals titles to change. Maybe one way to do it would be for new terminals to get title that differentiates them from existing ones, but for the titles not to change once set.

> To me it's overengineered and not any more useful than something simpler.
> Simply ellipsizing the start of the complete path (assuming no other info, such
> as username is displayed) sounds a much cleaner solution to me. I'd expect the
> tab name not to depend on any other tabs I have open, just like in other apps.

I think that would be worse than simply having the current working directory and not doing anything more complex to differentiate terminals in the same location. You could still end up with tabs with identical titles, but you would also have a lot of extra noise and you'd end up having to try and parse lines of text from the end rather than the start, which is difficult.

I'd be very happy to start with a simplified version of the proposal in #c2, by the way. Simply using the current working directory for local terminals and the host name for remote ones would be a massive improvement in my opinion.

(In reply to comment #4)

> > I really dislike this one. Suppose you have a single tab in /usr/lib, the title
> > is displayed as "lib". Then another one is opened at /lib, its title becomes
> > "lib" and the other one becomes "usr/lib".
> 
> In this case, neither tab title would change, since the paths are identical.

Nope, read again carefully please. /usr/lib and /lib are different paths.

> Yeah that's a good point - it wouldn't be good for terminals titles to change.
> Maybe one way to do it would be for new terminals to get title that
> differentiates them from existing ones, but for the titles not to change once
> set.

This would again lead to a solution where the title depends on what happens in other tabs. Imagine two directories, a/src and b/src. In the first tab you change to a/src. The title becomes src, since this is the only tab inside any src directory at the moment, and g-t has no clue what you're about to do next. Then in the other tab you change to b/src, and the title becomes b/src so that it's differentiated from the first. The two titles are src and b/src. Had you changed directories with different timings, the titles would be a/src and src. I would find this counterintuitive and more confusing than useful.

If you really wish to differentiate terminals in the title, what do you think of konsole's "session number"? It's just a unique integer for each tab. (You can then append the directory or whatever you want.) (By the way, this is pretty close to what I've been using for years now. For me, the title is just a unique integer, nothing more.)

The problem with the current directory is that it's hardly related to what you're using that tab for. In some tabs you can do things totally irrelevant to each other, still stand in the same directory. In some other tabs you might perform related tasks (e.g. edit a source code in one, compile in another), yet maybe stand in different directories, maybe not. Perhaps the working directory is a little bit overrated, I mean you can either "vim vte/src/vte.c" or "cd vte; vim src/vte.c" or "cd vte/src; vim vte.c", they're essentially the same, so why should the title be different, I'm not sure.

Anyway, as long as you try to show the current directory as an aid (without the intent of being unique), I'm totally fine with that. Trying to force that to be unique, or displaying based on what's happening in other tabs don't sound good ideas to me. If you want uniqueness, please give konsole's sequence number a try.

> I think that would be worse than simply having the current working directory
> and not doing anything more complex to differentiate terminals in the same
> location. You could still end up with tabs with identical titles, but you would
> also have a lot of extra noise and you'd end up having to try and parse lines
> of text from the end rather than the start, which is difficult.

I don't understand your concerns with ellipsizing at the beginning. Please try in konsole to only show the long directory name, it'll do this for you. (A working version is always better than a static screenshot mock, we're lucky to have one now.) The "/" is a prominent visual separator, and after I know I've switched to a couple of directories including e.g. "/usr/local/share/mc/skins" I don't think I'm parsing the "...are/mc/skins" string left-to-right wondering what "...are" stands for. I just look at it as a whole, and I immediately recognize the "mc" and "skins" words and I know where I am.

> I'd be very happy to start with a simplified version of the proposal in #c2, by
> the way. Simply using the current working directory for local terminals and the
> host name for remote ones would be a massive improvement in my opinion.

Yup. In fact, showing the remote directory (if the remote machine is cooperative, e.g. a Fedora with certain system-wide changes accepted) is also relatively easily doable now, based on OSC 7.

Here's a long overview of the situation and a design doc of my proposed solution.

Displaying a proper and informative title for terminals is an issue that's been unsolved so far. Everyone has their favorite piece of information they'd like to see there: a fixed string, the username, the hostname, the current working directory (cwd), the opened file, the running command, a unique identifier, the title as requested by the application running inside, or a combination thereof. Each terminal offers a different set of these features, and making these work consistently across applications [such as midnight commander (mc) that can show the cwd in one particular hardcoded format, unlikely to be consistent with the title when mc is not running], across user switches [su, sudo], across remote logins [ssh] (or again a combination thereof, e.g. ssh followed by sudo followed by mc) requires deep technical knowledge and hacking, and requires duplicating the personally preferred format at many places. Terminal emulators, vendors (via config files) all ship a partial and incompatible solution, if any.

The current situation is a total mess, and trying to address the current particular needs of gnome-terminal taking the path of least resistance is likely to just increase the complexity and mess. In the current mess, the UX engineer is limited by hard to understand technical restrictions, and a small change in the proposed UI might lead to a totally different technical approach to achieve that behavior using a horrible hack.

Hereby I propose a solution, which, if accepted by some leading terminal emulators and OS/distro vendors and so hits a critical mass that pushes others to follow, would solve all the problems. Terminal emulators are free to implement the whole, or a desired subset only, or they can even add some extensions. The proposed solution is easy to implement, results in clean code. If a distribution (e.g. Fedora) accepts this and implements this in a way that it works with ssh, su, mc etc. out of the box then I hope it would make others follow this solution. Note that for a complete out of the box solution, a distribution would need to adjust its system-wide config files (bash profile and such), and it might be recommended to patch a few applications (e.g. mc) and a few nondefault terminals (e.g. xterm) for wider adoption of the solution. Deep technical skills are not required, but a good generic overview of the situation is desired, since the solution necessarily touches several components.

Terminals, by design, receive text and other control information (color change, cursor movement, title change etc.) via a certain channel and then act accordingly (display the text, change the title etc.), and send back keystrokes and other similar events in the same channel. They don't know which application sent the text, or which application will receive the keystrokes. They don't know anyting about the meaning of the text they show. They don't know what a "shell" or "prompt" means. Traditionally they don't have the concept of username, hostname, cwd, command being executed and so on.

There are three approaches to overcome (some of) these limitation, and let the terminal know about the cwd and other properties of what's happening inside.

(1) is to parse what's on the screen and try to figure out the meaning from those letters. Some experimental terminal emulators (e.g. FinalTerm) do this. Recognizing the cwd, username, hostname from the contents of the screen sounds extremely hard to implement and fragile with all kinds of hard-to-track errors and limited functionality (e.g. stops working if the user switches to her favorite prompt format) and would necessarily behave differently across terminals. I recommend not to even think about this approach.

(2) is to dig under /proc (or equivalent). This is what Gnome-Terminal up to 3.6 used to do to figure out the cwd so that the new tab is started in the same cwd. This is what Konsole does to find out the cwd, the name of the running process, the hostname in case of ssh. Konsole has an unfriendly noticeable delay in updating the tab title because this approach requires periodically re-examining /proc. The solution is heavily OS dependent, different code is required for each Unix variant, has a large implementation and maintenance cost. The cwd is no longer accessible after a su or sudo, due to denied access under /proc. The whole approach stops working when you log in to a remote machine, you just don't know what's happening over there and can't dig into the remote /proc. Konsole goes down in the process hierarchy as deep as possible to get the cwd, having both pros (updates the cwd when using mc) and cons (updates when a shell script internally changes directory). Due to its complexity, its limitations by design and its latency, I don't recommend this approach (and we heard ChPe doesn't want to go this way either).

(3) Recently MacOS introduced the OSC 7 (telling the hostname and cwd to the terminal) and OSC 6 (telling the hostname and current file) commands, iTerm2 and Gnome-Terminal 3.8 also implemented these, G-T switched to using this instead of approach (2) when opening a new tab in the same directory as the old one. Assuming that the prompt emits this control sequence for all users on all host, this would solve the sudo and ssh problems: even on a remote machine, even after changing username the terminal knows this information. It's not the terminal that goes ahead and tries to figure it out; it's the applications (shell etc.) that explicitly tell it to the terminal. This can result in instantaneous update of the title. Even konsole's cwd updating anomaly can easily be solved: applications that find it important to notify the terminal about a cwd change can do so using OSC 7 (patch for mc: https://www.midnight-commander.org/ticket/3088), whereas shell scripts that internally change directory obviously won't tell it to the terminal. I really love this approach: it can work across all combinations of sudo, ssh, mc and whatnot, the update happens immediately, and it has other advantages that I'll talk about. I would really like to move in this direction.

The main advantage I see in approach (3) is that it starts to talk about semantics. Fields that have a well defined meaning. "Dear terminal, please set this as the title" - all the terminal can do is obey (or not), nothing more. "Dear terminal, this is the current hostname, this is the cwd, do with it whatever you think is appropriate" gives much more freedom for doing awesome things.

One of the things that we'd need to do is to add support for more of these: at least for username and running command. [These could be OSC 8 and OSC 9 (although OSC 10-19 are already used for something else, so if we start in this direction then the next one would be OSC 20 or so), or we can do a more generic approach of "OSC 8 ; keyword ; value" where initially only "username" and "command" would be valid keywords but it's easily extendible. (Or just numbers for keywords, e.g. OSC 8;0;value for username, 8;1;value for command etc., just as it is right now with OSC 5). Anyway, the very technical details are to be figured out, not important at this point.] This way, even after ssh'ing and su'ing, the terminal could be kept notified "this is the current username", "this is the currently running process" etc.

Telling the running process to the terminal would need to use bash's debug trap (it works so it's okay, although a bit of misuse of the intent), or bash could be patched in the reference distro of this solution. I hope that a complete out-of-the-box solution for properly maintaining the title, rather than just one-off requests, could convince bash's author to accept the feature mainstream.

The shell startup scripts should be modified so that after a remote login or a su/sudo (or combinations thereof) the prompt contains all these OSC escapes, supposed that the terminal is likely to either support or silently ignore them. We should locate all terminals that emit garbage on seeing such an unknown escape and fix them. Having tried many emulators on Linux, I found the Linux console (can be filtered out by $TERM, but we could just as well fix the kernel) and VTE (heck, let's fix it immediately) as such.

The backend/infrastructure work is basically this. Finalize the new OSC codes. Make bash (and other popular shell) prompt always print these OSCs, even after a remote login a su/sudo. Add support to some interactive terminal apps where you can change the directory (mc, other file managers?, maybe ftp clients' lcd command, anything else?).

Adding support for the new OSC codes in vte/gnome-terminal, or any other terminal emulator, should be a piece of cake. In vte/g-t it requires a copy-paste of the OSC 6/7 API. At this moment, the terminal knows all the information it ever wanted to know.

The rest is UI work, and here is where terminals will likely do differently. Konsole is likely to keep its current approach of letting the user configure anything, just the backing technical solution would be different, allowing immediate update, knowing the username and directory all the times, even on remote hostnames. G-T is likely to provide fewer alternatives to the user, but the hands of the UX engineer would not be tied.

A couple of ideas I have in mind that become possible by following approach (3):

There's only a small room in the tab title. There's more room, but still just one line in the window title. There's plenty of room in the hover tooltip. Currently they all display the same. We could perhaps display more information in the window title (e.g. complete username, host, directory), and less information in the tab title (e.g. directory only for local, host only for remote). The hover tooltip could display all the information in multiple lines in structured format (first line: "username: joe", second line: "host: mycomp" etc.).

The ellipsis, if required, could also use any clever algorithm. E.g. if someone prefers to see a unique identifier and the current directory, it might make sense to display the ID, a space, followed by ellipsis if necessary, followed by the (trailing part of the) current directory.

These are random just ideas to show how flexible it would be. The main point is that the background infrastructure would be common across all terminals, all shells, and eventually (hopefully) all Unixes, and the display format could be whatever the terminal developers or users decide, without technical limitations. This design, once implemented, would no longer had to be changed, users would get a flexible and working system without requiring technical knowledge, and distros wouldn't have to do heavy backend refactoring whenever any new UI trends asked for a change in the look.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/7405.