bug#28591: 27.0.50; xterm-set-window-title

bug#28591: 27.0.50; xterm-set-window-title

[Katsumi Yamaoka]

Hi,

The feature looks nice but I want the original title to come back
when Emacs exits or suspends (even if it launches with -Q).

Thanks.

In GNU Emacs 27.0.50 (build 1, i686-pc-cygwin, GTK+ Version 3.18.9)
 of 2017-09-25 built on localhost
Windowing system distributor 'The Cygwin/X Project', version 11.0.11900000

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> The feature looks nice but I want the original title to come back
> when Emacs exits or suspends (even if it launches with -Q).

I posted a patch here
https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00728.html

but at the moment it's not clear to me how to handle other terminals
that use an xterm- family terminfo.

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

Mark Oteiza <mvoteiza@udel.edu> writes:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>> The feature looks nice but I want the original title to come back
>> when Emacs exits or suspends (even if it launches with -Q).
>
> I posted a patch here
> https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00728.html
>
> but at the moment it's not clear to me how to handle other terminals
> that use an xterm- family terminfo.

The following lightly tested patch appears to do the right thing here.

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 6a17d382b0..d7214fc849 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -708,6 +708,16 @@ xterm--version-handler
           ;;(xterm--init-activate-get-selection)
           (xterm--init-activate-set-selection))))))
 
+(defvar xterm-window-title-stack nil)
+
+(defun xterm--title-handler ()
+  (let ((str "")
+        chr)
+    (while (and (setq chr (read-event nil nil 2))
+                (not (equal chr ?\\)))
+      (setq str (concat str (string chr))))
+    (push str xterm-window-title-stack)))
+
 (defvar xterm-query-timeout 2
   "Seconds to wait for an answer from the terminal.
 Can be nil to mean \"no timeout\".")
@@ -837,12 +847,28 @@ xterm--init-activate-set-selection
 
 (defun xterm--init-frame-title ()
   "Terminal initialization for XTerm frame titles."
+  (xterm-push-title-stack)
   (xterm-set-window-title)
+  (add-hook 'delete-frame-functions 'xterm-pop-title-stack)
   (add-hook 'after-make-frame-functions 'xterm-set-window-title-flag)
   (add-hook 'window-configuration-change-hook 'xterm-unset-window-title-flag)
-  (add-hook 'post-command-hook 'xterm-set-window-title)
+  (add-hook 'pre-redisplay-functions 'xterm-set-window-title)
   (add-hook 'minibuffer-exit-hook 'xterm-set-window-title))
 
+(defun xterm-push-title-stack ()
+  "Store terminal window title in XTerm's internal stack."
+  ;; (send-string-to-terminal "\e[22;0t")
+  (xterm--query "\e[21;0t"
+                '(("\e]l" . xterm--title-handler))))
+
+(defun xterm-pop-title-stack (&optional terminal)
+  "Pop terminal window title from XTerm's internal stack."
+  ;; (send-string-to-terminal "\e[23;0t" terminal)
+  (when xterm-window-title-stack
+    (send-string-to-terminal
+     (format "\e]2;%s\a" (pop xterm-window-title-stack))
+     terminal)))
+
 (defvar xterm-window-title-flag nil
   "Whether a new frame has been created, calling for a title update.")
 
@@ -861,7 +887,7 @@ xterm-set-window-title
 The title is constructed from `frame-title-format'."
   (send-string-to-terminal
    (format "\e]2;%s\a" (format-mode-line frame-title-format))
-   terminal))
+   (if (windowp terminal) (window-frame terminal) terminal)))
 
 (defun xterm--selection-char (type)
   (pcase type

bug#28591: 27.0.50; xterm-set-window-title

[Katsumi Yamaoka]

On Mon, 25 Sep 2017 13:24:24 -0400, Mark Oteiza wrote:
> Mark Oteiza <mvoteiza@udel.edu> writes:

>> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>>> The feature looks nice but I want the original title to come back
>>> when Emacs exits or suspends (even if it launches with -Q).

>> I posted a patch here
>> https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00728.html

>> but at the moment it's not clear to me how to handle other terminals
>> that use an xterm- family terminfo.

I use:

$ xterm -v
XTerm(327)

$ xterm&
Then the title bar of the launched xterm shows "xterm".

> The following lightly tested patch appears to do the right thing here.

Thanks.  I tried.  But nothing seems to be changed unfortunately.
When I run `emacs -nw' in the xterm, the title becomes to
"emacs@hostname" but the original title "xterm" is not pushed to
the `xterm-window-title-stack' variable.  And the title does not
come back to "xterm" when I exit or suspend Emacs -nw.

I tried adding `(error "XXX")' to the `xterm--title-handler'
function but nothing happens (with no error).  So, the function
doesn't seem to run by way of `xterm-push-title-stack'.

Regards,

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 26/09/17 at 12:45am, Katsumi Yamaoka wrote:
> On Mon, 25 Sep 2017 13:24:24 -0400, Mark Oteiza wrote:
> > Mark Oteiza <mvoteiza@udel.edu> writes:
> 
> >> Katsumi Yamaoka <yamaoka@jpl.org> writes:
> 
> >>> The feature looks nice but I want the original title to come back
> >>> when Emacs exits or suspends (even if it launches with -Q).
> 
> >> I posted a patch here
> >> https://lists.gnu.org/archive/html/emacs-devel/2017-09/msg00728.html
> 
> >> but at the moment it's not clear to me how to handle other terminals
> >> that use an xterm- family terminfo.
> 
> I use:
> 
> $ xterm -v
> XTerm(327)
> 
> $ xterm&
> Then the title bar of the launched xterm shows "xterm".
> 
> > The following lightly tested patch appears to do the right thing here.
> 
> Thanks.  I tried.  But nothing seems to be changed unfortunately.
> When I run `emacs -nw' in the xterm, the title becomes to
> "emacs@hostname" but the original title "xterm" is not pushed to
> the `xterm-window-title-stack' variable.  And the title does not
> come back to "xterm" when I exit or suspend Emacs -nw.
> 
> I tried adding `(error "XXX")' to the `xterm--title-handler'
> function but nothing happens (with no error).  So, the function
> doesn't seem to run by way of `xterm-push-title-stack'.

Grr, thanks.  I see what you're seeing in XTerm 330.  I am stumped--not
sure this is possible in Elisp, so I'm inclined to revert.

bug#28591: 27.0.50; xterm-set-window-title

[Eli Zaretskii]

> Date: Tue, 26 Sep 2017 00:08:08 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: 28591@debbugs.gnu.org
> 
> > > The following lightly tested patch appears to do the right thing here.
> > 
> > Thanks.  I tried.  But nothing seems to be changed unfortunately.
> > When I run `emacs -nw' in the xterm, the title becomes to
> > "emacs@hostname" but the original title "xterm" is not pushed to
> > the `xterm-window-title-stack' variable.  And the title does not
> > come back to "xterm" when I exit or suspend Emacs -nw.
> > 
> > I tried adding `(error "XXX")' to the `xterm--title-handler'
> > function but nothing happens (with no error).  So, the function
> > doesn't seem to run by way of `xterm-push-title-stack'.
> 
> Grr, thanks.  I see what you're seeing in XTerm 330.  I am stumped--not
> sure this is possible in Elisp, so I'm inclined to revert.

That'd be too drastic, I think.  The code did work for you, right?  So
it definitely works for some configurations out there, and I think we
could leave it in Emacs, turned off by default, and allow its optional
activation with the proper warning that it might not work for some
versions of xterm.

WDYT?

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 29/09/17 at 01:45pm, Eli Zaretskii wrote:
> > Date: Tue, 26 Sep 2017 00:08:08 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: 28591@debbugs.gnu.org
> > 
> > > > The following lightly tested patch appears to do the right thing here.
> > > 
> > > Thanks.  I tried.  But nothing seems to be changed unfortunately.
> > > When I run `emacs -nw' in the xterm, the title becomes to
> > > "emacs@hostname" but the original title "xterm" is not pushed to
> > > the `xterm-window-title-stack' variable.  And the title does not
> > > come back to "xterm" when I exit or suspend Emacs -nw.
> > > 
> > > I tried adding `(error "XXX")' to the `xterm--title-handler'
> > > function but nothing happens (with no error).  So, the function
> > > doesn't seem to run by way of `xterm-push-title-stack'.
> > 
> > Grr, thanks.  I see what you're seeing in XTerm 330.  I am stumped--not
> > sure this is possible in Elisp, so I'm inclined to revert.
> 
> That'd be too drastic, I think.  The code did work for you, right?  So
> it definitely works for some configurations out there, and I think we
> could leave it in Emacs, turned off by default, and allow its optional
> activation with the proper warning that it might not work for some
> versions of xterm.

Everything except foregrounding a client works (I did not test this),
where the following occurs:

  Error in post-command-hook (xterm-set-window-title): (error "Terminal
  is currently suspended")

post-command-hook is used to catch changing windows within a frame--I
do not know if there is another hook (or event perhaps) that would
better serve this purpose.

bug#28591: 27.0.50; xterm-set-window-title

[martin rudalics]

 > post-command-hook is used to catch changing windows within a frame--I
 > do not know if there is another hook (or event perhaps) that would
 > better serve this purpose.

‘window-configuration-change-hook’ is the canonical hook to "to catch
changing windows within a frame".  But maybe I'm missing something.

martin

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 29/09/17 at 02:51pm, martin rudalics wrote:
> > post-command-hook is used to catch changing windows within a frame--I
> > do not know if there is another hook (or event perhaps) that would
> > better serve this purpose.
> 
> ‘window-configuration-change-hook’ is the canonical hook to "to catch
> changing windows within a frame".  But maybe I'm missing something.

Sorry, I meant changing window focus; for instance with `other-window'.

bug#28591: 27.0.50; xterm-set-window-title

[martin rudalics]

 > Sorry, I meant changing window focus; for instance with `other-window'.

Then try ‘buffer-list-update-hook’.

martin

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 29/09/17 at 07:57am, Mark Oteiza wrote:
> On 29/09/17 at 01:45pm, Eli Zaretskii wrote:
> > > Date: Tue, 26 Sep 2017 00:08:08 -0400
> > > From: Mark Oteiza <mvoteiza@udel.edu>
> > > Cc: 28591@debbugs.gnu.org
> > > 
> > > > > The following lightly tested patch appears to do the right thing here.
> > > > 
> > > > Thanks.  I tried.  But nothing seems to be changed unfortunately.
> > > > When I run `emacs -nw' in the xterm, the title becomes to
> > > > "emacs@hostname" but the original title "xterm" is not pushed to
> > > > the `xterm-window-title-stack' variable.  And the title does not
> > > > come back to "xterm" when I exit or suspend Emacs -nw.
> > > > 
> > > > I tried adding `(error "XXX")' to the `xterm--title-handler'
> > > > function but nothing happens (with no error).  So, the function
> > > > doesn't seem to run by way of `xterm-push-title-stack'.
> > > 
> > > Grr, thanks.  I see what you're seeing in XTerm 330.  I am stumped--not
> > > sure this is possible in Elisp, so I'm inclined to revert.
> > 
> > That'd be too drastic, I think.  The code did work for you, right?  So
> > it definitely works for some configurations out there, and I think we
> > could leave it in Emacs, turned off by default, and allow its optional
> > activation with the proper warning that it might not work for some
> > versions of xterm.
> 
> Everything except foregrounding a client works (I did not test this),
> where the following occurs:

Correction: deleting a frame does not restore the window title as
Katsumi pointed out.

I have a shell hook that sets the window title which I keep
forgetting to disable when testing this

bug#28591: 27.0.50; xterm-set-window-title

[Eli Zaretskii]

> Date: Fri, 29 Sep 2017 09:05:42 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> 
> Correction: deleting a frame does not restore the window title as
> Katsumi pointed out.

So you are saying the title is only restored when Emacs exits?
Otherwise, I think I'm missing something: in what case(s) your
restoration code does work?

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 29/09/17 at 08:34pm, Eli Zaretskii wrote:
> > Date: Fri, 29 Sep 2017 09:05:42 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> > 
> > Correction: deleting a frame does not restore the window title as
> > Katsumi pointed out.
> 
> So you are saying the title is only restored when Emacs exits?
> Otherwise, I think I'm missing something: in what case(s) your
> restoration code does work?

There is no restoration code at the moment--I totally overlooked it
because of my shell configuration.

The following works for me on a VTE based terminal.
The commented bits I would expect to do _something_ on XTerm, but
I have been unable to get titles to restore on XTerm, whether or not
I set the allowWindowOps and disallowedWindowOps resources.

diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el
index 6a17d382b0..337c75e0ea 100644
--- a/lisp/term/xterm.el
+++ b/lisp/term/xterm.el
@@ -708,6 +708,16 @@ xterm--version-handler
           ;;(xterm--init-activate-get-selection)
           (xterm--init-activate-set-selection))))))
 
+(defun xterm--title-handler ()
+  (let ((str "")
+        chr)
+    (while (and (setq chr (read-event nil nil 2))
+                (not (eq chr ?\\)))
+      (setq str (concat str (string chr))))
+    (push (replace-regexp-in-string "\e$" "" str)
+          (terminal-parameter (frame-terminal (selected-frame))
+                              'xterm-saved-title))))
+
 (defvar xterm-query-timeout 2
   "Seconds to wait for an answer from the terminal.
 Can be nil to mean \"no timeout\".")
@@ -837,12 +847,25 @@ xterm--init-activate-set-selection
 
 (defun xterm--init-frame-title ()
   "Terminal initialization for XTerm frame titles."
+  ;; (xterm-push-title-stack)
+  (xterm-push-window-title (frame-terminal (selected-frame)))
   (xterm-set-window-title)
+  (add-hook 'suspend-tty-functions 'xterm-pop-window-title)
+  (add-hook 'resume-tty-functions 'xterm-push-window-title)
+  ;; (add-hook 'delete-frame-functions 'xterm-pop-title-stack)
   (add-hook 'after-make-frame-functions 'xterm-set-window-title-flag)
   (add-hook 'window-configuration-change-hook 'xterm-unset-window-title-flag)
-  (add-hook 'post-command-hook 'xterm-set-window-title)
+  (add-hook 'delete-terminal-functions 'xterm-pop-window-title)
+  ;; (add-hook 'delete-terminal-functions 'xterm-pop-title-stack)
+  (add-hook 'buffer-list-update-hook 'xterm-set-window-title)
   (add-hook 'minibuffer-exit-hook 'xterm-set-window-title))
 
+;; (defun xterm-push-title-stack ()
+;;   (send-string-to-terminal "\e[22;0t"))
+
+;; (defun xterm-pop-title-stack (&optional terminal)
+;;   (send-string-to-terminal "\e[23;0t" terminal))
+
 (defvar xterm-window-title-flag nil
   "Whether a new frame has been created, calling for a title update.")
 
@@ -863,6 +886,15 @@ xterm-set-window-title
    (format "\e]2;%s\a" (format-mode-line frame-title-format))
    terminal))
 
+(defun xterm-pop-window-title (terminal)
+  (send-string-to-terminal
+   (format "\e]2;%s\a" (pop (terminal-parameter terminal 'xterm-saved-title)))
+   terminal))
+
+(defun xterm-push-window-title (terminal)
+  (xterm--query "\e[21;0t" '(("\e]l" . xterm--title-handler)))
+  (xterm-set-window-title terminal))
+
 (defun xterm--selection-char (type)
   (pcase type
     ('PRIMARY "p")

bug#28591: 27.0.50; xterm-set-window-title

[Eli Zaretskii]

> Date: Sat, 30 Sep 2017 15:26:27 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> 
> > So you are saying the title is only restored when Emacs exits?
> > Otherwise, I think I'm missing something: in what case(s) your
> > restoration code does work?
> 
> There is no restoration code at the moment--I totally overlooked it
> because of my shell configuration.
> 
> The following works for me on a VTE based terminal.
> The commented bits I would expect to do _something_ on XTerm, but
> I have been unable to get titles to restore on XTerm, whether or not
> I set the allowWindowOps and disallowedWindowOps resources.

OK, how about pushing this to master, with some defcustom, by default
off, to control whether this feature is used?  With any luck, we might
have contributions for others to increase the number of configurations
supported by this feature.

Thanks.

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 05/10/17 at 01:16pm, Eli Zaretskii wrote:
> > Date: Sat, 30 Sep 2017 15:26:27 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> > 
> > > So you are saying the title is only restored when Emacs exits?
> > > Otherwise, I think I'm missing something: in what case(s) your
> > > restoration code does work?
> > 
> > There is no restoration code at the moment--I totally overlooked it
> > because of my shell configuration.
> > 
> > The following works for me on a VTE based terminal.
> > The commented bits I would expect to do _something_ on XTerm, but
> > I have been unable to get titles to restore on XTerm, whether or not
> > I set the allowWindowOps and disallowedWindowOps resources.
> 
> OK, how about pushing this to master, with some defcustom, by default
> off, to control whether this feature is used?  With any luck, we might
> have contributions for others to increase the number of configurations
> supported by this feature.

After running with the patch for a bit, I notice sometimes there is
a long (second or two) delay when opening a new frame--I guess because
of a possible delay like is mentioned in delete-frame-functions.
I would prefer to simply turn the existing code off by default than
introduce possibly more broken behavior, especially when it only
supports a subset of xterm-like terminals.

bug#28591: 27.0.50; xterm-set-window-title

[Eli Zaretskii]

> Date: Sun, 8 Oct 2017 16:21:40 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> 
> I would prefer to simply turn the existing code off by default than
> introduce possibly more broken behavior, especially when it only
> supports a subset of xterm-like terminals.

Fine with me, thanks.

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 09/10/17 at 09:23am, Eli Zaretskii wrote:
> > Date: Sun, 8 Oct 2017 16:21:40 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> > 
> > I would prefer to simply turn the existing code off by default than
> > introduce possibly more broken behavior, especially when it only
> > supports a subset of xterm-like terminals.
> 
> Fine with me, thanks.

Change pushed.

bug#28591: 27.0.50; xterm-set-window-title

[Lars Ingebrigtsen]

Mark Oteiza <mvoteiza@udel.edu> writes:

>> > I would prefer to simply turn the existing code off by default than
>> > introduce possibly more broken behavior, especially when it only
>> > supports a subset of xterm-like terminals.
>> 
>> Fine with me, thanks.
>
> Change pushed.

Skimming this thread, it seems like the reported problem was fixed, and
I'm closing this bug report.  If this is wrong, please respond to the
debbugs address and we'll reopen the report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#28591: 27.0.50; xterm-set-window-title

[Eli Zaretskii]

> Date: Fri, 29 Sep 2017 07:57:00 -0400
> From: Mark Oteiza <mvoteiza@udel.edu>
> Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> 
> Everything except foregrounding a client works (I did not test this),
> where the following occurs:
> 
>   Error in post-command-hook (xterm-set-window-title): (error "Terminal
>   is currently suspended")

This error comes from here:

  DEFUN ("send-string-to-terminal", Fsend_string_to_terminal,
	 Ssend_string_to_terminal, 1, 2, 0,
	 doc: /* Send STRING to the terminal without alteration.
  Control characters in STRING will have terminal-dependent effects.

  Optional parameter TERMINAL specifies the tty terminal device to use.
  It may be a terminal object, a frame, or nil for the terminal used by
  the currently selected frame.  In batch mode, STRING is sent to stdout
  when TERMINAL is nil.  */)
    (Lisp_Object string, Lisp_Object terminal)
  {

    ...
	if (! tty->output)
	  error ("Terminal is currently suspended");

So one way of fixing it would be to have a suspend-hook set some flag
which your post-command-hook would check, and avoid calling
send-string-to-terminal when the terminal is suspended.

Another possibility would be to add a utility function, called
'tty-suspended-p', which you could then test in your
post-command-hook.  Its implementation should test the tty->output
value.

Would any of this make sense?

bug#28591: 27.0.50; xterm-set-window-title

[Mark Oteiza]

On 29/09/17 at 08:29pm, Eli Zaretskii wrote:
> > Date: Fri, 29 Sep 2017 07:57:00 -0400
> > From: Mark Oteiza <mvoteiza@udel.edu>
> > Cc: yamaoka@jpl.org, 28591@debbugs.gnu.org
> > 
> > Everything except foregrounding a client works (I did not test this),
> > where the following occurs:
> > 
> >   Error in post-command-hook (xterm-set-window-title): (error "Terminal
> >   is currently suspended")
> 
> This error comes from here:
> 
>   DEFUN ("send-string-to-terminal", Fsend_string_to_terminal,
> 	 Ssend_string_to_terminal, 1, 2, 0,
> 	 doc: /* Send STRING to the terminal without alteration.
>   Control characters in STRING will have terminal-dependent effects.
> 
>   Optional parameter TERMINAL specifies the tty terminal device to use.
>   It may be a terminal object, a frame, or nil for the terminal used by
>   the currently selected frame.  In batch mode, STRING is sent to stdout
>   when TERMINAL is nil.  */)
>     (Lisp_Object string, Lisp_Object terminal)
>   {
> 
>     ...
> 	if (! tty->output)
> 	  error ("Terminal is currently suspended");
> 
> So one way of fixing it would be to have a suspend-hook set some flag
> which your post-command-hook would check, and avoid calling
> send-string-to-terminal when the terminal is suspended.
> 
> Another possibility would be to add a utility function, called
> 'tty-suspended-p', which you could then test in your
> post-command-hook.  Its implementation should test the tty->output
> value.
> 
> Would any of this make sense?

It would, but I ended up taking Martin's suggestion and replacing the
use of post-command-hook with instead using buffer-list-update-hook,
which doesn't have this problem.