* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file @ 2011-10-26 2:03 Christoph Scholtes 2011-10-26 2:16 ` Juanma Barranquero 0 siblings, 1 reply; 22+ messages in thread From: Christoph Scholtes @ 2011-10-26 2:03 UTC (permalink / raw) To: 9873 emacs -Q C-x d <ret> C-x 2 select at least to files for deletion with `d' press x The top window now shows the *Deletions* buffer at the bottom, but the size of the top dired buffer shrunk by about a third. This only happens when the frame is split with C-x 2 to show two windows. In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601) of 2011-10-24 on MARVIN Windowing system distributor `Microsoft Corp.', version 6.1.7601 configured using `configure --with-gcc (4.6) --no-opt --cflags -I"D:/devel/emacs/libs/libXpm-3.5.8/include" -I"D:/devel/emacs/libs/libXpm-3.5.8/src" -I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include" -I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include" -I"D:/devel/emacs/libs/giflib-4.1.4-1/include" -I"D:/devel/emacs/libs/jpeg-6b-4/include" -I"D:/devel/emacs/libs/tiff-3.8.2-1/include" -I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags -L"D:/devel/emacs/libs/gnutls-2.10.1/lib"' Important settings: value of $LC_ALL: nil value of $LC_COLLATE: nil value of $LC_CTYPE: nil value of $LC_MESSAGES: nil value of $LC_MONETARY: nil value of $LC_NUMERIC: nil value of $LC_TIME: nil value of $LANG: ENU value of $XMODIFIERS: nil locale-coding-system: cp1252 default enable-multibyte-characters: t Major mode: Group Minor modes in effect: gnus-topic-mode: t my-keys-minor-mode: t erc-autojoin-mode: t erc-track-mode: t erc-match-mode: t erc-pcomplete-mode: t erc-stamp-mode: t global-auto-complete-mode: t gnus-undo-mode: t desktop-save-mode: t ido-everywhere: t yas/global-mode: t global-auto-revert-mode: t tooltip-mode: t mouse-wheel-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 size-indication-mode: t column-number-mode: t line-number-mode: t Recent input: <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> M-d M-d M-d M-d M-d <left> <backspace> SPC a n d M-q <down> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <left> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <backspace> ? <right> M-d C-d <right> <right> <right> <right> <right> <right> t h e n SPC M-q <down> <down> <backspace> . <up> <up> <down> <down> <down> <down> <down> <down> <down> <down> <up> <up> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <M-backspace> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> C-k <down> <down> <down> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <down> <down> . . <backspace> <backspace> <down> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <right> <left> h <down> <down> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <up> <left> <left> <left> , SPC b u t C-c C-c g <return> C-n C-n C-n C-n C-n C-n C-n C-n <return> C-p C-p C-p C-p C-p C-p C-p C-p <return> q g <down-mouse-1> <mouse-1> M-x r e p o r t - e <tab> <return> Recent messages: Checking new news... nnimap read 0k nnimap read 26k Reading active file from archive via nnfolder...done Checking new news...done nnimap read 0k Checking new news... nnimap read 0k Reading active file from archive via nnfolder...done Checking new news...done Load-path shadows: c:/Users/Christoph/AppData/Roaming/.emacs.d/plugins/python hides d:/devel/emacs/emacs-bzr/trunk_jenkins/lisp/progmodes/python Features: (shadow emacsbug vc-bzr multi-isearch etags flow-fill vc-hg mailalias smtpmail sendmail newcomment qp sort mule-util ansi-color gnus-cite mail-extr gnus-async gnus-bcklg gnus-ml gnus-topic nndraft nnmh nnfolder utf-7 gnutls network-stream auth-source eieio starttls nnimap parse-time tls utf7 netrc gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime password-cache dig mailcap nntp gnus-cache paredit org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc org-jsinfo org-infojs org-html org-exp ob-exp org-exp-blocks org-agenda org-info org-gnus org-docview org-bibtex bibtex org-bbdb org byte-opt warnings bytecomp byte-compile cconv ob-emacs-lisp ob-tangle ob-ref ob-lob ob-table org-footnote org-src ob-comint ob-keys ob ob-eval org-pcomplete org-list org-faces org-compat org-entities org-macs noutline outline cal-menu calendar cal-loaddefs my-zenburn-theme erc-join erc-track erc-match erc-pcomplete pcomplete erc-stamp erc-goodies erc erc-backend erc-compat thingatpt windmove auto-complete-config auto-complete popup find-func ispell bookmark+ bookmark+-key dired-x dired bookmark+-1 nnir gnus-sum macroexp nnoo gnus-group gnus-undo nnmail mail-source 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 gnus-util mail-utils mm-util mail-prsvr wid-edit bookmark+-bmu help-mode view bookmark+-lit pp+ bookmark+-mac bookmark pp midnight desktop ibuffer uniquify autopair google-c-style cc-styles cc-align cc-engine cc-vars cc-defs grep-o-matic grep compile comint regexp-opt ring browse-kill-ring+ browse-kill-ring second-sel ido yasnippet dropdown-list derived easy-mmode edmacro kmacro easymenu assoc cl org-install server advice help-fns advice-preload debbugs-autoloads package tabulated-list autorevert time-date tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe lisp-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 button faces cus-face files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process multi-tty emacs) ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 2:03 bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file Christoph Scholtes @ 2011-10-26 2:16 ` Juanma Barranquero 2011-10-26 2:50 ` Christoph Scholtes 0 siblings, 1 reply; 22+ messages in thread From: Juanma Barranquero @ 2011-10-26 2:16 UTC (permalink / raw) To: Christoph Scholtes; +Cc: 9873 > emacs -Q Try with emacs -Q --eval "(setq window-nest t)" Juanma ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 2:16 ` Juanma Barranquero @ 2011-10-26 2:50 ` Christoph Scholtes 2011-10-26 2:52 ` Juanma Barranquero 0 siblings, 1 reply; 22+ messages in thread From: Christoph Scholtes @ 2011-10-26 2:50 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 9873 Juanma Barranquero <lekktu@gmail.com> writes: > Try with > > emacs -Q --eval "(setq window-nest t)" Thanks Juanma, this fixes the problem. I am not sure I understand what other implications this has, though. Was this meant to be a test or a permanent solution? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 2:50 ` Christoph Scholtes @ 2011-10-26 2:52 ` Juanma Barranquero 2011-10-26 9:22 ` martin rudalics 0 siblings, 1 reply; 22+ messages in thread From: Juanma Barranquero @ 2011-10-26 2:52 UTC (permalink / raw) To: Christoph Scholtes; +Cc: 9873 On Wed, Oct 26, 2011 at 04:50, Christoph Scholtes <cschol2112@googlemail.com> wrote: > Thanks Juanma, this fixes the problem. I am not sure I understand what > other implications this has, though. You'll have to ask Martin for that. > Was this meant to be a test or a permanent solution? Is what I have in my .emacs. Juanma ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 2:52 ` Juanma Barranquero @ 2011-10-26 9:22 ` martin rudalics 2011-10-26 11:08 ` Eli Zaretskii 2011-10-27 3:39 ` Christoph Scholtes 0 siblings, 2 replies; 22+ messages in thread From: martin rudalics @ 2011-10-26 9:22 UTC (permalink / raw) To: Juanma Barranquero; +Cc: Christoph Scholtes, 9873 >> Thanks Juanma, this fixes the problem. I am not sure I understand what >> other implications this has, though. > > You'll have to ask Martin for that. The Elisp manual should cover `window-nest' in some detail. Please have a look. BTW this bug has been first described by Juri in Message#65 of Bug#1806. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 9:22 ` martin rudalics @ 2011-10-26 11:08 ` Eli Zaretskii 2011-10-26 14:22 ` martin rudalics 2011-10-27 3:39 ` Christoph Scholtes 1 sibling, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2011-10-26 11:08 UTC (permalink / raw) To: martin rudalics; +Cc: cschol2112, lekktu, 9873 > Date: Wed, 26 Oct 2011 11:22:04 +0200 > From: martin rudalics <rudalics@gmx.at> > Cc: Christoph Scholtes <cschol2112@googlemail.com>, 9873@debbugs.gnu.org > > >> Thanks Juanma, this fixes the problem. I am not sure I understand what > >> other implications this has, though. Lucky you. I didn't understand a thing about it. > The Elisp manual should cover `window-nest' in some detail. Please have > a look. IMNSHO, the doc string needs "Some Work"®, as right now it's impenetrable for mere mortals (this being is a user option). Users aren't, and shouldn't be, aware that windows are arranged in a tree. Without a very good understanding of that, talking about "a new parent window" and "binary tree of windows" misses the target by a very large measure. Besides, user options should be first and foremost be described in the user manual, not in the ELisp manual. After reading what's written in the ELisp manual (and digressing to "Windows and Frames" for a while, to understand what the heck it is talking about when it says "parent window"), I do understand what the variable does in terms of the window tree, but still cannot tell I understand its effects in practice, beyond the specific example of splitting and unsplitting windows that is described there in detail. Is this the only user-visible effect of this variable? If so, why not name it something that is related to resizing or splitting, and why not say that in the doc string, instead of describing the window tree and the "parent window" which a user will never see and does not care about in the first place? Since when do we explain user-level features in terms of abstract data types and structures that are all but invisible to users?? I'm sorry for being so blunt, but it's the first time I've read in an Emacs manual a whole section, which does a very good job at describing what it sets out to describe, but is completely useless for me as a guide for understanding the practical implications of a certain user option. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 11:08 ` Eli Zaretskii @ 2011-10-26 14:22 ` martin rudalics 2011-10-26 18:30 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: martin rudalics @ 2011-10-26 14:22 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, lekktu, 9873 >> The Elisp manual should cover `window-nest' in some detail. Please have >> a look. > > IMNSHO, the doc string needs "Some Work"®, as right now it's > impenetrable for mere mortals (this being is a user option). Users > aren't, and shouldn't be, aware that windows are arranged in a tree. > Without a very good understanding of that, talking about "a new parent > window" and "binary tree of windows" misses the target by a very large > measure. Describing what `window-nest' does without referring to the window tree is virtually impossible (aat least for me). > Besides, user options should be first and foremost be described in the > user manual, not in the ELisp manual. Agreed. But since I apparently failed to convey the semantics of this variable in the Elisp manual, someone else will have to take care of writing such a description ;-) > After reading what's written in the ELisp manual (and digressing to > "Windows and Frames" for a while, to understand what the heck it is > talking about when it says "parent window"), I do understand what the > variable does in terms of the window tree, but still cannot tell I > understand its effects in practice, beyond the specific example of > splitting and unsplitting windows that is described there in detail. > Is this the only user-visible effect of this variable? No. Suppose a window W is a vertical combination of two windows W1 and W2 and W2 is a vertical combination of two windows W3 and W4. In this case resizing W will equally affect W1 and W2 and consequently W1 more than W3 or W4. This is different from the case where W is a vertical combination of three live windows W1, W3 and W4. > If so, why not > name it something that is related to resizing or splitting, and why > not say that in the doc string, instead of describing the window tree > and the "parent window" which a user will never see and does not care > about in the first place? Since when do we explain user-level > features in terms of abstract data types and structures that are all > but invisible to users?? This is the Elisp manual and I have been trying to explain all related terms in the section "Windows and Frames". If there's something missing, including cross references to that section, you're welcome to fix that. > I'm sorry for being so blunt, but it's the first time I've read in an > Emacs manual a whole section, which does a very good job at describing > what it sets out to describe, but is completely useless for me as a > guide for understanding the practical implications of a certain user > option. One practical implication of not having that option is evident from the example. If it has further implications, then that's something we will find out as soon as people have started to customize it. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 14:22 ` martin rudalics @ 2011-10-26 18:30 ` Eli Zaretskii 2011-10-27 9:51 ` martin rudalics 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2011-10-26 18:30 UTC (permalink / raw) To: martin rudalics; +Cc: cschol2112, lekktu, 9873 > Date: Wed, 26 Oct 2011 16:22:59 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: lekktu@gmail.com, cschol2112@googlemail.com, 9873@debbugs.gnu.org > > Describing what `window-nest' does without referring to the window tree > is virtually impossible (aat least for me). Well, how about explaining why this variable was introduced, for starters? What problem(s) did its introduction try to solve? > > Is [splitting and unsplitting windows] the only user-visible > > effect of this variable? > > No. Suppose a window W is a vertical combination of two windows W1 and > W2 and W2 is a vertical combination of two windows W3 and W4. In this > case resizing W will equally affect W1 and W2 and consequently W1 more > than W3 or W4. This is different from the case where W is a vertical > combination of three live windows W1, W3 and W4. Sorry, I don't get the drift. What do you mean by "resizing W"? how can one resize "a vertical combination" of 2 or 3 windows, which AFAIU is just a node in the window tree, not a live window that is displayed on a frame? I mean, I can resize W1, W2, or W3, but how do I resize their combination? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 18:30 ` Eli Zaretskii @ 2011-10-27 9:51 ` martin rudalics 2011-10-27 10:23 ` Eli Zaretskii 0 siblings, 1 reply; 22+ messages in thread From: martin rudalics @ 2011-10-27 9:51 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, lekktu, 9873 > Well, how about explaining why this variable was introduced, for > starters? What problem(s) did its introduction try to solve? Its introduction modifies the behavior of splitting, resizing and deleting windows in the order described in the example in the manual. Bug reports #1806 and #9873 confirm that the behavior of Emacs 23 in this regard is problematic, at least > Sorry, I don't get the drift. What do you mean by "resizing W"? how > can one resize "a vertical combination" of 2 or 3 windows, which AFAIU > is just a node in the window tree, not a live window that is displayed > on a frame? You won't get the drift as long as you insist that an internal window is "just a node in the window tree". > I mean, I can resize W1, W2, or W3, but how do I resize > their combination? By resizing their parent window or a sibling of their parent window. Or by resizing the containing frame. Or by resizing the minibuffer window. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-27 9:51 ` martin rudalics @ 2011-10-27 10:23 ` Eli Zaretskii 2011-10-27 13:15 ` martin rudalics 0 siblings, 1 reply; 22+ messages in thread From: Eli Zaretskii @ 2011-10-27 10:23 UTC (permalink / raw) To: martin rudalics; +Cc: cschol2112, lekktu, 9873 > Date: Thu, 27 Oct 2011 11:51:12 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: lekktu@gmail.com, cschol2112@googlemail.com, 9873@debbugs.gnu.org > > > Well, how about explaining why this variable was introduced, for > > starters? What problem(s) did its introduction try to solve? > > Its introduction modifies the behavior of splitting, resizing and > deleting windows in the order described in the example in the manual. I understand that it affects resizing (by changing which other window is resized as side effect of changing the size of the window we want to resize), and deleting (by controlling which window will be given the space released by the deleted one). But what is modified in the behavior of splitting? > > Sorry, I don't get the drift. What do you mean by "resizing W"? how > > can one resize "a vertical combination" of 2 or 3 windows, which AFAIU > > is just a node in the window tree, not a live window that is displayed > > on a frame? > > You won't get the drift as long as you insist that an internal window is > "just a node in the window tree". What I mean is that the user have no way of resizing the internal windows, only the live windows, AFAIK. A Lisp program can resize an internal window, but doing so is precisely equivalent to resizing one of the live windows on the same frame (again, AFAIK). When you talk about resizing a live window, I understand exactly what is meant. If by "vertical combination" you mean the internal window that is the parent of 2 or more live windows, I can understand that as well, assuming that you are talking about a Lisp program. If you mean anything else, please explain what I am missing. > > I mean, I can resize W1, W2, or W3, but how do I resize > > their combination? > > By resizing their parent window or a sibling of their parent window. Or > by resizing the containing frame. Or by resizing the minibuffer window. Some of these are unavailable to users. We were talking about a user option. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-27 10:23 ` Eli Zaretskii @ 2011-10-27 13:15 ` martin rudalics 0 siblings, 0 replies; 22+ messages in thread From: martin rudalics @ 2011-10-27 13:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, lekktu, 9873 >> Its introduction modifies the behavior of splitting, resizing and >> deleting windows in the order described in the example in the manual. > > I understand that it affects resizing (by changing which other window > is resized as side effect of changing the size of the window we want > to resize), and deleting (by controlling which window will be given > the space released by the deleted one). But what is modified in the > behavior of splitting? There's yet another new variable called `window-splits'. That variable allows to steal space from other windows when splitting, so you can "split" windows which are otherwise too small. Now if `window-nest' is non-nil, `window-splits' has no effect. > What I mean is that the user have no way of resizing the internal > windows, only the live windows, AFAIK. > > A Lisp program can resize an internal window, but doing so is > precisely equivalent to resizing one of the live windows on the same > frame (again, AFAIK). No. Resizing an internal window with two child windows usually resizes _both_ child windows proportionally (usually so, because edge dragging behaves different from other forms of resizing). > When you talk about resizing a live window, I understand exactly what > is meant. Then you know more than me. Resizing a live window can resize all other windows on the same frame. Adjusting the edge of a live window can be different from enlarging that window. In addition, the nest and splits status of the window affect the outcome as well. All I know is that when I resize a window in a certain way, I can live with the result, or not. In the latter case, I try to fix the behavior. But I gave up understanding what happens some time ago. > If by "vertical combination" you mean the internal window > that is the parent of 2 or more live windows, I can understand that as > well, assuming that you are talking about a Lisp program. A vertical combination is slightly more than a parent window. It encompasses number and sizes of the parent's child windows too, which can be retrieved only by looking at these child windows. Also, a vertical combination can be the parent of 2 or more internal windows, or live and internal windows. >> By resizing their parent window or a sibling of their parent window. Or >> by resizing the containing frame. Or by resizing the minibuffer window. > > Some of these are unavailable to users. ... but maybe hidden in operations available to the user ... > We were talking about a user > option. ... which is hard to explain, I know. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-26 9:22 ` martin rudalics 2011-10-26 11:08 ` Eli Zaretskii @ 2011-10-27 3:39 ` Christoph Scholtes 2011-10-27 9:53 ` martin rudalics 1 sibling, 1 reply; 22+ messages in thread From: Christoph Scholtes @ 2011-10-27 3:39 UTC (permalink / raw) To: martin rudalics; +Cc: Juanma Barranquero, 9873 martin rudalics <rudalics@gmx.at> writes: > The Elisp manual should cover `window-nest' in some detail. Please have > a look. > > BTW this bug has been first described by Juri in Message#65 of Bug#1806. I see. Was there ever a conclusion reached? Ibuffer has the same issue, btw. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-27 3:39 ` Christoph Scholtes @ 2011-10-27 9:53 ` martin rudalics 2011-10-28 8:12 ` Juri Linkov 2012-10-04 18:31 ` Juri Linkov 0 siblings, 2 replies; 22+ messages in thread From: martin rudalics @ 2011-10-27 9:53 UTC (permalink / raw) To: Christoph Scholtes; +Cc: Juanma Barranquero, 9873 >> BTW this bug has been first described by Juri in Message#65 of Bug#1806. > > I see. Was there ever a conclusion reached? No. > Ibuffer has the same issue, btw. More will turn up. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-27 9:53 ` martin rudalics @ 2011-10-28 8:12 ` Juri Linkov 2011-10-28 17:16 ` martin rudalics 2012-10-04 18:31 ` Juri Linkov 1 sibling, 1 reply; 22+ messages in thread From: Juri Linkov @ 2011-10-28 8:12 UTC (permalink / raw) To: martin rudalics; +Cc: Christoph Scholtes, Juanma Barranquero, 9873 >>> BTW this bug has been first described by Juri in Message#65 of Bug#1806. >> >> I see. Was there ever a conclusion reached? > > No. Are we waiting for a conclusion whether to set `window-nest' to t by default or to bind it individually where necessary? Are there other options? >> Ibuffer has the same issue, btw. > > More will turn up. In Message#45 of Bug#1806 you already found more: `Electric-pop-up-window', `ibuffer-confirm-operation-on', `disabled-command-function', `proced-send-signal', `fancy-startup-screen', `display-time-world', `widget-choose'. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-28 8:12 ` Juri Linkov @ 2011-10-28 17:16 ` martin rudalics 2011-10-31 10:11 ` Juri Linkov 0 siblings, 1 reply; 22+ messages in thread From: martin rudalics @ 2011-10-28 17:16 UTC (permalink / raw) To: Juri Linkov; +Cc: Christoph Scholtes, Juanma Barranquero, 9873 > Are we waiting for a conclusion whether to set `window-nest' to t by default > or to bind it individually where necessary? Setting it to t by default and _not_ binding it individually will have detrimental consequences for people who don't want it always t. Juanma wants it always t because he wants to control the layout of his windows. I'm more sloppy in this respect. Hence if we choose to handle this via `window-nest' we should bind that individually. > Are there other options? You could try writing a suitable buffer display function ;-) >>> Ibuffer has the same issue, btw. >> More will turn up. > > In Message#45 of Bug#1806 you already found more: > > `Electric-pop-up-window', `ibuffer-confirm-operation-on', > `disabled-command-function', `proced-send-signal', > `fancy-startup-screen', `display-time-world', `widget-choose'. I forgot about these. Must have been some quick random search. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-28 17:16 ` martin rudalics @ 2011-10-31 10:11 ` Juri Linkov 2011-10-31 10:27 ` martin rudalics 0 siblings, 1 reply; 22+ messages in thread From: Juri Linkov @ 2011-10-31 10:11 UTC (permalink / raw) To: martin rudalics; +Cc: Christoph Scholtes, Juanma Barranquero, 9873 >> Are we waiting for a conclusion whether to set `window-nest' to t by default >> or to bind it individually where necessary? > > Setting it to t by default and _not_ binding it individually will have > detrimental consequences for people who don't want it always t. Juanma > wants it always t because he wants to control the layout of his windows. > I'm more sloppy in this respect. Hence if we choose to handle this via > `window-nest' we should bind that individually. > >> Are there other options? > > You could try writing a suitable buffer display function ;-) Below is a new buffer display function created from `dired-pop-to-buffer' that can be used in all packages that need this functionality like Dired and Proced (more could be fixed later if this is the right approach): === modified file 'lisp/window.el' --- lisp/window.el 2011-10-30 08:29:56 +0000 +++ lisp/window.el 2011-10-31 10:05:16 +0000 @@ -4851,6 +4851,24 @@ (defun display-buffer-pop-up-window (buf (set-window-prev-buffers window nil) window))) +(defun display-buffer-pop-up-window-below (buffer alist) + "Display BUFFER by popping up a new window below the selected window." + (let ( + ;; Stay within the confines of the initial window. + ;; Don't resize other windows. (Bug#1806 Bug#9873) + (window-nest t) + (split-window-preferred-function + (lambda (window) + (or (and (let ((split-height-threshold 0)) + (window-splittable-p (selected-window))) + ;; Try to split the selected window vertically if + ;; that's possible. (Bug#1806) + (split-window-below)) + ;; Otherwise, try to split WINDOW sensibly. + (split-window-sensibly window)))) + pop-up-frames) + (display-buffer-pop-up-window buffer alist))) + (defun display-buffer--maybe-pop-up-frame-or-window (buffer alist) "Try displaying BUFFER based on `pop-up-frames' or `pop-up-windows'. === modified file 'lisp/dired.el' --- lisp/dired.el 2011-10-30 01:56:03 +0000 +++ lisp/dired.el 2011-10-31 10:06:19 +0000 @@ -2873,17 +2873,7 @@ (defun dired-mark-prompt (arg files) (defun dired-pop-to-buffer (buf) "Pop up buffer BUF in a way suitable for Dired." - (let ((split-window-preferred-function - (lambda (window) - (or (and (let ((split-height-threshold 0)) - (window-splittable-p (selected-window))) - ;; Try to split the selected window vertically if - ;; that's possible. (Bug#1806) - (split-window-below)) - ;; Otherwise, try to split WINDOW sensibly. - (split-window-sensibly window)))) - pop-up-frames) - (pop-to-buffer (get-buffer-create buf))) + (pop-to-buffer (get-buffer-create buf) '(display-buffer-pop-up-window-below)) ;; If dired-shrink-to-fit is t, make its window fit its contents. (when dired-shrink-to-fit ;; Try to not delete window when we want to display less than === modified file 'lisp/proced.el' --- lisp/proced.el 2011-08-24 18:09:18 +0000 +++ lisp/proced.el 2011-10-31 10:07:56 +0000 @@ -1730,8 +1730,7 @@ (defun proced-send-signal (&optional sig (save-window-excursion ;; Analogous to `dired-pop-to-buffer' ;; Don't split window horizontally. (Bug#1806) - (let (split-width-threshold) - (pop-to-buffer (current-buffer))) + (pop-to-buffer (current-buffer) '(display-buffer-pop-up-window-below)) (fit-window-to-buffer (get-buffer-window) nil 1) (let* ((completion-ignore-case t) (pnum (if (= 1 (length process-alist)) ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-31 10:11 ` Juri Linkov @ 2011-10-31 10:27 ` martin rudalics 2011-11-03 19:42 ` Juri Linkov 0 siblings, 1 reply; 22+ messages in thread From: martin rudalics @ 2011-10-31 10:27 UTC (permalink / raw) To: Juri Linkov; +Cc: Christoph Scholtes, Juanma Barranquero, 9873 > + pop-up-frames) There should be no need to bind this to nil. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-31 10:27 ` martin rudalics @ 2011-11-03 19:42 ` Juri Linkov 0 siblings, 0 replies; 22+ messages in thread From: Juri Linkov @ 2011-11-03 19:42 UTC (permalink / raw) To: martin rudalics; +Cc: Christoph Scholtes, Juanma Barranquero, 9873 >> + pop-up-frames) > > There should be no need to bind this to nil. I agree it's unnecessary. Below is a new patch without `pop-up-frames': === modified file 'lisp/window.el' --- lisp/window.el 2011-11-02 09:39:18 +0000 +++ lisp/window.el 2011-11-03 19:34:58 +0000 @@ -4853,6 +4853,23 @@ (defun display-buffer-pop-up-window (buf (set-window-prev-buffers window nil) window))) +(defun display-buffer-pop-up-window-below (buffer alist) + "Display BUFFER by popping up a new window below the selected window." + (let ( + ;; Stay within the confines of the initial window. + ;; Don't resize other windows. (Bug#1806 Bug#9873) + (window-nest t) + (split-window-preferred-function + (lambda (window) + (or (and (let ((split-height-threshold 0)) + (window-splittable-p (selected-window))) + ;; Try to split the selected window vertically if + ;; that's possible. (Bug#1806) + (split-window-below)) + ;; Otherwise, try to split WINDOW sensibly. + (split-window-sensibly window))))) + (display-buffer-pop-up-window buffer alist))) + (defun display-buffer--maybe-pop-up-frame-or-window (buffer alist) "Try displaying BUFFER based on `pop-up-frames' or `pop-up-windows'. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2011-10-27 9:53 ` martin rudalics 2011-10-28 8:12 ` Juri Linkov @ 2012-10-04 18:31 ` Juri Linkov 2012-10-04 18:51 ` martin rudalics 1 sibling, 1 reply; 22+ messages in thread From: Juri Linkov @ 2012-10-04 18:31 UTC (permalink / raw) To: martin rudalics; +Cc: 9873 >>> BTW this bug has been first described by Juri in Message#65 of Bug#1806. >> >> I see. Was there ever a conclusion reached? > > No. Martin, what about bug#9873, can it be closed now? ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2012-10-04 18:31 ` Juri Linkov @ 2012-10-04 18:51 ` martin rudalics 2012-10-04 19:40 ` Juri Linkov 0 siblings, 1 reply; 22+ messages in thread From: martin rudalics @ 2012-10-04 18:51 UTC (permalink / raw) To: Juri Linkov; +Cc: 9873 > Martin, what about bug#9873, can it be closed now? Hopefully. Interesting that you invented `display-buffer-pop-up-window-below' then. BTW, do we still have to fix proced.el? And what do we intend to do about these: > `Electric-pop-up-window', `ibuffer-confirm-operation-on', > `disabled-command-function', `proced-send-signal', > `fancy-startup-screen', `display-time-world', `widget-choose'. martin ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2012-10-04 18:51 ` martin rudalics @ 2012-10-04 19:40 ` Juri Linkov 2012-10-05 7:03 ` martin rudalics 0 siblings, 1 reply; 22+ messages in thread From: Juri Linkov @ 2012-10-04 19:40 UTC (permalink / raw) To: martin rudalics; +Cc: 9873-done >> Martin, what about bug#9873, can it be closed now? > > Hopefully. Bug closed. > BTW, do we still have to fix proced.el? > And what do we intend to do about these: > >> `Electric-pop-up-window', `ibuffer-confirm-operation-on', >> `disabled-command-function', `proced-send-signal', >> `fancy-startup-screen', `display-time-world', `widget-choose'. Eventually they should be fixed as well, but let's do this in a separate bug report. ^ permalink raw reply [flat|nested] 22+ messages in thread
* bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file 2012-10-04 19:40 ` Juri Linkov @ 2012-10-05 7:03 ` martin rudalics 0 siblings, 0 replies; 22+ messages in thread From: martin rudalics @ 2012-10-05 7:03 UTC (permalink / raw) To: Juri Linkov; +Cc: 9873-done > Eventually they should be fixed as well, but let's do this > in a separate bug report. I won't object ;-) martin ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2012-10-05 7:03 UTC | newest] Thread overview: 22+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-10-26 2:03 bug#9873: 24.0.90; dired - window changes size when trying to delete more than one file Christoph Scholtes 2011-10-26 2:16 ` Juanma Barranquero 2011-10-26 2:50 ` Christoph Scholtes 2011-10-26 2:52 ` Juanma Barranquero 2011-10-26 9:22 ` martin rudalics 2011-10-26 11:08 ` Eli Zaretskii 2011-10-26 14:22 ` martin rudalics 2011-10-26 18:30 ` Eli Zaretskii 2011-10-27 9:51 ` martin rudalics 2011-10-27 10:23 ` Eli Zaretskii 2011-10-27 13:15 ` martin rudalics 2011-10-27 3:39 ` Christoph Scholtes 2011-10-27 9:53 ` martin rudalics 2011-10-28 8:12 ` Juri Linkov 2011-10-28 17:16 ` martin rudalics 2011-10-31 10:11 ` Juri Linkov 2011-10-31 10:27 ` martin rudalics 2011-11-03 19:42 ` Juri Linkov 2012-10-04 18:31 ` Juri Linkov 2012-10-04 18:51 ` martin rudalics 2012-10-04 19:40 ` Juri Linkov 2012-10-05 7:03 ` martin rudalics
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).