It's those applications setting the title, not the terminal changing it for them though.

(In reply to comment #1)
> It's those applications setting the title, not the terminal changing it for
> them though.

I think we should consider whether this is something that the terminal should be doing for apps.

(In reply to comment #0)
> I have "When terminal commands set their own titles" set to "Replace initial
> title".

For what it is worth, that option is gone since 3.9.90:

commit f27bf0135a2d18ba22158d28bf1f8c5f6ec066c8
Author: Christian Persch <chpe@gnome.org>
Date:   Fri Jun 21 15:33:53 2013 +0200

    screen: Simplify terminal title handling
    
    Remove all the options.

When terminal commands set their own titles, the initial title is always replaced.

(In reply to comment #3)
...
> For what it is worth, that option is gone since 3.9.90:
...

I'm using 3.10.2, and I still see that option.

That's because 3-10 was branched from 3-8, not master.

Created attachment 279220 [details] [review]
screen: Update the title with the current foreground process

Trying out an idea suggested by rtcm. Not very reliable, but kind of works. It can detect stuff launched in the background with &, ctrl+z followed by fg or bg. However, if you running your shell nested within another, then keeping the enter key pressed will cause the window title to flicker.

Created attachment 280426 [details] [review]
screen: Update the title with the current foreground process

This works much better with nested shells than before. We just skip the key stroke immediately after the title has been updated. If the title was changed by COMMAND_PROMPT or precmd_functions then we are currently showing the prompt and the next key is either an empty ENTER or something else, neither of which is interested for us. If the title was changed by an application then we don't need to bother anyway.

This works with ctrl+z, bg, fg.

'/bin/echo; emacs -nw' shows up as emacs, but 'sleep 5; emacs -nw' shows up as sleep. I am not too bothered with this because the Mac OS X terminal shows 'git log' and 'man ls' as less, which is a much common case than 'sleep 5; emacs -nw'.

We could fix that by exploring cgroups - we can put the shell in its own cgroup and listen for notifications where a new foreground process is spawned. I am not 100% sure how all that would work, but as I said, I think this is a reasonable start.

Created attachment 280651 [details] [review]
screen: Update the title with the current foreground process

chpe suggested that we guard this behaviour behind a setting. I have added a show-foreground-process-in-title profile setting for that.

this would be very nice to have for 3.14 - any chance to get a rewiew here ?

Review of attachment 280651 [details] [review]:

I have to say I don't like this approach too much…

So this shows either the application-set window-title, or the process-name as title, depending on the order of some events… that seems rather fragile.

::: src/org.gnome.Terminal.gschema.xml
@@ +166,3 @@
     </key>
+    <key name="show-foreground-process-in-title" type="b">
+      <default>true</default>

false

::: src/terminal-schemas.h
@@ +57,3 @@
 #define TERMINAL_PROFILE_SCROLL_ON_KEYSTROKE_KEY        "scroll-on-keystroke"
 #define TERMINAL_PROFILE_SCROLL_ON_OUTPUT_KEY           "scroll-on-output"
+#define TERMINAL_PROFILE_SHOW_FOREGROUND_PROCESS_IN_TITLE "show-foreground-process-in-title"

...._KEY

::: src/terminal-screen.c
@@ +1536,3 @@
+    }
+
+  if (event->keyval == GDK_KEY_Return || event->keyval == GDK_KEY_KP_Enter)

What about ISO_Enter and 3270_Enter ? And I see there's now *another* one, RockerEnter, no idea what that's about...

In gtk, we generally treat GDK_KEY_Return, GDK_KEY_KP_Enter and GDK_KEY_ISO_Enter the same, and ignore the others.

Ping ? Would this patch be acceptable if we make it handle other Enter variants

Maybe gtk+ should export a macro in the GDK_KEY_ namespace that checks the keyval for all the enter variants, so that every programme can be consistent in this…

Is this one of the patches that fedora ships? If so, has there been any feedback from users on whether they like the feature, or about problems with the implementation (wrong title shown at some point)?

(In reply to Christian Persch from comment #13)
> Is this one of the patches that fedora ships?

No.

> If so, has there been any
> feedback from users on whether they like the feature,

Terminal.app on OS X has been doing it for a while, and there are some other terminals both on OS X and Linux (eg., Konsole) that do this. Unfortunately, all the free software ones use polling, which is bad. :(

I wonder if Bash 4.4's PS0 [1] is the equivalent of Z shell's preexec that we have been asking for.

We can use vte.sh to setup PS0 to emit an escape sequence, and then the terminal emulator could use tcgetpgrp to read the foreground process name and set the window title. The escape sequence would stand for "about to execute command interactively".

[1] Egmont mentioned it here: https://bugzilla.gnome.org/show_bug.cgi?id=711059#c79

I have a prototype where PS0 emits a new VteTerminal::shell-preexec signal to prompt the terminal application to look at the current foreground process group and update the title. Will attach the patches after cleaning them up.

Created attachment 371856 [details] [review]
[vte] Support preexec notifications from an interactive shell

Created attachment 371857 [details] [review]
[vte] Test the shell-preexec signal

Created attachment 371858 [details] [review]
[vte] Support precmd notifications from an interactive shell

Created attachment 371859 [details] [review]
[vte] Test the shell-precmd signal

Created attachment 371867 [details] [review]
[gnome-terminal] screen: Update the title with the current foreground process

Created attachment 371903 [details] [review]
[gnome-terminal] screen: Update the title with the current foreground process

Restore the show-foreground-process-in-title GSetting that got lost, and changed the default to "false".

Created attachment 372123 [details] [review]
[gnome-terminal] screen: Monitor changes to the current foreground process

I was experimenting with monitoring the activity on the pseudo-terminal device (ie. VteTerminal::contents-changed) to detect when the foreground process might have changed.

This helps with commands like "emacs; vim".  Bash won't emit a notification when emacs terminates and vim starts, so monitoring terminal activity is a way to catch that.  This also works when a program is run from the (gdb) prompt, but I am not sure we want to update the title in that case.

I don't know if it's a good idea to repeatedly invoke tcgetpgrp whenever there's any pseudo-terminal activity.  It's currently batched using a 500 ms timeout, which seems ok-ish - my only measurement was to run "time ls -R" in my home directory which has loads of git trees, including some big ones like glibc.git, linux.git and libreOffice/core.git, and I didn't notice any noticeable slowdown.

Either way, I thought that it would be good to at least experiment with this, since this one of the things that KDE's Konsole does.  Relying only on this approach seems a bit limiting because it's hard to detect nested shells - the child shell will look like an ordinary foreground process like emacs.  It works for Konsole because it doesn't differentiate if the foreground process is the shell or an application - if there's no application running, it just shows the name of the shell.  However, if you want to draw that distinction, then it will look odd if that doesn't work reliably.

The patches are also in the following branches:
vte.git:wip/rishi/precmd-preexec
gnome-terminal.git:wip/rishi/auto-title-notify

Created attachment 372198 [details] [review]
[gnome-terminal] screen: Try harder to find a foreground process group member

Since there's no user-space API to list the members of a process group, other than crawling through /proc, this tries a bit harder to find a surviving member of the group so that we can show a window title for commands like:
  $ cat /proc/meminfo | less

-- 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/7379.