bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[Vasilij Schneidermann]

[-- Attachment #1: Type: text/plain, Size: 3828 bytes --]

I've written a package for managing window configurations and switched
from using `current-window-configuration' and `set-window-configuration'
for their storage to `window-state-get' and `window-state-put' as
recommended by the Emacs Lisp manual to have serializable state and the
possibility of transforming it in a more elegant manner.

Today an user reported to me that the package doesn't work when strongly
dedicated buffers are involved.  I've refined their reproduction recipe
to the following piece of code which can be evaluated from `emacs -Q` in
the scratch buffer:

(progn
  (switch-to-buffer "*Messages*")
  (let ((old-window-config (window-state-get)))
    (set-window-dedicated-p nil t)
    (switch-to-buffer-other-window "*scratch*")
    (window-state-put old-window-config (frame-root-window))))

To get out of this, it's sufficient to use M-: (set-window-dedicated-p
nil nil) afterwards.

Compare with the following version that doesn't error out:

(progn
  (switch-to-buffer "*Messages*")
  (let ((old-window-config (current-window-configuration)))
    (set-window-dedicated-p nil t)
    (switch-to-buffer-other-window "*scratch*")
    (set-window-configuration old-window-config)))

Is this a bug? If not, is there a way of working around this in a sane
fashion (like, not removing the dedication status of the window)?



In GNU Emacs 24.5.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.16.2)
 of 2015-04-20 on bitzer.hoetzel.info
Windowing system distributor `The X.Org Foundation', version 11.0.11701000
System Description: Arch Linux

Configured using:
 `configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong
 --param=ssp-buffer-size=4' CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-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
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util help-fns mail-prsvr mail-utils 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
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 70995 6884)
 (symbols 48 17559 0)
 (miscs 40 35 138)
 (strings 32 9046 4656)
 (string-bytes 1 248445)
 (vectors 16 8907)
 (vector-slots 8 383084 18361)
 (floats 8 63 89)
 (intervals 56 177 6)
 (buffers 960 11)
 (heap 1024 48846 939))

[-- Attachment #2: Type: text/html, Size: 4348 bytes --]

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[martin rudalics]

 > Is this a bug? If not, is there a way of working around this in a sane
 > fashion (like, not removing the dedication status of the window)?

Do you mean we should apply the following patch?

martin


--- a/lisp/window.el
+++ b/lisp/window.el
@@ -5375,6 +5375,8 @@ windows can get as small as `window-safe-min-height' and
  			root))))
        (delete-other-windows-internal window root)))

+  (set-window-dedicated-p window nil)
+
    (let* ((frame (window-frame window))
  	 (head (car state))
  	 ;; We check here (1) whether the total sizes of root window of

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[Vasilij Schneidermann]

> Do you mean we should apply the following patch?

That doesn't look right to me at all.  Would the dedicated flag be
correctly put back in place again?  If not, I'd prefer a lower-level
patch for temporarily ignoring it.

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[martin rudalics]

 > That doesn't look right to me at all.  Would the dedicated flag be
 > correctly put back in place again?

The dedicated status is stored for each live window individually and
should be restored as such.  Did you try it?

 > If not, I'd prefer a lower-level
 > patch for temporarily ignoring it.

The state of the argument window of ‘window-state-put’ is destroyed by
the latter so I have no idea how that could be done.

martin

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[Vasilij Schneidermann]

> The dedicated status is stored for each live window individually and
> should be restored as such.  Did you try it?

Yes, the patch works for me.  To accomodate for Emacs 24.3, 24.4 and
24.5, I've modified my example to contain a workaround:

(progn
  (switch-to-buffer "*Messages*")
  (let ((old-window-config (window-state-get)))
    (set-window-dedicated-p nil t)
    (switch-to-buffer-other-window "*scratch*")
    (when (version<= emacs-version "24.5")
      (delete-other-windows)
      (set-window-dedicated-p nil nil)
      (window-state-put old-window-config (frame-root-window)))))
 
> The state of the argument window of ‘window-state-put’ is destroyed by
> the latter so I have no idea how that could be done.
 
I thought of introducing a variable roughly equivalent to
`inhibit-read-only' which state is checked by a few window primitives.
If it were bound, functions like `set-window-buffer' wouldn't error out
for dedicated windows at all.

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[martin rudalics]

 > Yes, the patch works for me.

Pushed to trunk/master as f95211e..1338482  master -> master.

 > I thought of introducing a variable roughly equivalent to
 > `inhibit-read-only' which state is checked by a few window primitives.
 > If it were bound, functions like `set-window-buffer' wouldn't error out
 > for dedicated windows at all.

This might work.  But before doing that we'd have to find a couple of
situations where such a variable could be useful.  ‘window-state-put’
alone is no sufficient justification.

martin

bug#20848: 24.5; window-state-put fails when strongly dedicated windows are involved

[martin rudalics]

Version: 25.1

Closing this bug.

Thanks for the report, martin