* bug#8862: compilation-window-height no good anymore
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
@ 2011-06-14 17:14 ` martin rudalics
2011-06-14 18:32 ` Nix
2011-06-14 23:50 ` jidanni
` (6 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-06-14 17:14 UTC (permalink / raw)
To: jidanni; +Cc: 8862
> I used to have
> setq compilation-window-height 111
> in my .emacs, but starting this week, I get a cannot resize window error
> upon M-x compiles.
Same here.
> I just was hoping to have a big window.
By default `compile' tries to split off a window for the compilation
buffer and, when faced with the problem to make that window 111 lines
high, calls `enlarge-window' which, with the old behavior, automatically
deleted all other windows on your frame and then used the remaining big
window (but not 111 lines even on your screen, I suppose;-)).
In the current version, windows are no longer deleted automatically. So
when you want to make a window that's too large to fit onto the frame in
question (respecting the minimumm heights of other windows on the frame)
Emacs issues an error message.
If you really want one big window for your compilation buffer, you
should create an entry in `display-buffer-alist' (I know you don't like
it but I recommend to use the customization interface when doing this
for the first time) which might look like
(((name . "*compilation*")) (reuse-window same nil nil))
telling the buffer display mechanism to simply use the selected window
for displaying the buffer (and not split the window as it would do by
default). If you want a more sophisticated behavior, please tell me.
martin
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-14 17:14 ` martin rudalics
@ 2011-06-14 18:32 ` Nix
2011-06-14 19:08 ` martin rudalics
0 siblings, 1 reply; 23+ messages in thread
From: Nix @ 2011-06-14 18:32 UTC (permalink / raw)
To: martin rudalics; +Cc: 8862, jidanni
On 14 Jun 2011, martin rudalics spake thusly:
> In the current version, windows are no longer deleted automatically.
Isn't this a very large backward-compatibility and user-expectations
break?
--
NULL && (void)
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-14 18:32 ` Nix
@ 2011-06-14 19:08 ` martin rudalics
2011-06-14 19:11 ` Nix
2011-06-15 3:15 ` Stefan Monnier
0 siblings, 2 replies; 23+ messages in thread
From: martin rudalics @ 2011-06-14 19:08 UTC (permalink / raw)
To: Nix; +Cc: 8862, jidanni
>> In the current version, windows are no longer deleted automatically.
>
> Isn't this a very large backward-compatibility and user-expectations
> break?
Hopefully not. There were a number of complaints that Emacs deleted
windows automatically during resizing. When a similar change was
applied to `adjust-window-trailing-edge' for Emacs 22 hardly anyone
complained.
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-14 19:08 ` martin rudalics
@ 2011-06-14 19:11 ` Nix
2011-06-15 3:15 ` Stefan Monnier
1 sibling, 0 replies; 23+ messages in thread
From: Nix @ 2011-06-14 19:11 UTC (permalink / raw)
To: martin rudalics; +Cc: 8862, jidanni
On 14 Jun 2011, martin rudalics stated:
>>> In the current version, windows are no longer deleted automatically.
>>
>> Isn't this a very large backward-compatibility and user-expectations
>> break?
>
> Hopefully not. There were a number of complaints that Emacs deleted
> windows automatically during resizing. When a similar change was
> applied to `adjust-window-trailing-edge' for Emacs 22 hardly anyone
> complained.
OK, that's fine then :) I'm not concerned about breakage to packages
so much -- they can be fixed, and in the past have been -- but user
expectations are a hard thing to reprogram.
(Your window management changes are really nice codewise, don't let my
carping from the sidelines stop you revamping things!)
--
NULL && (void)
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-14 19:08 ` martin rudalics
2011-06-14 19:11 ` Nix
@ 2011-06-15 3:15 ` Stefan Monnier
2011-06-15 9:09 ` martin rudalics
1 sibling, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2011-06-15 3:15 UTC (permalink / raw)
To: martin rudalics; +Cc: 8862, jidanni
>>> In the current version, windows are no longer deleted automatically.
>> Isn't this a very large backward-compatibility and user-expectations
>> break?
> Hopefully not. There were a number of complaints that Emacs deleted
> windows automatically during resizing.
Yes, being less eager to delete windows is good. But why signal an
error rather than just make the window as big as possible without
deleting surrounding windows?
> When a similar change was applied to `adjust-window-trailing-edge' for
> Emacs 22 hardly anyone complained.
Not sure what you're referring to: adjust-window-trailing-edge was a new
function in Emacs-22.
Stefan
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-15 3:15 ` Stefan Monnier
@ 2011-06-15 9:09 ` martin rudalics
2011-06-15 14:09 ` Stefan Monnier
0 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-06-15 9:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8862, jidanni
> Yes, being less eager to delete windows is good. But why signal an
> error rather than just make the window as big as possible without
> deleting surrounding windows?
I can do that for `enlarge-window' (and do a corresponding thing for
`shrink-window'). I can do that for the lower level function
`resize-window' (aka `window-resize') as well but wouldn't we rather
like to catch a failure here? Also what about an attempt to enlarge or
shrink the root window of a frame? Should we avoid signalling an error
here too?
>> When a similar change was applied to `adjust-window-trailing-edge' for
>> Emacs 22 hardly anyone complained.
>
> Not sure what you're referring to: adjust-window-trailing-edge was a new
> function in Emacs-22.
I meant the functionality of `adjust-window-trailing-edge'. Before that
change mouse dragging an edge could delete windows and after that change
not.
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-15 9:09 ` martin rudalics
@ 2011-06-15 14:09 ` Stefan Monnier
2011-06-15 14:51 ` martin rudalics
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2011-06-15 14:09 UTC (permalink / raw)
To: martin rudalics; +Cc: 8862, jidanni
>> Yes, being less eager to delete windows is good. But why signal an
>> error rather than just make the window as big as possible without
>> deleting surrounding windows?
> I can do that for `enlarge-window' (and do a corresponding thing for
> `shrink-window').
AFAIK, `enlarge-window' did not signal an error when the size was too
large, so I think it's best to keep being silent, for backward
compatibility's sake.
> I can do that for the lower level function
> `resize-window' (aka `window-resize') as well but wouldn't we rather
Signalling an error is a good thing, wo while we shouldn't do it for
enlarge-window for compatibility reasons, we should do it for the
new functions like window-resize.
> I meant the functionality of `adjust-window-trailing-edge'.
> Before that change mouse dragging an edge could delete windows and
> after that change not.
Such changes to interactive behavior are much less problematic than
changes in non-interactive functions, since the first might at worst
surprise or disappoint the user, while the second can
break functionality.
Stefan
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-15 14:09 ` Stefan Monnier
@ 2011-06-15 14:51 ` martin rudalics
2011-06-15 15:38 ` Stefan Monnier
0 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-06-15 14:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8862, jidanni
> AFAIK, `enlarge-window' did not signal an error when the size was too
> large, so I think it's best to keep being silent, for backward
> compatibility's sake.
OK. I'll use the maximum possible height for enlarging and
window-min-height/-width for shrinking. The only cases where I signal
an error are when the window is either fixed-size or the root window.
> Signalling an error is a good thing, wo while we shouldn't do it for
> enlarge-window for compatibility reasons, we should do it for the
> new functions like window-resize.
Good.
> Such changes to interactive behavior are much less problematic than
> changes in non-interactive functions, since the first might at worst
> surprise or disappoint the user, while the second can
> break functionality.
Agreed. I tend to discourage using `enlarge-window' in ELisp because it
only works on the selected window leading to things like compile.el's
;; Stef said that doing the saves in this order is safer:
(save-excursion
(save-selected-window
(select-window window)
(enlarge-window (- height (window-height))))))))
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-15 14:51 ` martin rudalics
@ 2011-06-15 15:38 ` Stefan Monnier
2011-06-15 15:56 ` martin rudalics
0 siblings, 1 reply; 23+ messages in thread
From: Stefan Monnier @ 2011-06-15 15:38 UTC (permalink / raw)
To: martin rudalics; +Cc: 8862, jidanni
>> AFAIK, `enlarge-window' did not signal an error when the size was too
>> large, so I think it's best to keep being silent, for backward
>> compatibility's sake.
> OK. I'll use the maximum possible height for enlarging and
> window-min-height/-width for shrinking. The only cases where I signal
> an error are when the window is either fixed-size or the root window.
In Emacs-23, enlarge-window called on the root window doesn't seem to
signal an error either. Maybe you'll be lucky and won't bump into bugs
resulting from such a change, but I think you'd be safer keeping the old
non-signaling behavior.
After all, you don't like enlarge-window anyway and can't really change
it into something you like, so you may as well keep it unchanged and
deprecate it in favor of something you like better.
> Agreed. I tend to discourage using `enlarge-window' in ELisp because it
> only works on the selected window leading to things like compile.el's
> ;; Stef said that doing the saves in this order is safer:
> (save-excursion
> (save-selected-window
> (select-window window)
> (enlarge-window (- height (window-height))))))))
Hmm... not sure why it doesn't use with-selected-window, but yes,
providing a `window' argument is even better.
Stefan
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-15 15:38 ` Stefan Monnier
@ 2011-06-15 15:56 ` martin rudalics
0 siblings, 0 replies; 23+ messages in thread
From: martin rudalics @ 2011-06-15 15:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8862, jidanni
> In Emacs-23, enlarge-window called on the root window doesn't seem to
> signal an error either.
Horizontally only. Try (enlarge-window 4 t) with a one-window frame.
> Maybe you'll be lucky and won't bump into bugs
> resulting from such a change, but I think you'd be safer keeping the old
> non-signaling behavior.
OK.
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
2011-06-14 17:14 ` martin rudalics
@ 2011-06-14 23:50 ` jidanni
2011-06-15 9:08 ` martin rudalics
2011-06-15 11:46 ` jidanni
` (5 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: jidanni @ 2011-06-14 23:50 UTC (permalink / raw)
To: rudalics; +Cc: 8862
>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
mr> (((name . "*compilation*")) (reuse-window same nil nil))
Please tell me the exact lines I should put in what exact file. I cannot
use the customization interface. Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-14 23:50 ` jidanni
@ 2011-06-15 9:08 ` martin rudalics
0 siblings, 0 replies; 23+ messages in thread
From: martin rudalics @ 2011-06-15 9:08 UTC (permalink / raw)
To: jidanni; +Cc: 8862
> mr> (((name . "*compilation*")) (reuse-window same nil nil))
> Please tell me the exact lines I should put in what exact file. I cannot
> use the customization interface. Thanks.
Does it work if you put
(setq display-buffer-alist
(cons '(((name . "*compilation*")) (reuse-window same nil t))
display-buffer-alist))
into your .emacs?
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
2011-06-14 17:14 ` martin rudalics
2011-06-14 23:50 ` jidanni
@ 2011-06-15 11:46 ` jidanni
2011-06-15 12:57 ` martin rudalics
2011-06-15 13:10 ` jidanni
` (4 subsequent siblings)
7 siblings, 1 reply; 23+ messages in thread
From: jidanni @ 2011-06-15 11:46 UTC (permalink / raw)
To: rudalics; +Cc: 8862
mr> Does it work if you put
mr> (setq display-buffer-alist
mr> (cons '(((name . "*compilation*")) (reuse-window same nil t))
mr> display-buffer-alist))
mr> into your .emacs?
No it does not.
I want the compilation buffer to take up my entire screen.
That line does not do that. I just tried it.
I want to say M-x compile ... and the new buffer should then take up the
entire screen.
Please give me the right line.
Please implement something like
(setq Man-notify-method 'bully)
Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-15 11:46 ` jidanni
@ 2011-06-15 12:57 ` martin rudalics
2011-06-15 13:28 ` martin rudalics
0 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-06-15 12:57 UTC (permalink / raw)
To: jidanni; +Cc: 8862
I want to say M-x compile ... and the new buffer should then take up the
> entire screen.
So your use case is that you have more than one window on your screen
but when you invoke compile you just want to have one window? Try the
following:
(setq display-buffer-alist
(cons '(((name . "*compilation*"))
(fun-with-args
(lambda (buffer &rest args)
(delete-other-windows)
(display-buffer buffer 'same-window))))
display-buffer-alist))
You might have to adjust the name if that of your compilation buffer is
not *compilation*.
martin
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-15 12:57 ` martin rudalics
@ 2011-06-15 13:28 ` martin rudalics
2011-07-15 22:47 ` Glenn Morris
0 siblings, 1 reply; 23+ messages in thread
From: martin rudalics @ 2011-06-15 13:28 UTC (permalink / raw)
To: jidanni; +Cc: 8862
> Well it certainly isn't,
>
> %* *compilation /home/jidanni/* 174 Compilation:exit
> %* *compilation /cf/updates/* 184 Compilation:exit
Aha. In this case you probably need something like
(setq display-buffer-alist
(cons '(((regexp . "\\*compilation.+\\*"))
(fun-with-args
(lambda (buffer &rest args)
(delete-other-windows)
(display-buffer buffer 'same-window))))
display-buffer-alist))
martin
^ permalink raw reply [flat|nested] 23+ messages in thread
* bug#8862: compilation-window-height no good anymore
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
` (2 preceding siblings ...)
2011-06-15 11:46 ` jidanni
@ 2011-06-15 13:10 ` jidanni
2011-06-15 13:43 ` jidanni
` (3 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: jidanni @ 2011-06-15 13:10 UTC (permalink / raw)
To: rudalics; +Cc: 8862
>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
mr> You might have to adjust the name if that of your compilation buffer is
mr> not *compilation*.
Well it certainly isn't,
%* *compilation /home/jidanni/* 174 Compilation:exit
%* *compilation /cf/updates/* 184 Compilation:exit
As I seem to use
(defun jidanni-compilation-buffer-name-function (maj-mode)
"my buffer name individualizer. Helps me not to stomp forgotten
compilation logs so fast... maybe upon exiting emacs, we should also
somehow ask about compilation buffers that we haven't taken a look at
after their compilation finished."
(concat "*" (downcase maj-mode) " "
;(file-name-nondirectory default-directory....) ;too bad I don't know how
;to do an exact replica of "basname `pwd`" but in lisp. So I guess
;I'll have to settle for
default-directory
"*"))
(setq compilation-buffer-name-function
'jidanni-compilation-buffer-name-function)
etc. from http://jidanni.org/comp/configuration/
So now what?
It seems your stuff isn't as dynamic as it should be.
Maybe I should put something in a hook to max out the window.
Well I bet I used to do that long ago.
Then they made some new way, and I followed that.
Anyway it is all in
http://jidanni.org/comp/configuration/
just waiting for you to give me the 2011 year's solution.
Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: compilation-window-height no good anymore
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
` (3 preceding siblings ...)
2011-06-15 13:10 ` jidanni
@ 2011-06-15 13:43 ` jidanni
2011-07-24 15:07 ` bug#8862: Stop compilation mode from splitting the window jidanni
` (2 subsequent siblings)
7 siblings, 0 replies; 23+ messages in thread
From: jidanni @ 2011-06-15 13:43 UTC (permalink / raw)
To: rudalics; +Cc: 8862
>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
mr> Aha. In this case you probably need something like
mr> (setq display-buffer-alist
mr> (cons '(((regexp . "\\*compilation.+\\*"))
OK, thanks. I am back in business.
So the fate of this bug report is now up to you guys. Thanks.
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: Stop compilation mode from splitting the window
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
` (4 preceding siblings ...)
2011-06-15 13:43 ` jidanni
@ 2011-07-24 15:07 ` jidanni
2011-07-24 15:34 ` jidanni
2011-07-25 1:14 ` jidanni
7 siblings, 0 replies; 23+ messages in thread
From: jidanni @ 2011-07-24 15:07 UTC (permalink / raw)
To: rudalics, monnier; +Cc: help-gnu-emacs, 8862
8862 is broken again.
Please tell me a way to stop compilation mode from splitting the window!
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: Stop compilation mode from splitting the window
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
` (5 preceding siblings ...)
2011-07-24 15:07 ` bug#8862: Stop compilation mode from splitting the window jidanni
@ 2011-07-24 15:34 ` jidanni
2011-07-25 1:14 ` jidanni
7 siblings, 0 replies; 23+ messages in thread
From: jidanni @ 2011-07-24 15:34 UTC (permalink / raw)
To: david.belohrad; +Cc: help-gnu-emacs, 8862
>>>>> "DB" == David Belohrad <david.belohrad@cern.ch> writes:
DB> I use something like this to close compilation window if no error during compilation was
DB> found. This however does not preserve the frame configuration
DB> (setq compilation-finish-function
DB> (lambda (buf str)
DB> (if (or (string-match "warning:" str) (string-match "exited abnormally" str)
DB> (string-match "compilation aborted" str))
DB> ;;there were errors
DB> (message "compilation errors or warnings, press C-x ` to visit")
DB> ;;no errors, make the compilation window go away in 0.5 seconds
DB> (run-at-time 0.5 nil 'delete-windows-on buf)
DB> (message "NO COMPILATION ERRORS!"))))
OK, but one would think the emacs maintainers might be charitable to
provide a variable to just not split the window in half in the first
place (so I can see the whole window of juicy compilation action.)
^ permalink raw reply [flat|nested] 23+ messages in thread* bug#8862: Stop compilation mode from splitting the window
2011-06-14 15:03 ` bug#8862: compilation-window-height no good anymore jidanni
` (6 preceding siblings ...)
2011-07-24 15:34 ` jidanni
@ 2011-07-25 1:14 ` jidanni
7 siblings, 0 replies; 23+ messages in thread
From: jidanni @ 2011-07-25 1:14 UTC (permalink / raw)
To: rudalics; +Cc: help-gnu-emacs, 8862
>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
mr> Does ...
mr> work?
Yes! Thanks! Bye.
^ permalink raw reply [flat|nested] 23+ messages in thread