suggested feature -- console-mode frame title sets Xterm title

suggested feature -- console-mode frame title sets Xterm title

[Eric Hanchrow]

In GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-22 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes --with-x-toolkit=athena --without-gif'

I've been using Emacs in console mode recently, via an SSH connection
from a Windows box (using the very nice Windows SSH client "putty" --
http://www.chiark.greenend.org.uk/~sgtatham/putty).  That program,
naturally, creates a console window for me to type in, and it changes
the window's title when the program running under it sends escape
sequences.  To exploit that feature of Putty, when I'm just using the
shell (as opposed to using Emacs) I've set this variable in Bash:

        PROMPT_COMMAND='echo -ne "\033]0;${USER:-${LOGNAME}}@${HOSTNAME}: ${PWD}\007"'

This causes Bash to emit a bunch of characters every time it prints a
prompt; Putty responds by changing the window title (to include my
user name, host name, and working directory, obviously).

This escape sequence doesn't work just with Putty; it apparently
conforms to some standard or other, because other programs (such as
xterm) similarly change their window-bar title in response.

I'm proposing that Emacs, when running under a console (as opposed to
running under X), behave similarly to Bash -- that is, that it (when
the user so requests) send those sorts of characters, thus updating
Putty, or the xterm it's running under, or whatever, in the same
situations in which it would modify its frame title if it were running
under X.

I don't know if this is possible, although I suspect it is; I haven't
tried to hack something up myself.  I'd be interested to hear comments
from Emacs developers -- is this worth doing, has it already been
done, etc.  If it seems worth doing, I'll give it a whirl and if I'm
happy with what I've done, I'll submit it as a patch.

-- 
PGP Fingerprint: 3E7B A3F3 96CA 8958 ACC5  C8BD 6337 0041 C01C 5276

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    the user so requests) send those sorts of characters, thus updating
    Putty, or the xterm it's running under, or whatever, in the same
    situations in which it would modify its frame title if it were running
    under X.

It seems worth a try.  I suggest doing it when the mode line is updated.

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On Sat, 15 Jun 2002 15:47:30 -0600, Richard Stallman wrote:

>     the user so requests) send those sorts of characters, thus updating
>     Putty, or the xterm it's running under, or whatever, in the same
>     situations in which it would modify its frame title if it were running
>     under X.
> 
> It seems worth a try.  I suggest doing it when the mode line is updated.

I thought I would try this.

Updating the title can be done pretty easily from lisp by sending the
right characters directly to the terminal.  Noah S. Friedman has an
example of how to do it here:

  http://www.splode.com/~friedman/software/emacs-lisp/src/xterm-frobs.el

Noah's code, like most of the xterm-handling code in emacs, uses
hardcoded escape sequences.  I think they ought to be taken from the
fs/ds/es fields in the termcap database, but for some reason the
normal 'xterm' terminal definition doesn't seem to have them.  If we
relied on using termcap to get the right control codes then users
would have to patch their termcap to get it to work.

It looks like the title update is done purely in C and not visible to
Lisp; there doesn't seem to be a hook that's run at any relevant time.
Also it looks like the code that expands the format string is not
accessible to Lisp.  I suppose this makes sense since the
window-system title must be set by C code.

I can see where the title is built up into a buffer in
x_consider_frame_title.  At the moment that code is only compiled when
we're built for a window system.  That assumption needs to come out.

In addition, the function only acts on frames that have
windowing-system windows.  This too needs to change so we consider
frames which either have windows or which are FRAME_TERMCAP_P().  

I'm not sure how this will interact with creation of multiple frames
on a terminal, if anyone uses that.

Anyhow, here is a patch against 21.3.  It seems to work for me in
quick tests in three domains:

 - in a terminal, built --without-x

 - in a terminal, built --with-x

 - on x

Comments would be very welcome.  I would like it if something like
this could eventually be merged.

Regards,
-- 
Martin



--- /home/mbp/work/emacs/emacs-21.3/src/xdisp.c.~1~	2003-01-18 00:45:13.000000000 +1100
+++ /home/mbp/work/emacs/emacs-21.3/src/xdisp.c	2003-09-26 15:02:16.000000000 +1000
@@ -7142,7 +7142,6 @@ echo_area_display (update_frame_p)
  ***********************************************************************/
 
 
-#ifdef HAVE_WINDOW_SYSTEM
 
 /* A buffer for constructing frame titles in it; allocated from the
    heap in init_xdisp and resized as needed in store_frame_title_char.  */
@@ -7211,6 +7210,8 @@ store_frame_title (str, field_width, pre
 }
 
 
+const char *xterm_title_start = "\033]2;", *xterm_title_end = "\007";
+
 /* Set the title of FRAME, if it has changed.  The title format is
    Vicon_title_format if FRAME is iconified, otherwise it is
    frame_title_format.  */
@@ -7222,6 +7223,7 @@ x_consider_frame_title (frame)
   struct frame *f = XFRAME (frame);
 
   if (FRAME_WINDOW_P (f)
+      || FRAME_TERMCAP_P (f)
       || FRAME_MINIBUF_ONLY_P (f)
       || f->explicit_name)
     {
@@ -7260,24 +7262,32 @@ x_consider_frame_title (frame)
       frame_title_ptr = NULL;
       set_buffer_internal (obuf);
 
+#ifdef HAVE_WINDOW_SYSTEM
       /* Set the title only if it's changed.  This avoids consing in
 	 the common case where it hasn't.  (If it turns out that we've
 	 already wasted too much time by walking through the list with
 	 display_mode_element, then we might need to optimize at a
 	 higher level than this.)  */
-      if (! STRINGP (f->name) 
-	  || STRING_BYTES (XSTRING (f->name)) != len
-	  || bcmp (frame_title_buf, XSTRING (f->name)->data, len) != 0)
-	x_implicitly_set_name (f, make_string (frame_title_buf, len), Qnil);
+
+      /* Even if we're compiled with a window system, we might not be
+         using it for this frame... */
+      if (FRAME_WINDOW_P (f)) 
+        if (! STRINGP (f->name) 
+            || STRING_BYTES (XSTRING (f->name)) != len
+            || bcmp (frame_title_buf, XSTRING (f->name)->data, len) != 0)
+          x_implicitly_set_name (f, make_string (frame_title_buf, len), Qnil);
+#endif
+      
+      if (FRAME_TERMCAP_P (f))
+        {
+          fwrite (xterm_title_start, 1, strlen (xterm_title_start), stdout);
+          fwrite (frame_title_buf, 1, len, stdout);
+          fwrite (xterm_title_end, 1, strlen (xterm_title_end), stdout);
+          fflush (stdout);
+        }
     }
 }
 
-#else /* not HAVE_WINDOW_SYSTEM */
-
-#define frame_title_ptr ((char *)0)
-#define store_frame_title(str, mincol, maxcol) 0
-
-#endif /* not HAVE_WINDOW_SYSTEM */
 
 
 
@@ -7307,7 +7317,6 @@ prepare_menu_bars ()
   /* Update all frame titles based on their buffer names, etc.  We do
      this before the menu bars so that the buffer-menu will show the
      up-to-date frame titles.  */
-#ifdef HAVE_WINDOW_SYSTEM
   if (windows_or_buffers_changed || update_mode_lines)
     {
       Lisp_Object tail, frame;
@@ -7320,7 +7329,6 @@ prepare_menu_bars ()
 	    x_consider_frame_title (frame);
 	}
     }
-#endif /* HAVE_WINDOW_SYSTEM */
 
   /* Update the menu bar item lists, if appropriate.  This has to be
      done before any actual redisplay or generation of display lines.  */
@@ -15120,7 +15128,6 @@ init_xdisp ()
 	default_invis_vector[i] = make_number ('.');
     }
 
-#ifdef HAVE_WINDOW_SYSTEM
   {
     /* Allocate the buffer for frame titles.  */
     int size = 100;
@@ -15128,7 +15135,6 @@ init_xdisp ()
     frame_title_buf_end = frame_title_buf + size;
     frame_title_ptr = NULL;
   }
-#endif /* HAVE_WINDOW_SYSTEM */
   
   help_echo_showing_p = 0;
 }

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

Your patch looks good, except that there is no way to turn it on and
off.  Can you make xterm_title_start and xterm_title_end into Lisp
variables, and enable this feature if their values are strings?

The Lisp variable names should be tty-frame-title-start
and tty-frame-title-end, for consistency.

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

[-- Attachment #1.1: Type: text/plain, Size: 10036 bytes --]

On 26 Sep 2003, Richard Stallman <rms@gnu.org> wrote:
> Your patch looks good, except that there is no way to turn it on and
> off.  Can you make xterm_title_start and xterm_title_end into Lisp
> variables, and enable this feature if their values are strings?

After a bit more study, I think that a better way to do this is to get
the values from termcap for the terminal's status line.  This new
patch does so.

On systems which are using Eric Raymond's termcap distribution the
xterm title line is not represented as a status line.  (I don't really
understand why, since the absence just encourages programs to hardcode
escape sequences as I originally did.)  So on Debian, to make this
patch do anything, you have to set for example TERM=xterm+sl before
running emacs.  This ought to be explained in the NEWS file if this
feature is accepted.

Perhaps this patch ought to add Lisp variables to set the escape
codes, but there is already a (slightly obscure) way to set them
through the termcap file or $TERMCAP.  I think it would be better to
do that, and hope people fix their termcaps, rather than putting in a
redundant mechanism.  If people disagree I can add the variables.

Incidentally, there is a bit of duplicated code in the implementations
of x_explicitly_set_name and x_set_name for different window systems.
It might be good to factor that out to a higher level, and then
perhaps just make the actual work of setting the title go through a
window system specific hook.

This patch causes trouble with mode-line-frame-identification: the
whole title is displayed on the modeline and it takes up a lot of
space.  Normally terminal frames have a little "F%d" identifier,
which is set into f->name by make_terminal_frame().  

The problem is that the usage of the f->name field is a bit
inconsistent between window system and termcap frames.  On termcap
frames it really is the name of the frame, and usually something brief
like 'F0'.  But x_set_name and x_consider_frame_title expect it to be
the title of the frame, as produced from the frame-title-format.

I'm not sure of the best way to resolve this, but resolving it might
remove the kludge of clearing mode-line-frame-identification on
non-termcap frames.

I renamed x_consider_frame_title because it is no longer X-specific.




diff -rud emacs-21.3/src/dispextern.h emacs-21.3-title/src/dispextern.h
--- emacs-21.3/src/dispextern.h	2002-11-15 00:15:46.000000000 +1100
+++ emacs-21.3-title/src/dispextern.h	2003-09-29 13:02:51.000000000 +1000
@@ -2365,6 +2365,7 @@
 /* Defined in term.c */
 
 extern void ring_bell P_ ((void));
+extern void terminal_set_frame_title P_ ((char *, int));
 extern void set_terminal_modes P_ ((void));
 extern void reset_terminal_modes P_ ((void));
 extern void update_begin P_ ((struct frame *));
diff -rud emacs-21.3/src/term.c emacs-21.3-title/src/term.c
--- emacs-21.3/src/term.c	2001-05-31 18:56:32.000000000 +1000
+++ emacs-21.3-title/src/term.c	2003-09-29 13:51:44.000000000 +1000
@@ -285,6 +285,9 @@
 char *TS_set_window;		/* "wi" (4 params, start and end of window,
 				   each as vpos and hpos) */
 
+char *TS_to_status;             /* "ts", go to status line */
+char *TS_from_status;           /* "fs", go back from status line */
+
 /* Value of the "NC" (no_color_video) capability, or 0 if not
    present.  */
 
@@ -369,9 +372,13 @@
 			   TN_standout_width == 0, it means don't bother
 			   to write any end-standout cookies.  */
 
+int TF_status;              /* termcap hs flag: has a status line
+                               (title for xterms) */
+
 int TN_standout_width;	/* termcap sg number: width occupied by standout
 			   markers */
 
+
 static int RPov;	/* # chars to start a TS_repeat */
 
 static int delete_in_insert_mode;	/* delete mode == insert mode */
@@ -472,6 +479,22 @@
 }
 
 void
+terminal_set_frame_title (line, len)
+     char *line;
+     int len;
+{
+  if (!TF_status || !TS_to_status || !TS_from_status)
+    return;                     /* no status line */
+
+  /* XXX: Are there any terminals where we need to explicitly clear
+     the status line after jumping to it? */
+
+  OUTPUT1 (TS_to_status);
+  fwrite (line, 1, len, stdout);
+  OUTPUT1 (TS_from_status);
+}
+
+void
 set_terminal_modes ()
 {
   if (FRAME_TERMCAP_P (XFRAME (selected_frame)))
@@ -2334,6 +2357,9 @@
   TS_cursor_visible = tgetstr ("vs", address);
   TS_cursor_invisible = tgetstr ("vi", address);
   TS_set_window = tgetstr ("wi", address);
+  TS_to_status = tgetstr ("ts", address);
+  TS_from_status = tgetstr ("fs", address);
+  TF_status = tgetflag ("hs");
   
   TS_enter_underline_mode = tgetstr ("us", address);
   TS_exit_underline_mode = tgetstr ("ue", address);
diff -rud emacs-21.3/src/xdisp.c emacs-21.3-title/src/xdisp.c
--- emacs-21.3/src/xdisp.c	2003-01-18 00:45:13.000000000 +1100
+++ emacs-21.3-title/src/xdisp.c	2003-09-29 14:50:09.000000000 +1000
@@ -523,6 +523,11 @@
 
 int cursor_in_non_selected_windows;
 
+/* Non-nil means to try to show frame titles on tty frames.  Whether
+   we can actually do so depends on whether the termcap definition has
+   hardstatus capabilities. */
+Lisp_Object Vtty_frame_title_on_status;
+
 /* A scratch glyph row with contents used for generating truncation
    glyphs.  Also used in direct_output_for_insert.  */
 
@@ -688,7 +693,7 @@
 static int text_outside_line_unchanged_p P_ ((struct window *, int, int));
 static void store_frame_title_char P_ ((char));
 static int store_frame_title P_ ((unsigned char *, int, int));
-static void x_consider_frame_title P_ ((Lisp_Object));
+static void consider_frame_title P_ ((Lisp_Object));
 static void handle_stop P_ ((struct it *));
 static int tool_bar_lines_needed P_ ((struct frame *));
 static int single_display_prop_intangible_p P_ ((Lisp_Object));
@@ -7142,7 +7147,6 @@
  ***********************************************************************/
 
 
-#ifdef HAVE_WINDOW_SYSTEM
 
 /* A buffer for constructing frame titles in it; allocated from the
    heap in init_xdisp and resized as needed in store_frame_title_char.  */
@@ -7211,17 +7215,19 @@
 }
 
 
+
 /* Set the title of FRAME, if it has changed.  The title format is
    Vicon_title_format if FRAME is iconified, otherwise it is
    frame_title_format.  */
 
 static void
-x_consider_frame_title (frame)
+consider_frame_title (frame)
      Lisp_Object frame;
 {
   struct frame *f = XFRAME (frame);
 
   if (FRAME_WINDOW_P (f)
+      || FRAME_TERMCAP_P (f)
       || FRAME_MINIBUF_ONLY_P (f)
       || f->explicit_name)
     {
@@ -7266,18 +7272,31 @@
 	 display_mode_element, then we might need to optimize at a
 	 higher level than this.)  */
       if (! STRINGP (f->name) 
-	  || STRING_BYTES (XSTRING (f->name)) != len
-	  || bcmp (frame_title_buf, XSTRING (f->name)->data, len) != 0)
-	x_implicitly_set_name (f, make_string (frame_title_buf, len), Qnil);
+          || STRING_BYTES (XSTRING (f->name)) != len
+          || bcmp (frame_title_buf, XSTRING (f->name)->data, len) != 0)
+        {
+#ifdef HAVE_WINDOW_SYSTEM
+          /* Even if we're compiled with a window system, we might not be
+             using it for this frame... */
+          /* TODO: There is some common logic across all terminal
+             types that could be factored out of
+             x_implicitly_set_name() */
+          if (FRAME_WINDOW_P (f))
+            x_implicitly_set_name (f, make_string (frame_title_buf, len), Qnil);
+#endif
+          if (FRAME_TERMCAP_P (f)
+              && !NILP (Vtty_frame_title_on_status))
+            {
+              terminal_set_frame_title (frame_title_buf, len);
+              f->name =  make_string (frame_title_buf, len);
+            }
+
+          /* There are other possibilities, e.g. a nongraphical window
+             on Windows NT.  We don't handle that at the moment. */
+        }
     }
 }
 
-#else /* not HAVE_WINDOW_SYSTEM */
-
-#define frame_title_ptr ((char *)0)
-#define store_frame_title(str, mincol, maxcol) 0
-
-#endif /* not HAVE_WINDOW_SYSTEM */
 
 
 
@@ -7307,7 +7326,6 @@
   /* Update all frame titles based on their buffer names, etc.  We do
      this before the menu bars so that the buffer-menu will show the
      up-to-date frame titles.  */
-#ifdef HAVE_WINDOW_SYSTEM
   if (windows_or_buffers_changed || update_mode_lines)
     {
       Lisp_Object tail, frame;
@@ -7317,10 +7335,9 @@
 	  f = XFRAME (frame);
 	  if (!EQ (frame, tooltip_frame)
 	      && (FRAME_VISIBLE_P (f) || FRAME_ICONIFIED_P (f)))
-	    x_consider_frame_title (frame);
+	    consider_frame_title (frame);
 	}
     }
-#endif /* HAVE_WINDOW_SYSTEM */
 
   /* Update the menu bar item lists, if appropriate.  This has to be
      done before any actual redisplay or generation of display lines.  */
@@ -14955,6 +14972,14 @@
 							       Qnil)))),
 			   Qnil)));
 
+  DEFVAR_BOOL ("tty-frame-title-on-status", &Vtty_frame_title_on_status,
+"Non-nil means that the title of a text terminal frame is shown in the\n\
+terminal's \"hard status\" line or a terminal emulator's title bar, if\n\
+the terminal has that capability.\n\
+The terminal must have the \"hs\", \"ts\" and \"fs\" termcap capabilies\n\
+for this to work.");
+  Vtty_frame_title_on_status = Qt;
+
   DEFVAR_LISP ("message-log-max", &Vmessage_log_max,
     "Maximum number of lines to keep in the message log buffer.\n\
 If nil, disable message logging.  If t, log messages but don't truncate\n\
@@ -15120,7 +15145,6 @@
 	default_invis_vector[i] = make_number ('.');
     }
 
-#ifdef HAVE_WINDOW_SYSTEM
   {
     /* Allocate the buffer for frame titles.  */
     int size = 100;
@@ -15128,7 +15152,6 @@
     frame_title_buf_end = frame_title_buf + size;
     frame_title_ptr = NULL;
   }
-#endif /* HAVE_WINDOW_SYSTEM */
   
   help_echo_showing_p = 0;
 }



-- 
Martin 

[-- Attachment #1.2: Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 141 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    Perhaps this patch ought to add Lisp variables to set the escape
    codes, but there is already a (slightly obscure) way to set them
    through the termcap file or $TERMCAP.

I think we should have both interfaces.  It is good to look in the
termcap entry, but xterm is important and we can't expect its termcap
entry to be fixed soon.  So we should create a mechanism that
lisp/term/xterm.el can use to supply the correct information.

Can you do that?

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On  1 Oct 2003, Richard Stallman <rms@gnu.org> wrote:
>     Perhaps this patch ought to add Lisp variables to set the escape
>     codes, but there is already a (slightly obscure) way to set them
>     through the termcap file or $TERMCAP.
> 
> I think we should have both interfaces.  It is good to look in the
> termcap entry, but xterm is important and we can't expect its termcap
> entry to be fixed soon.  So we should create a mechanism that
> lisp/term/xterm.el can use to supply the correct information.
> 
> Can you do that?

Yes, I'll do that.  Thanks for the guidance -- and happy birthday to Gnu!

--
Martin

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On  1 Oct 2003, Richard Stallman <rms@gnu.org> wrote:
>     Perhaps this patch ought to add Lisp variables to set the escape
>     codes, but there is already a (slightly obscure) way to set them
>     through the termcap file or $TERMCAP.
> 
> I think we should have both interfaces.  It is good to look in the
> termcap entry, but xterm is important and we can't expect its termcap
> entry to be fixed soon.  So we should create a mechanism that
> lisp/term/xterm.el can use to supply the correct information.
> 
> Can you do that?

Here's a new patch.

I have set tty-frame-use-title on by default, because it won't do
anything unless we're on a terminal where it can work.  

This works well in xterms and under GNU screen.  It's quite nice to
see the title update as you flip between buffers or screens.  Before
this can be committed we need a term/screen.el as well.

I think the only remaining problem is that this has changed the way
select-buffer-by-name works.  For multi-frame text terminals the names
used to be F%d, but now they're "full" names, probably including the
name of the buffer.  This is inconsistent with how it was documented
to work in the 21.3 manual, but on the other hand it is consistent
with how this function works on windowing system frames.  I'm not sure
how to resolve this.  

To avoid messing up the modeline I have disabled the %F character when
tty-frame-use-title is set.  This is perhaps a bit ugly but I think a
proper resolution would require something like adding a 'short name'
for the frame as distinct from its title.


diff -dru emacs-21.3/lisp/cus-start.el emacs-21.3-title/lisp/cus-start.el
--- emacs-21.3/lisp/cus-start.el	2001-10-29 03:24:54.000000000 +1100
+++ emacs-21.3-title/lisp/cus-start.el	2003-10-02 16:16:15.000000000 +1000
@@ -244,6 +244,9 @@
 					(choice integer
 						(const :tag "No limit" nil)))
 	     (highlight-nonselected-windows display boolean)
+             (tty-frame-use-title display boolean)
+             (tty-frame-title-start display string)
+             (tty-frame-title-end display end)
 	     (message-log-max debug (choice (const :tag "Disable" nil)
 					    (integer :menu-tag "lines"
 						     :format "%v")
diff -dru emacs-21.3/lisp/term/xterm.el emacs-21.3-title/lisp/term/xterm.el
--- emacs-21.3/lisp/term/xterm.el	2001-07-16 21:39:42.000000000 +1000
+++ emacs-21.3-title/lisp/term/xterm.el	2003-10-02 16:24:37.000000000 +1000
@@ -48,4 +48,7 @@
 (define-key function-key-map "\e[24~" [f12])
 (define-key function-key-map "\e[29~" [print])
 
+(set-variable 'tty-frame-title-start "\e]2;")
+(set-variable 'tty-frame-title-end "\007")
+
 ;;; xterm.el ends here
diff -dru emacs-21.3/src/dispextern.h emacs-21.3-title/src/dispextern.h
--- emacs-21.3/src/dispextern.h	2002-11-15 00:15:46.000000000 +1100
+++ emacs-21.3-title/src/dispextern.h	2003-10-02 16:02:18.000000000 +1000
@@ -2224,6 +2224,9 @@
 extern int current_mode_line_height, current_header_line_height;
 extern int cursor_in_non_selected_windows;
 
+extern int tty_frame_use_title;
+extern Lisp_Object Vtty_frame_title_start, Vtty_frame_title_end;
+
 /* Defined in sysdep.c */
 
 void get_frame_size P_ ((int *, int *));
@@ -2365,6 +2368,7 @@
 /* Defined in term.c */
 
 extern void ring_bell P_ ((void));
+extern void terminal_set_frame_title P_ ((char *, int));
 extern void set_terminal_modes P_ ((void));
 extern void reset_terminal_modes P_ ((void));
 extern void update_begin P_ ((struct frame *));
diff -dru emacs-21.3/src/term.c emacs-21.3-title/src/term.c
--- emacs-21.3/src/term.c	2001-05-31 18:56:32.000000000 +1000
+++ emacs-21.3-title/src/term.c	2003-10-02 11:56:47.000000000 +1000
@@ -285,6 +285,9 @@
 char *TS_set_window;		/* "wi" (4 params, start and end of window,
 				   each as vpos and hpos) */
 
+char *TS_to_status;             /* "ts", go to status line */
+char *TS_from_status;           /* "fs", go back from status line */
+
 /* Value of the "NC" (no_color_video) capability, or 0 if not
    present.  */
 
@@ -369,9 +372,13 @@
 			   TN_standout_width == 0, it means don't bother
 			   to write any end-standout cookies.  */
 
+int TF_status;              /* termcap hs flag: has a status line
+                               (title for xterms) */
+
 int TN_standout_width;	/* termcap sg number: width occupied by standout
 			   markers */
 
+
 static int RPov;	/* # chars to start a TS_repeat */
 
 static int delete_in_insert_mode;	/* delete mode == insert mode */
@@ -472,6 +479,30 @@
 }
 
 void
+terminal_set_frame_title (line, len)
+     char *line;
+     int len;
+{
+  /* XXX: Are there any terminals where we need to explicitly clear
+     the status line after jumping to it? */
+
+  if (!NILP (Vtty_frame_title_start)
+      && !NILP (Vtty_frame_title_end))
+    {
+      fputs (XSTRING (Vtty_frame_title_start)->data, stdout);
+      fwrite (line, 1, len, stdout);
+      fputs (XSTRING (Vtty_frame_title_end)->data, stdout);
+    }
+  else if (TF_status && TS_to_status && TS_from_status)
+    {
+      /* defined by termcap */    
+      OUTPUT1 (TS_to_status);
+      fwrite (line, 1, len, stdout);
+      OUTPUT1 (TS_from_status);
+    }
+}
+
+void
 set_terminal_modes ()
 {
   if (FRAME_TERMCAP_P (XFRAME (selected_frame)))
@@ -2334,6 +2365,9 @@
   TS_cursor_visible = tgetstr ("vs", address);
   TS_cursor_invisible = tgetstr ("vi", address);
   TS_set_window = tgetstr ("wi", address);
+  TS_to_status = tgetstr ("ts", address);
+  TS_from_status = tgetstr ("fs", address);
+  TF_status = tgetflag ("hs");
   
   TS_enter_underline_mode = tgetstr ("us", address);
   TS_exit_underline_mode = tgetstr ("ue", address);
diff -dru emacs-21.3/src/xdisp.c emacs-21.3-title/src/xdisp.c
--- emacs-21.3/src/xdisp.c	2003-01-18 00:45:13.000000000 +1100
+++ emacs-21.3-title/src/xdisp.c	2003-10-02 16:24:52.000000000 +1000
@@ -1,5 +1,5 @@
 /* Display generation from window structure and buffer text.
-   Copyright (C) 1985, 86, 87, 88, 93, 94, 95, 97, 98, 99, 2000, 2001, 2002
+   Copyright (C) 1985, 86, 87, 88, 93, 94, 95, 97, 98, 99, 2000, 01, 02, 03
    Free Software Foundation, Inc.
 
 This file is part of GNU Emacs.
@@ -296,6 +296,13 @@
 
 static int message_log_need_newline;
 
+/* Non-nil means to try to show frame titles on tty frames.  Whether
+   we can actually do so depends on whether the termcap definition has
+   hardstatus capabilities. */
+int tty_frame_use_title;
+
+Lisp_Object Vtty_frame_title_start, Vtty_frame_title_end;
+
 \f
 /* The buffer position of the first character appearing entirely or
    partially on the line of the selected window which contains the
@@ -688,7 +695,7 @@
 static int text_outside_line_unchanged_p P_ ((struct window *, int, int));
 static void store_frame_title_char P_ ((char));
 static int store_frame_title P_ ((unsigned char *, int, int));
-static void x_consider_frame_title P_ ((Lisp_Object));
+static void consider_frame_title P_ ((Lisp_Object));
 static void handle_stop P_ ((struct it *));
 static int tool_bar_lines_needed P_ ((struct frame *));
 static int single_display_prop_intangible_p P_ ((Lisp_Object));
@@ -7142,7 +7149,6 @@
  ***********************************************************************/
 
 
-#ifdef HAVE_WINDOW_SYSTEM
 
 /* A buffer for constructing frame titles in it; allocated from the
    heap in init_xdisp and resized as needed in store_frame_title_char.  */
@@ -7211,17 +7217,19 @@
 }
 
 
+
 /* Set the title of FRAME, if it has changed.  The title format is
    Vicon_title_format if FRAME is iconified, otherwise it is
    frame_title_format.  */
 
 static void
-x_consider_frame_title (frame)
+consider_frame_title (frame)
      Lisp_Object frame;
 {
   struct frame *f = XFRAME (frame);
 
   if (FRAME_WINDOW_P (f)
+      || (FRAME_TERMCAP_P (f) && tty_frame_use_title)
       || FRAME_MINIBUF_ONLY_P (f)
       || f->explicit_name)
     {
@@ -7260,24 +7268,41 @@
       frame_title_ptr = NULL;
       set_buffer_internal (obuf);
 
+#ifdef HAVE_WINDOW_SYSTEM
+          /* Even if we're compiled with a window system, we might not be
+             using it for this frame... */
+
       /* Set the title only if it's changed.  This avoids consing in
 	 the common case where it hasn't.  (If it turns out that we've
 	 already wasted too much time by walking through the list with
 	 display_mode_element, then we might need to optimize at a
 	 higher level than this.)  */
-      if (! STRINGP (f->name) 
-	  || STRING_BYTES (XSTRING (f->name)) != len
-	  || bcmp (frame_title_buf, XSTRING (f->name)->data, len) != 0)
-	x_implicitly_set_name (f, make_string (frame_title_buf, len), Qnil);
-    }
-}
+      if (FRAME_WINDOW_P (f))
+        if (! STRINGP (f->name) 
+            || STRING_BYTES (XSTRING (f->name)) != len
+            || bcmp (frame_title_buf, XSTRING (f->name)->data, len) != 0)
+          {
+            /* TODO: There is some common logic across all terminal
+               types that could be factored out of
+               x_implicitly_set_name() */
+            x_implicitly_set_name (f, make_string (frame_title_buf, len), Qnil);
+          }
+#endif
 
-#else /* not HAVE_WINDOW_SYSTEM */
+      /* For termcap windows, we always reset the title when we
+         reconsider it, because this may not have been the
+         previously-visible frame. */
+      if (FRAME_TERMCAP_P (f)  &&  f == SELECTED_FRAME ())
+        {
+          terminal_set_frame_title (frame_title_buf, len);
+          f->name =  make_string (frame_title_buf, len);
+        }
 
-#define frame_title_ptr ((char *)0)
-#define store_frame_title(str, mincol, maxcol) 0
+      /* There are other possibilities, e.g. a nongraphical window
+         on Windows NT.  We don't handle that at the moment. */
+    }
+}
 
-#endif /* not HAVE_WINDOW_SYSTEM */
 
 
 
@@ -7307,7 +7332,6 @@
   /* Update all frame titles based on their buffer names, etc.  We do
      this before the menu bars so that the buffer-menu will show the
      up-to-date frame titles.  */
-#ifdef HAVE_WINDOW_SYSTEM
   if (windows_or_buffers_changed || update_mode_lines)
     {
       Lisp_Object tail, frame;
@@ -7317,10 +7341,9 @@
 	  f = XFRAME (frame);
 	  if (!EQ (frame, tooltip_frame)
 	      && (FRAME_VISIBLE_P (f) || FRAME_ICONIFIED_P (f)))
-	    x_consider_frame_title (frame);
+	    consider_frame_title (frame);
 	}
     }
-#endif /* HAVE_WINDOW_SYSTEM */
 
   /* Update the menu bar item lists, if appropriate.  This has to be
      done before any actual redisplay or generation of display lines.  */
@@ -14068,6 +14091,8 @@
       /* %F displays the frame name.  */
       if (!NILP (f->title))
 	return (char *) XSTRING (f->title)->data;
+      if (FRAME_TERMCAP_P (f) && tty_frame_use_title)
+        return "";
       if (f->explicit_name || ! FRAME_WINDOW_P (f))
 	return (char *) XSTRING (f->name)->data;
       return "Emacs";
@@ -14955,6 +14980,27 @@
 							       Qnil)))),
 			   Qnil)));
 
+  DEFVAR_BOOL ("tty-frame-use-title", &tty_frame_use_title,
+"*Show frame titles in the title or status line of text terminals.\n\
+The title is set if this variable is non-nil and if either \n\
+`tty-frame-title-start' and `tty-frame-title-end' are set, or if the \n\
+terminal has the `ts' and `fs' termcap capabilities.");
+  tty_frame_use_title = 1;
+
+  DEFVAR_LISP ("tty-frame-title-start", &Vtty_frame_title_start,
+"Start of the escape sequence to set a text terminal's title bar.\n\
+This value is only used if `tty-frame-use-title' is non-nil.\n\
+The default value is suitable for xterms, GNU Screen, and many other\n\
+modern terminal emulators.");
+  Vtty_frame_title_start = Qnil;
+
+  DEFVAR_LISP ("tty-frame-title-end", &Vtty_frame_title_end,
+"End of the escape sequence to set a text terminal's title bar.\n\
+This value is only used if `tty-frame-use-title' is non-nil.\n\
+The default value is suitable for xterms, GNU Screen, and many other\n\
+modern terminal emulators.");
+  Vtty_frame_title_end = Qnil;
+
   DEFVAR_LISP ("message-log-max", &Vmessage_log_max,
     "Maximum number of lines to keep in the message log buffer.\n\
 If nil, disable message logging.  If t, log messages but don't truncate\n\
@@ -15120,7 +15166,6 @@
 	default_invis_vector[i] = make_number ('.');
     }
 
-#ifdef HAVE_WINDOW_SYSTEM
   {
     /* Allocate the buffer for frame titles.  */
     int size = 100;
@@ -15128,7 +15173,6 @@
     frame_title_buf_end = frame_title_buf + size;
     frame_title_ptr = NULL;
   }
-#endif /* HAVE_WINDOW_SYSTEM */
   
   help_echo_showing_p = 0;
 }



-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

This patch seems to have been generated against an old version of emacs;
when I tried to apply it against (roughly) CVS HEAD, I got many failed
hunks (note the -l which causes patch to ignore whitespace problems):

   (emacs--cvs-trunk) patch --dry-run -l -p1 < $ls/emacs-xterm-title.patch 
   patching file lisp/cus-start.el
   Hunk #1 succeeded at 258 with fuzz 2 (offset 14 lines).
   patching file lisp/term/xterm.el
   Hunk #1 FAILED at 48.
   1 out of 1 hunk FAILED -- saving rejects to file lisp/term/xterm.el.rej
   patching file src/dispextern.h
   Hunk #1 succeeded at 2544 with fuzz 2 (offset 320 lines).
   Hunk #2 succeeded at 2715 (offset 347 lines).
   patching file src/term.c
   Hunk #1 succeeded at 276 (offset -9 lines).
   Hunk #2 FAILED at 363.
   Hunk #3 succeeded at 448 (offset -31 lines).
   Hunk #4 succeeded at 2332 (offset -33 lines).
   1 out of 4 hunks FAILED -- saving rejects to file src/term.c.rej
   patching file src/xdisp.c
   Hunk #1 FAILED at 1.
   Hunk #2 succeeded at 755 with fuzz 2 (offset 459 lines).
   Hunk #3 FAILED at 1154.
   Hunk #4 succeeded at 7758 with fuzz 2 (offset 609 lines).
   Hunk #5 FAILED at 7826.
   Hunk #6 FAILED at 7877.
   Hunk #7 succeeded at 7871 (offset 539 lines).
   Hunk #8 succeeded at 7880 (offset 539 lines).
   Hunk #9 FAILED at 14630.
   Hunk #10 succeeded at 20993 with fuzz 2 (offset 6013 lines).
   Hunk #11 FAILED at 21179.
   Hunk #12 FAILED at 21186.
   7 out of 12 hunks FAILED -- saving rejects to file src/xdisp.c.rej

It would be nice if you could try to use a development version of emacs
when sending patches.

Thanks,

-Miles
-- 
"1971 pickup truck; will trade for guns"

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On  2 Oct 2003, Miles Bader <miles@lsi.nec.co.jp> wrote:
> This patch seems to have been generated against an old version of emacs;
> when I tried to apply it against (roughly) CVS HEAD, I got many failed
> hunks (note the -l which causes patch to ignore whitespace problems):

It's against 21.3, which is the last version I could find.  When I
looked a few weeks ago, the web site said that the CVS repository was
down.  I'll try to update it.

Do you have any comments on the patch?  This is my first patch for
emacs internals, so please don't trust me. :-)

-- 
Martin

I think that I can safely speak for the whole troll community when I
say "I like watching train wrecks".
		-- AC

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

Martin Pool <mbp@sourcefrog.net> writes:
> Do you have any comments on the patch?  This is my first patch for
> emacs internals, so please don't trust me. :-)

It's a little hard to evaluate in isolation, but here are a few comments:

> diff -dru emacs-21.3/lisp/cus-start.el emacs-21.3-title/lisp/cus-start.el
> +             (tty-frame-use-title display boolean)
> +             (tty-frame-title-start display string)
> +             (tty-frame-title-end display end)

Why are the latter two variables being added to the customize framework?

They seem like low-level variables that are only exported to lisp for
the terminal lisp files to use, not something that a user would
customize.

> diff -dru emacs-21.3/lisp/term/xterm.el emacs-21.3-title/lisp/term/xterm.el
> +(set-variable 'tty-frame-title-start "\e]2;")
> +(set-variable 'tty-frame-title-end "\007")

Why use `set-variable' instead of `set', or indeed, instead of just `setq'?

> diff -dru emacs-21.3/src/dispextern.h emacs-21.3-title/src/dispextern.h
>  void
> +terminal_set_frame_title (line, len)

term.c is not particularly consistent, but in general the naming
convention used seems to be either `set_terminal_foo' or `set_tty_foo'.

> diff -dru emacs-21.3/src/xdisp.c emacs-21.3-title/src/xdisp.c
> +  DEFVAR_BOOL ("tty-frame-use-title", &tty_frame_use_title,
> +"*Show frame titles in the title or status line of text terminals.\n\

I find the name `tty-frame-use-title' a bit odd; how about something
like `tty-show-frame-titles' (it's the first three words of the
docstring, which must mean something :-)?

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    When I
    looked a few weeks ago, the web site said that the CVS repository was
    down.

Which web site said which repository was down?

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On  2 Oct 2003, Richard Stallman <rms@gnu.org> wrote:
>     When I
>     looked a few weeks ago, the web site said that the CVS repository was
>     down.
> 
> Which web site said which repository was down?

The front page of http://savannah.gnu.org/ says "CVS not available",
as of 16th September.

  CVS not available
    posted by yeupou, Tue 09/16/2003 at 07:58 - 3 replies
  Under heavy maintenance, the CVS server is not accessible right now.

  A message will be posted here once it's back on 

When they say "posted here" they actually meant "posted in the page
linked from this headline", but I understood it differently.

I have a checkout now and I'll send an updated patch.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On  2 Oct 2003, Richard Stallman <rms@gnu.org> wrote:
>     I think the only remaining problem is that this has changed the way
>     select-buffer-by-name works.
> 
> I can't find any select-buffer-by-name in the Emacs sources.
> Could you please explain what this is about?

Sorry, I meant select-frame-by-name.

>       For multi-frame text terminals the names
>     used to be F%d, but now they're "full" names, probably including the
>     name of the buffer.
> 
> I am confused.  What are "the names"?

>From the emacs 21.3 manual:
  
  Non-Window Terminals
  ====================
  
  If your terminal does not have a window system that Emacs supports,
  then it can display only one Emacs frame at a time.  However, you can
  still create multiple Emacs frames, and switch between them.  Switching
  frames on these terminals is much like switching between different
  window configurations.
  
     Use `C-x 5 2' to create a new frame and switch to it; use `C-x 5 o'
  to cycle through the existing frames; use `C-x 5 0' to delete the
  current frame.
  
     Each frame has a number to distinguish it.  If your terminal can
  display only one frame at a time, the selected frame's number N appears
  near the beginning of the mode line, in the form `FN'.
  
     `FN' is actually the frame's name.  You can also specify a different
  name if you wish, and you can select a frame by its name.  Use the
  command `M-x set-frame-name <RET> NAME <RET>' to specify a new name for
  the selected frame, and use `M-x select-frame-by-name <RET> NAME <RET>'
  to select a frame according to its name.  The name you specify appears
  in the mode line when the frame is selected.

Before this patch, on non-window terminals, the f->name field is set
to 'F%d' by default.  This identifier also comes up near the left of
the modeline through the mode-line-frame-identification variable and
the '%F' format.  This is why when you start "emacs-21.3 -q nw", you
see the string "F1" to the left of the buffer name.  (I always
wondered why that was there...)

Also in 21.3, the behaviour on window system frames is quite
different: f->name contains what I think of as a "full name" for the
window.  It's produced by expanding the variable frame-title-format.
This is by default "emacs@hostname" if there is one frame, or the
buffer name if there is more than one.  The frame name is usually used
as the window title.  You can also use select-frame-by-name here, but
you need to choose a window title, not a short name like "F1".

The problem is that the manual gives the impression that "each frame
has a number to distinguish it", but in fact this is just a different
default frame name.

This patch makes frame-title-format apply to both window and
non-window frames, so the frame titles are consistent between them.
As a side effect it removes the special-case behaviour for frame names
described in that section of the manual.  In other words, with my
current version of the patch, the first termcap frame is called
"emacs@host", just as for the first window-system frame.

So the functionality of switching between non window system frames
still works, but the pattern names you choose from are different.

>     To avoid messing up the modeline I have disabled the %F character when
>     tty-frame-use-title is set.
> 
> I am confused here too.  What does any of this have to do with
> the mode line?  What would have "messed it up"?

The '%F' format item shows the frame name in the modeline, and it is
in there by default on non-window terminals.

With this patch applied, the frame name follows frame-title-format,
which is typically much longer than two characters.  This causes the
frame title to use up a lot of the space on the modeline.  I say it's
messed up because you might not be able to see, say, the line-number
annunciator.  

If the buffer name is in the frame title then it's printed twice, once
by %F and once by %b.  This looks messy.

-- mbp

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On  4 Oct 2003, Richard Stallman <rms@gnu.org> wrote:
>     Sorry, I meant select-frame-by-name.
> 
>     >       For multi-frame text terminals the names
>     >     used to be F%d, but now they're "full" names, probably including the
>     >     name of the buffer.
> 
> Now I understand.  But I think this is an undesirable
> side effect that the user will notice.  Can you find a way
> to avoid altering these names?

I've thought about this and I can't think of a completely satisfactory
way to reconcile the differences between window-system and text frames
in the existing documented behaviour.

I don't feel qualified to decide what to break.  If you let me know
how you would like it to behave I'll try to write a patch.

I'd guess the number of people using multiple frames on a text
terminal is fairly small, though non-zero.  I would also guess that
more than half the people using emacs in termcap mode are doing so
from some kind of terminal emulator under a window system (xterm,
putty, etc) and so could benefit from seeing the title.

If I had to decide, I would probably just remove the 'F%d' behaviour.
(Specifically, remove that indicator from the toolbar, and remove it
as the default name for tty frames.)  This is a bit disturbing to
people who were accustomed to those features, but it does not really
remove any functionality, as they can still name frames by hand and
switch between them.  I'd choose this because in the long term it's
better to move towards internal consistency at the price of sometimes
breaking things.

In some ways this is an improvement: when people have multiple frames,
they will by default be named using buffer names, which are more
meaningful than F%d.  If people give their frames explicit names
either by hand or from code then those names will work the same way.
C-x 5 commands will also still be the same.

I haven't ever seriously used multiple termcap frames.  Maybe somebody
who does use them has an opinion.

Alternatively we could add an option to give tty frames these names as
'explicit names'.  I would probably have it off by default, because
for users who weren't specifically using this feature they're less
friendly than the names produced by frame-title-format.

Yet another option would be to introduce a new user-visible concept of
a "frame number".  That wouldn't preserve the exact same behaviour and
I'm not sure it would be useful, but if you really want to preserve
F%d it might be the best way.

On the whole I think just making the behaviour the same will please
many people, and annnoy fairly few, and be good for the code.  But let
me know what you want and I'll write it.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Eli Zaretskii]

> Date: Tue, 14 Oct 2003 13:59:33 +1000
> From: Martin Pool <mbp@sourcefrog.net>
> 
> I'd guess the number of people using multiple frames on a text
> terminal is fairly small, though non-zero.

I do.

Please note that some Emacs features, such as Speedbar, create their
own dedicated frames, so if you use those features, you'll be using
multiple frames on text-mode displays whether you want that or not.

> I would also guess that
> more than half the people using emacs in termcap mode are doing so
> from some kind of terminal emulator under a window system (xterm,
> putty, etc) and so could benefit from seeing the title.

Sorry, I don't see how the latter follows from the former.  Could you
please explain?

> If I had to decide, I would probably just remove the 'F%d' behaviour.
> (Specifically, remove that indicator from the toolbar, and remove it
> as the default name for tty frames.)  This is a bit disturbing to
> people who were accustomed to those features, but it does not really
> remove any functionality, as they can still name frames by hand and
> switch between them.

I think it'd be annoying to force the user to set frame names
manually.  That is why I kept the old F1 name and generalized it to
Fn back when I made multiple frames work on ttys.

How about if we have an option that would cause Emacs to either use
the F<num> names (default) or the new names you implemented.  If it
uses F<num>, that name will be displayed on the mode line, as today;
otherwise, the name will be displayed in the xterm's title and be
removed from the mode line.

(I also think that the code that sets the xterm's title should test
whether the required capability is supported, in case we run on
something that is not an xterm at all.)

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On 14 Oct 2003, Eli Zaretskii <eliz@elta.co.il> wrote:
> > Date: Tue, 14 Oct 2003 13:59:33 +1000
> > From: Martin Pool <mbp@sourcefrog.net>
> > 
> > I'd guess the number of people using multiple frames on a text
> > terminal is fairly small, though non-zero.
> 
> I do.

Thanks for responding!

> Please note that some Emacs features, such as Speedbar, create their
> own dedicated frames, so if you use those features, you'll be using
> multiple frames on text-mode displays whether you want that or not.
> 
> > I would also guess that
> > more than half the people using emacs in termcap mode are doing so
> > from some kind of terminal emulator under a window system (xterm,
> > putty, etc) and so could benefit from seeing the title.
> 
> Sorry, I don't see how the latter follows from the former.  Could you
> please explain?

With this feature added, people gain control over a part of their
environment (the xterm titlebar) that previously showed a fixed and
possibly unhelpful string.  The patch puts more of the environment
under the user's control (through mode-line-format), and I think that
control is useful in itself.

One way it might be helpful is in distinguishing emacs xterms from
each other or from other xterms.  I was motivated to do this by having
several emacs sessions open on different machines over ssh.

If you do happen to have several tty frames open, labelling them in
the title bar might help keep track of which one is which.

Some people like to have information in the title bar that won't fit
in their modeline.

Also, vim does it :-)

> > If I had to decide, I would probably just remove the 'F%d' behaviour.
> > (Specifically, remove that indicator from the toolbar, and remove it
> > as the default name for tty frames.)  This is a bit disturbing to
> > people who were accustomed to those features, but it does not really
> > remove any functionality, as they can still name frames by hand and
> > switch between them.
> 
> I think it'd be annoying to force the user to set frame names
> manually.  That is why I kept the old F1 name and generalized it to
> Fn back when I made multiple frames work on ttys.
> 
> How about if we have an option that would cause Emacs to either use
> the F<num> names (default) or the new names you implemented.  If it
> uses F<num>, that name will be displayed on the mode line, as today;
> otherwise, the name will be displayed in the xterm's title and be
> removed from the mode line.

OK.

Should this be a separate variable, or just controlled by
tty-frame-use-title?  Should it be on by default?

> (I also think that the code that sets the xterm's title should test
> whether the required capability is supported, in case we run on
> something that is not an xterm at all.)

The logic is that it is turned on if you set tty-frame-use-title (t by
default) and if emacs knows how to set it.  emacs knows how to set it
if the escape sequences are set either in termcap, or in
tty-frame-title-start/end, typically by xterm.el.  So on e.g. a text
mode virtual console with no title, it should just do nothing.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

Martin Pool <mbp@sourcefrog.net> writes:
> Some people like to have information in the title bar that won't fit
> in their modeline.

I'm confused -- is there actually any question that this is a useful
feature?  I'm constantly annoyed by `full screen' programs in terminal
emulators that _don't_ update the titlebar; it's a very useful feature,
above and beyond the mode-line.

> > How about if we have an option that would cause Emacs to either use
> > the F<num> names (default) or the new names you implemented.  If it
> > uses F<num>, that name will be displayed on the mode line, as today;
> > otherwise, the name will be displayed in the xterm's title and be
> > removed from the mode line.
> 
> OK.
> 
> Should this be a separate variable, or just controlled by
> tty-frame-use-title?  Should it be on by default?

That seems silly; why not just do _both_?  The `Fn' notation doesn't
take up much room in the mode-line, and is simply _different_
information that the actual title.  They're both handy.  So why not
introduce the concept of a `frame index' and display F%d of that in the
mode-line on terminals (hell some people might want to display it in X
too -- it's just a generally handy concept, given that the emacs frame
commands tend to cycle through frames in order).  [I _think_ this is
the last possibility you suggested in your original post]

-miles
-- 
Quidquid latine dictum sit, altum viditur.

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On 14 Oct 2003, Miles Bader <miles@lsi.nec.co.jp> wrote:
> Martin Pool <mbp@sourcefrog.net> writes:
> > Some people like to have information in the title bar that won't fit
> > in their modeline.
> 
> I'm confused -- is there actually any question that this is a useful
> feature?  

That was what I thought Eli was asking.  Maybe I misunderstood his
question.

> I'm constantly annoyed by `full screen' programs in terminal
> emulators that _don't_ update the titlebar; it's a very useful feature,
> above and beyond the mode-line.

That's how I feel.

> > > How about if we have an option that would cause Emacs to either use
> > > the F<num> names (default) or the new names you implemented.  If it
> > > uses F<num>, that name will be displayed on the mode line, as today;
> > > otherwise, the name will be displayed in the xterm's title and be
> > > removed from the mode line.
> > 
> > OK.
> > 
> > Should this be a separate variable, or just controlled by
> > tty-frame-use-title?  Should it be on by default?
> 
> That seems silly; why not just do _both_?  The `Fn' notation doesn't
> take up much room in the mode-line, and is simply _different_
> information that the actual title.  They're both handy.  So why not
> introduce the concept of a `frame index' and display F%d of that in the
> mode-line on terminals (hell some people might want to display it in X
> too -- it's just a generally handy concept, given that the emacs frame
> commands tend to cycle through frames in order).  [I _think_ this is
> the last possibility you suggested in your original post]

Yes, that's what I was getting at.  For the sake of discussion let's
use the term 'frame index'.  

This even makes sense in terms of the 21.3 manual, which half implies
that this already exists:

   Each frame has a number to distinguish it.  If your terminal can
   display only one frame at a time, the selected frame's number N appears
   near the beginning of the mode line, in the form `FN'.

The problem is in the next paragraph: 

    `FN' is actually the frame's name.  You can also specify a
    different name if you wish, and you can select a frame by its
    name.  Use the command `M-x set-frame-name <RET> NAME <RET>' to
    specify a new name for the selected frame, and use `M-x
    select-frame-by-name <RET> NAME <RET>' to select a frame according
    to its name.  The name you specify appears in the mode line when
    the frame is selected.

'F%d' would no longer be the frame's name.

Suppose we added a select-frame-by-index function?  

People would still be able to select-frame-by-name, but the names they
use would be those produced by frame-title-format or set-frame-name,
and never F%d.

Doing this would remove the ugliness of hiding
mode-line-frame-identification on window-system frames.

You could even put the frame index into the frame-title.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

Martin Pool <mbp@sourcefrog.net> writes:
> The problem is in the next paragraph: 
> 
>     `FN' is actually the frame's name.  You can also specify a
>     different name if you wish, and you can select a frame by its
>     name.  Use the command `M-x set-frame-name <RET> NAME <RET>' to
>     specify a new name for the selected frame, and use `M-x
>     select-frame-by-name <RET> NAME <RET>' to select a frame according
>     to its name.  The name you specify appears in the mode line when
>     the frame is selected.
> 
> 'F%d' would no longer be the frame's name.

What about just changing `select-frame-by-name' to first check the given
name against a list of `real names', and then if none match, to see if it's
of the form F%d, and if so select a frame by number.

I get the feeling that almost nobody would use the current meaning except
in interactive use (as a handy way to skip directly to a given frame), so
the above workaround would satisfy most people that use that feature.

Adding `select-frame-by-index' might be useful too, but I think the main
concern here is existing users that are used to using select-frame-by-name.
The above sort of compatibility hack might serve as a gentle introduction
to using meaningful names for frames (it even usually picks good
defaults)... :-)

-Miles
-- 
Suburbia: where they tear out the trees and then name streets after them.

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On 14 Oct 2003, Miles Bader <miles@lsi.nec.co.jp> wrote:
> Martin Pool <mbp@sourcefrog.net> writes:
> > The problem is in the next paragraph: 
> > 
> >     `FN' is actually the frame's name.  You can also specify a
> >     different name if you wish, and you can select a frame by its
> >     name.  Use the command `M-x set-frame-name <RET> NAME <RET>' to
> >     specify a new name for the selected frame, and use `M-x
> >     select-frame-by-name <RET> NAME <RET>' to select a frame according
> >     to its name.  The name you specify appears in the mode line when
> >     the frame is selected.
> > 
> > 'F%d' would no longer be the frame's name.
> 
> What about just changing `select-frame-by-name' to first check the given
> name against a list of `real names', and then if none match, to see if it's
> of the form F%d, and if so select a frame by number.
> 
> I get the feeling that almost nobody would use the current meaning except
> in interactive use (as a handy way to skip directly to a given frame), so
> the above workaround would satisfy most people that use that feature.
> 
> Adding `select-frame-by-index' might be useful too, but I think the main
> concern here is existing users that are used to using select-frame-by-name.
> The above sort of compatibility hack might serve as a gentle introduction
> to using meaningful names for frames (it even usually picks good
> defaults)... :-)

That sounds good to me.  Let's see what people who the feature say.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 14 Oct 2003 16:56:09 +0900
> 
> What about just changing `select-frame-by-name' to first check the given
> name against a list of `real names', and then if none match, to see if it's
> of the form F%d, and if so select a frame by number.

I have no objections to this change, assuming that the F<num> string
is always displayed in the mode line (at least on text-mode terminals).

Re: suggested feature -- console-mode frame title sets Xterm title

[Eli Zaretskii]

> From: Miles Bader <miles@lsi.nec.co.jp>
> Date: 14 Oct 2003 16:29:27 +0900
> 
> I'm confused -- is there actually any question that this is a useful
> feature?

I'm not questioning the usefullness of the feature, but I'd like to
keep the F<num> in the mode line and the associated switch to a
numbered frame intact.

Re: suggested feature -- console-mode frame title sets Xterm title

[Romain FRANCOISE]

Miles Bader <miles@lsi.nec.co.jp> writes:

> That seems silly; why not just do _both_?  The `Fn' notation doesn't
> take up much room in the mode-line, and is simply _different_
> information that the actual title.  They're both handy.

I second that.  I would very much like to see Martin's feature
implemented, but not at the cost of removing the F%d indicator, it's
very useful when working with terminal frames.  Having both would be the
ideal solution.

-- 
Romain FRANCOISE <romain@orebokech.com> | Every sky is blue, but not
it's a miracle -- http://orebokech.com/ | for me and you.

Re: suggested feature -- console-mode frame title sets Xterm title

[Eli Zaretskii]

> Date: Tue, 14 Oct 2003 17:15:39 +1000
> From: Martin Pool <mbp@sourcefrog.net>
> 
> If you do happen to have several tty frames open, labelling them in
> the title bar might help keep track of which one is which.

Please note that, at least currently (and at least AFAIK), several
tty frames open in separate xterm (or terminal emulator) windows
means several separate Emacs sessions, not a single Emacs session.
Each xterm window shows a single frame of one of these sessions.

This is different from a windowed Emacs session, where each frame
belongs to the same session.

(I'm sure I didn't tell you anything you didn't know already, I just
wanted to emphasize the difference between several xterm windows and
several Emacs frames.)

I will respond to the rest of your message later today.

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    How about if we have an option that would cause Emacs to either use
    the F<num> names (default) or the new names you implemented.

Which kind of usage are you talking about in this suggestion?

If you're talking about the xterm title, I don't see why this is desirable.
Always using the new names seems better.

If you're talking about the frame's name, what you would specify to
switch frames, then I don't see why this is desirable.  Always using
the F<n> name seems better.

Is it some other sort of usage that you're thinking of?

Re: suggested feature -- console-mode frame title sets Xterm title

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 15 Oct 2003 00:08:07 -0400
> 
> If you're talking about the frame's name, what you would specify to
> switch frames, then I don't see why this is desirable.  Always using
> the F<n> name seems better.

I thought about using the xterm's title as the frame's name.  People
may wish to use the name displayed in the xterm's title because it's
more descriptive, and thuis more easily remembered, than F<n>.  In
effect, the string in the title could act as the frame's name, making
the use of set-frame-name unnecessary.  (Which means, btw, that, if
Miles's suggestion is implemented, we should decide what to do with
set-frame-name: should it affect the xterm title or the F<n> displayed
in the mode line [or both]).

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

Eli Zaretskii <eliz@elta.co.il> writes:
> > If you're talking about the frame's name, what you would specify to
> > switch frames, then I don't see why this is desirable.  Always using
> > the F<n> name seems better.
> 
> I thought about using the xterm's title as the frame's name.  People
> may wish to use the name displayed in the xterm's title because it's
> more descriptive, and thuis more easily remembered, than F<n>.  In
> effect, the string in the title could act as the frame's name, making
> the use of set-frame-name unnecessary.  (Which means, btw, that, if
> Miles's suggestion is implemented, we should decide what to do with
> set-frame-name: should it affect the xterm title or the F<n> displayed
> in the mode line [or both]).

I really think it ought to work as close to the way X does as possible,
with the F%d notation only used as (1) an abbreviated form displayed in
the mode-line (since the `true name' is too long), and (2) possibly as a
`shortcut name' allowed for switching-frame commands as I described
earlier.

In X, the displayed frame `title' is either the frame's name (set by
set-frame-name), or if that's nil, a string computed using
frame-title-format.  select-frame-by-name actually seems to use the
frame's title, not it's name.

I see no reason _not_ to use this same model for ttys, and doing so
would be a big win for consistency.  If, as I described earlier, F%d
notation were still be displayed in mode-lines, and usable for
select-frame-by-name, the current tty behavior would also largely be
preserved.

I also think that the F%d stuff should work on X -- then there would be
basically no difference between X and ttys in this area.

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On 15 Oct 2003, Miles Bader <miles@lsi.nec.co.jp> wrote:
> Eli Zaretskii <eliz@elta.co.il> writes:
> > > If you're talking about the frame's name, what you would specify to
> > > switch frames, then I don't see why this is desirable.  Always using
> > > the F<n> name seems better.
> > 
> > I thought about using the xterm's title as the frame's name.  People
> > may wish to use the name displayed in the xterm's title because it's
> > more descriptive, and thuis more easily remembered, than F<n>.  In
> > effect, the string in the title could act as the frame's name, making
> > the use of set-frame-name unnecessary.  (Which means, btw, that, if
> > Miles's suggestion is implemented, we should decide what to do with
> > set-frame-name: should it affect the xterm title or the F<n> displayed
> > in the mode line [or both]).
> 
> I really think it ought to work as close to the way X does as possible,
> with the F%d notation only used as (1) an abbreviated form displayed in
> the mode-line (since the `true name' is too long), and (2) possibly as a
> `shortcut name' allowed for switching-frame commands as I described
> earlier.

I agree.

> In X, the displayed frame `title' is either the frame's name (set by
> set-frame-name), or if that's nil, a string computed using
> frame-title-format.  select-frame-by-name actually seems to use the
> frame's title, not it's name.

This is how it looks to the user.  On the inside it is much more
messy, because f->name and f->title are not used in the way their
documentation suggests.  select-frame-by-name uses what seems to be
the frame's title because that gets written into f->name.

There is also some stuff about "explicitly set titles" -- I can see
basically what this is about but I don't understand all the
interactions.

However, it is only software, and can be fixed, if we decide how we
want it to work.

Here is how I think it should work on the inside:

  f->name holds the frame's name, which is initially F%d and can be
  set by set-frame-name

  f->title holds the title generated by frame-title-format, except
  it holds the "explicit title" if one is set.

  f->title is always used for the window title on X or (where possible
  and desired) on ttys.

  f->name is used for the '%F' format in mode-line-frame-identification.
  If you want, you can even put '%F' in frame-title-format to include
  the frame name.

I haven't tried this yet, so it might not work.  But it sounds like it
will give the behaviour we want, and it's cleaner than the present
code.

We have a choice of either making select-frame-by-name look only at
f->name (as it does on tty frames at the moment), or having it also
look at titles as Miles suggested.  If we choose the first, we could
add select-frame-by-title.

> I see no reason _not_ to use this same model for ttys, and doing so
> would be a big win for consistency.  If, as I described earlier, F%d
> notation were still be displayed in mode-lines, and usable for
> select-frame-by-name, the current tty behavior would also largely be
> preserved.
> 
> I also think that the F%d stuff should work on X -- then there would be
> basically no difference between X and ttys in this area.

Yes, and users on ttys who like the F%d name could even arrange for it
to be shown in their xterm title if they wanted.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    Here is how I think it should work on the inside:

      f->name holds the frame's name, which is initially F%d and can be
      set by set-frame-name

      f->title holds the title generated by frame-title-format, except
      it holds the "explicit title" if one is set.

      f->title is always used for the window title on X or (where possible
      and desired) on ttys.

      f->name is used for the '%F' format in mode-line-frame-identification.
      If you want, you can even put '%F' in frame-title-format to include
      the frame name.

It sounds good to me.  Perhaps it will be necessary to have a separate
field for the explicit title (or nil if none).  Don't hesitate to add
one.

    We have a choice of either making select-frame-by-name look only at
    f->name (as it does on tty frames at the moment), or having it also
    look at titles as Miles suggested.

I think looking only at the name is cleaner and simpler,
and on X people probably won't care anyway.

					If we choose the first, we could
    add select-frame-by-title.

I wouldn't bother, since I doubt many people will really want to do
that.

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    I thought about using the xterm's title as the frame's name.  People
    may wish to use the name displayed in the xterm's title because it's
    more descriptive, and thuis more easily remembered, than F<n>.

The title is long, and very likely to change, and may not even be
unique.  So I don't think this is a very useful feature.

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    I've thought about this and I can't think of a completely satisfactory
    way to reconcile the differences between window-system and text frames
    in the existing documented behaviour.

A frame has a name field and a title field.
select-frame-by-name uses the name field.
Can't this feature operate in a way that avoids
changing the name field?

Adding a new field to the frame structure is ok.
Can you solve it that way?

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On 14 Oct 2003, Richard Stallman <rms@gnu.org> wrote:
>     I've thought about this and I can't think of a completely satisfactory
>     way to reconcile the differences between window-system and text frames
>     in the existing documented behaviour.
> 
> A frame has a name field and a title field.
> select-frame-by-name uses the name field.
> Can't this feature operate in a way that avoids
> changing the name field?

The code uses the name and title fields inconsistently.  In
particular, frame-title-format actually sets the f->name field, which
is copied by x_set_title() into the f->title.

We could clean it up but I didn't originally want to make such a large
change.

> Adding a new field to the frame structure is ok.
> Can you solve it that way?

I think so.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

Yes, the relationship between the name and the title is rather ugly.
It was originally a confusion, that I cleared up just enough to make
things work.

To redesign that from zero in a clean way, preserving compatibility
for the features that matter, would be an improvement.

Re: suggested feature -- console-mode frame title sets Xterm title

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 15 Oct 2003 16:00:10 -0400
> 
> To redesign that from zero in a clean way, preserving compatibility
> for the features that matter, would be an improvement.

I agree that it's messy and it's a good idea to redesign it to be
cleaner.

However, while redesigning, please keep in mind that
select-frame-by-name is used on tty's (by users who set up several
frames on tty's) much more than it is on windowed displays.  So the
new implementation of select-frame-by-name should be inobtrusive
enough on tty's.

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

"Eli Zaretskii" <eliz@elta.co.il> writes:
> However, while redesigning, please keep in mind that select-frame-by-name
> is used on tty's (by users who set up several frames on tty's) much more
> than it is on windowed displays.  So the new implementation of
> select-frame-by-name should be inobtrusive enough on tty's.

That's been part of the discussion all along, so I don't think there's
much danger of the issue being ignored; I think the changes that Martin
proposed would do the right thing.

-Miles
-- 
A zen-buddhist walked into a pizza shop and
said, "Make me one with everything."

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

On 16 Oct 2003, Miles Bader <miles@lsi.nec.co.jp> wrote:
> "Eli Zaretskii" <eliz@elta.co.il> writes:
> > However, while redesigning, please keep in mind that select-frame-by-name
> > is used on tty's (by users who set up several frames on tty's) much more
> > than it is on windowed displays.  So the new implementation of
> > select-frame-by-name should be inobtrusive enough on tty's.
> 
> That's been part of the discussion all along, so I don't think there's
> much danger of the issue being ignored; I think the changes that Martin
> proposed would do the right thing.

The main thing giving me trouble at the moment is: what should
set-frame-name do?

The obvious thing would be to make it set the name (f->name).  It's
documented only in the context of replacing F%d with something more
meaningful.

However, on X frames it has the user-visible behaviour of setting the
title, although inside emacs it is really setting f->name.  Once you
have done this, the format produced by frame-title-format is no longer
seen.  I wonder if any users count on this?

I can't think of any consistent way to resolve it, so I propose that
we make set-frame-name simply set the name, and we let people set the
title using the existing mechanisms (frame-title-format, etc).  

People who wish to assign nicknames to their frames can put that in
the frame name, and then include the name in the title format.

We could also add a set-frame-title to set an explicit title
overriding that produced by -format, but that might be an unnecessary
redundancy.

This behaviour will be the same on tty and graphical frames, which
should be good for everyone.

-- 
Martin 

Re: suggested feature -- console-mode frame title sets Xterm title

[Miles Bader]

Martin Pool <mbp@sourcefrog.net> writes:
> The obvious thing would be to make it set the name (f->name).  It's
> documented only in the context of replacing F%d with something more
> meaningful.
> 
> However, on X frames it has the user-visible behaviour of setting the
> title, although inside emacs it is really setting f->name.  Once you
> have done this, the format produced by frame-title-format is no longer
> seen.  I wonder if any users count on this?

I wouldn't be surprised if applications that want to create `special'
frames use `set-frame-name' and expect it to override frame-title-format
(which it currently does on X).

> I can't think of any consistent way to resolve it, so I propose that
> we make set-frame-name simply set the name, and we let people set the
> title using the existing mechanisms (frame-title-format, etc).  

It looks like you basically just have to always be sure that an
_explicitly_ set frame-name overrides the frame-title; under X, the
default frame name is apparently "Emacs", setting it explicitly with
set-frame-name overrides that, but if you do (set-frame-name nil), you
get the default back.  So there really seem to be _two_ frame names,
the `user set' name, and the `automatic name', acting sort of like:

  (defun frame-title (f)
    (or (frame-name f)
        (format-frame-title frame-title-format f))))

  (defun frame-name-for-modeline (f)
    (or (frame-name f)
        (frame-automatic-name f)))

where the initial `user name' is each frame is nil, and the `automatic
name' is "Emacs" on X, and "F..." on ttys.

The main difference between X and ttys seems to be that
`select-frame-by-name' uses `frame-title' (above) to get the list of
names, whereas it uses `frame-name-for-modeline' on ttys.  If it were
to use _both_ then it the resulting single function would be properly
backward compatible on both X and ttys.

So perhaps if the `automatic name' were changed to use the tty-style
"F..." everywhere and select-frame-by-name changed as above, everything
would work properly.

-miles
-- 
Saa, shall we dance?  (from a dance-class advertisement)

Re: suggested feature -- console-mode frame title sets Xterm title

[Stefan Monnier]

> I wouldn't be surprised if applications that want to create `special'
> frames use `set-frame-name' and expect it to override frame-title-format
> (which it currently does on X).

Definitely.  Having to play with `frame-title-format' is annoying,
and it would become necessary in some cases (e.g., you want to change
the name of your frame and then setup your window-manager to behave
differently for that frame).


        Stefan

Re: suggested feature -- console-mode frame title sets Xterm title

[Richard Stallman]

    However, on X frames it has the user-visible behaviour of setting the
    title, although inside emacs it is really setting f->name.  Once you
    have done this, the format produced by frame-title-format is no longer
    seen.  I wonder if any users count on this?

That's specifying an explicit title.  There needs to be a way
to specify an explicit title, but I think we should disconnect
it from the name parameter.

I think it is ok to change the behavior of set-frame-name.
It can't be used terribly often.

Re: suggested feature -- console-mode frame title sets Xterm title

[Martin Pool]

Somebody stole my laptop, so I lost my most recent tree and the
ability to work on it at home.  I will send a patch for the agreed
design when I can.

-- 
Martin