Closed bmag closed 9 years ago
Oh right, I didn't test at all with dedicated windows (and to be fair, I believe them to be a half-assed attempt at introducing some regularity in Emacs' way of window management, simply because the comments in window.el
hint at a way more useful system, but don't implement it).
Bisecting revealed the issue happened after switching to the window-state-get
/window-state-put
storage backend (as opposed to the older current-window-configuration
/set-window-configuration
storage backend). This isn't really surprising as set-window-configuration
is written in C and bypasses all higher-level protections whereas window-state-put
is written in elisp and is subject to the limitations of window.el
(which apparently include being subject to dedication status). I'll dig a bit further to see whether it's an Emacs bug with that function or something I can work around in a better way than unsetting dedication status as you've suggested.
FWIW, window-state-put
errors out when using set-window-buffer
which is defined in C. I don't see any variable or macro to temporarily(!) inhibit the dedicated status, so I'm writing an Emacs bug report for this.
edit: Here it is
Thanks to this discussion master got patched, I'm adding a workaround for earlier versions as Emacs 24.3, 24.4 and 24.5 are still widely in use.
Awesome, thank you
Sorry to re-raise this issue, but the fix in https://github.com/wasamasa/eyebrowse/commit/7f92251f320ac7e49e71f370b5901f6d5fd0bea6 doesn't work in Emacs 24.5.2. I guess the bug in Emacs was fixed in 25.x but the fix was not included in the 24.5.2. Probably the condition should be (version< emacs-version "25")
or something...
Thanks for re-raising, I've totally forgot that there would inevitably be a bump in patch version.
Sometimes when a window is dedicated, switching a workspace fails and messes the frame's window configuration. This causes trouble with packages such as NeoTree - see this report.
Recipe:
emacs -Q -l /path/to/dash.el -l /path/to/eyebrowse.el
M-x eyebrowse-mode
C-x b buff1
M-: (set-window-dedicated-p nil t)
C-x 4 b buff2
C-c C-w 2
Result:buff1
's window becomes the only window in the frame and I see a message: "Window is dedicated to `buff1'". According to the mode-line, a second workspace is created, but the first workspace remains the current workspace.I looked into it, and it seems the error is produced by
window-state-put
. Replace step 6 with:M-: (window-state-put (window-state-get nil 'writable) (frame-root-window))
And the result is an error traceback for "Window is dedicated to `buff1'".I think that adding
(progn (delete-other-windows) (set-window-dedicated-p nil nil))
before callingwindow-state-put
will solve this.P.S. Latest dash and eyebrowse from melpa, emacs version 24.5.