bug#25062: 24.5; Frame title (with "%b" format) changes when going to minibuffer

bug#25062: 24.5; Frame title (with "%b" format) changes when going to minibuffer

[Jonathan Marten]

When using the "%b" substitution in frame-title-format (the default
value includes this when there are multiple frames), the user would
expect the name of the buffer that they are editing to be shown.  This
happens, but when going to the minibuffer for any sort of prompt the
title changes to the buffer name of the minibuffer - "*Minibuf-0*" or
similar.  This may be what is happening internally, but it is an
implementation detail which does not need to be revealed.  The user
might wonder why the window title is changing just because they are
being prompted for some information.

Applying the following patch corrects this.  If the selected window is a 
minibuffer window, it evaluates the format string in the buffer of the 
minibuffer-selected-window instead of the buffer of the minibuffer.  With this 
patch, the frame title stays the same as before when being prompted in the 
minibuffer.

--- emacs-24.5/src/xdisp.c.orig	2015-04-02 08:23:06.000000000 +0100
+++ emacs-24.5/src/xdisp.c	2016-11-22 11:29:13.978385207 +0000
@@ -11612,6 +11612,7 @@
     {
       /* Do we have more than one visible frame on this X display?  */
       Lisp_Object tail, other_frame, fmt;
+      Lisp_Object this_window;
       ptrdiff_t title_start;
       char *title;
       ptrdiff_t len;
@@ -11640,9 +11641,17 @@
 			     format_mode_line_unwind_data
 			       (f, current_buffer, selected_window, 0));
 
-      Fselect_window (f->selected_window, Qt);
+      this_window = f->selected_window;
+      if ( MINI_WINDOW_P (XWINDOW (this_window)))
+        {
+          Lisp_Object original_window = Fminibuffer_selected_window ();
+          if (!NILP (original_window))
+            this_window = original_window;
+        }
+      Fselect_window (this_window, Qt);
+
       set_buffer_internal_1
-	(XBUFFER (XWINDOW (f->selected_window)->contents));
+	(XBUFFER (XWINDOW (this_window)->contents));
       fmt = FRAME_ICONIFIED_P (f) ? Vicon_title_format : Vframe_title_format;
 
       mode_line_target = MODE_LINE_TITLE;





In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.31)
 of 2016-11-22 on keelhaul
Windowing system distributor `The X.Org Foundation', version 11.0.11804000
Configured using:
 `configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-dependency-tracking
 --disable-silent-rules --docdir=/usr/share/doc/emacs-24.5-r3
 --htmldir=/usr/share/doc/emacs-24.5-r3/html --libdir=/usr/lib64
 --program-suffix=-emacs-24 --infodir=/usr/share/info/emacs-24
 --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --with-gameuser=:gamestat --without-compress-install
 --with-file-notification=inotify --enable-acl --without-dbus
 --without-gpm --without-hesiod --without-kerberos --without-kerberos5
 --with-xml2 --without-selinux --with-gnutls --without-wide-int
 --with-zlib --with-sound=alsa --with-x --without-ns --without-gconf
 --without-gsettings --with-toolkit-scroll-bars --with-gif --with-jpeg
 --with-png --with-rsvg --with-tiff --with-xpm --with-imagemagick
 --with-xft --without-libotf --without-m17n-flt --with-x-toolkit=gtk2
 GENTOO_PACKAGE=app-editors/emacs-24.5-r3 'CFLAGS=-O2 -march=native
 -pipe' CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Important settings:
  value of $EMACSLOADPATH: /usr/local/lib/xemacs/local:
  value of $LC_COLLATE: C
  value of $LC_MONETARY: en_GB.UTF-8
  value of $LC_TIME: C
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  asi-indent-mode: 
  tooltip-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  transient-mark-mode: t

Recent messages:
byte-code: End of buffer [2 times]
byte-code: Beginning of buffer [2 times]
Saving /home/jjm/.newsrc...
Saving file /home/jjm/.newsrc...
Wrote /home/jjm/.newsrc
Saving /home/jjm/.newsrc...done
Saving /home/jjm/.newsrc.eld...
Saving file /home/jjm/.newsrc.eld...
Wrote /home/jjm/.newsrc.eld
Saving /home/jjm/.newsrc.eld...done
End of buffer [2 times]

Load-path shadows:
/usr/local/lib/xemacs/local/site-start hides /etc/emacs/site-start

Features:
(shadow sort mail-extr warnings emacsbug sendmail gnus-topic utf-7
nndraft nnmh nnimap parse-time utf7 nnfolder gnus-agent gnus-srvr
gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015
epg-config mm-view mml-smime smime dig gnus-cache gnus-sum netrc gnutls
network-stream starttls tls nntp gnus-group gnus-undo nnmail mail-source
nnoo gnus-start gnus-spec gnus-int gnus-range message format-spec rfc822
mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
gnus-ems nnheader mail-utils wid-edit pp server sunkbd redo+ paren
browse-url paren-xe blink-paren buffer-frame frame-select
auto-set-indent sourcepair url url-proxy url-privacy url-expand
url-methods url-history url-cookie url-domsuf url-util url-parse
auth-source eieio byte-opt bytecomp byte-compile cl-extra cl-loaddefs
cl-lib cconv eieio-core gnus-util mm-util mail-prsvr password-cache
url-vars mailcap compile comint ansi-color ring sgml-mode psgml easymenu
datetrack edj site-gentoo gnu-compat advice help-fns time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
inotify dynamic-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty emacs)

Memory information:
((conses 16 173555 13977)
 (symbols 48 28250 0)
 (miscs 40 110 146)
 (strings 32 39827 6642)
 (string-bytes 1 1298501)
 (vectors 16 20550)
 (vector-slots 8 511832 8105)
 (floats 8 233 332)
 (intervals 56 295 0)
 (buffers 960 19)
 (heap 1024 40082 5871))

bug#25062: 24.5; Frame title (with "%b" format) changes when going to minibuffer

[Eli Zaretskii]

> From: Jonathan Marten <jjm@keelhaul.me.uk>
> Date: Tue, 29 Nov 2016 15:55:30 +0000
> 
> When using the "%b" substitution in frame-title-format (the default
> value includes this when there are multiple frames), the user would
> expect the name of the buffer that they are editing to be shown.  This
> happens, but when going to the minibuffer for any sort of prompt the
> title changes to the buffer name of the minibuffer - "*Minibuf-0*" or
> similar.  This may be what is happening internally, but it is an
> implementation detail which does not need to be revealed.  The user
> might wonder why the window title is changing just because they are
> being prompted for some information.

I actually use this feature all the time: it helps me to find the
frame which is waiting for some input.  So I don't think we should
change that.

Can't you achieve what you want by using some 'eval' form in
frame-title-format?

> Applying the following patch corrects this.  If the selected window is a 
> minibuffer window, it evaluates the format string in the buffer of the 
> minibuffer-selected-window instead of the buffer of the minibuffer.  With this 
> patch, the frame title stays the same as before when being prompted in the 
> minibuffer.

Sorry, I don't think it's right to change that for everyone.

Thanks.

bug#25062: 24.5; Frame title (with "%b" format) changes when going to minibuffer

[Drew Adams]

>> it is an implementation detail which does not need to be revealed.

No.  It is an indication to the user (1) that Emacs is asking for
minibuffer input and (2) which frame has the focus.

>> The user might wonder why the window title is changing

And wondering might lead to understanding why.  (See above.)

>> just because they are being prompted for some information.

The current buffer and the input focus have changed.

> I actually use this feature all the time: it helps me to find the
> frame which is waiting for some input.  So I don't think we should
> change that.... Sorry, I don't think it's right to change that for 
> everyone.

I was going to say the same thing (except that I don't use
the feature, myself).

bug#25062: 24.5; Frame title (with "%b" format) changes when going to minibuffer

[Jonathan Marten]

On Tuesday 29 November 2016 19:37:52 Eli Zaretskii wrote:
> I actually use this feature all the time: it helps me to find the
> frame which is waiting for some input.  So I don't think we should
> change that.
> 
> Can't you achieve what you want by using some 'eval' form in
> frame-title-format?

Thanks for the comments; if this is intentional behaviour then everything is 
working correctly.  I didn't like this happening myself and so looked for a 
way to customise it, and couldn't find one at the Lisp level - but then most 
of my elisp experience has been with XEmacs which didn't support eval forms 
within f-t-f.  Following your suggestion, though, I've found a way that works 
and doesn't need any Emacs changes.

> > Applying the following patch corrects this.  If the selected window is a
> > minibuffer window, it evaluates the format string in the buffer of the
> > minibuffer-selected-window instead of the buffer of the minibuffer.  With
> > this patch, the frame title stays the same as before when being prompted
> > in the minibuffer.
> 
> Sorry, I don't think it's right to change that for everyone.

Since there is a way around it, I'll agree.

> Thanks.

-- 
Jonathan Marten                         http://www.keelhaul.me.uk
Twickenham, UK                          jjm@keelhaul.me.uk

bug#25062: 24.5; Frame title (with "%b" format) changes when going to minibuffer

[Eli Zaretskii]

> From: Jonathan Marten <jjm@keelhaul.me.uk>
> Cc: 25062@debbugs.gnu.org
> Date: Wed, 30 Nov 2016 09:22:21 +0000
> 
> > > Applying the following patch corrects this.  If the selected window is a
> > > minibuffer window, it evaluates the format string in the buffer of the
> > > minibuffer-selected-window instead of the buffer of the minibuffer.  With
> > > this patch, the frame title stays the same as before when being prompted
> > > in the minibuffer.
> > 
> > Sorry, I don't think it's right to change that for everyone.
> 
> Since there is a way around it, I'll agree.

Thanks, I'm therefore closing this bug report.