bug#8862: compilation-window-height no good anymore

bug#8862: compilation-window-height no good anymore

[jidanni]

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.
I just was hoping to have a big window.

bug#8862: compilation-window-height no good anymore

[martin rudalics]

 > 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

bug#8862: compilation-window-height no good anymore

[Nix]

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)

bug#8862: compilation-window-height no good anymore

[martin rudalics]

 >> 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

bug#8862: compilation-window-height no good anymore

[Nix]

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)

bug#8862: compilation-window-height no good anymore

[jidanni]

>>>>> "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.

bug#8862: compilation-window-height no good anymore

[Stefan Monnier]

>>> 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

bug#8862: compilation-window-height no good anymore

[martin rudalics]

> 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

bug#8862: compilation-window-height no good anymore

[martin rudalics]

 > 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

bug#8862: compilation-window-height no good anymore

[jidanni]

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.

bug#8862: compilation-window-height no good anymore

[martin rudalics]

  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

bug#8862: compilation-window-height no good anymore

[jidanni]

>>>>> "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.

bug#8862: compilation-window-height no good anymore

[martin rudalics]

 > 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

bug#8862: compilation-window-height no good anymore

[jidanni]

>>>>> "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.

bug#8862: compilation-window-height no good anymore

[Stefan Monnier]

>> 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

bug#8862: compilation-window-height no good anymore

[martin rudalics]

 > 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

bug#8862: compilation-window-height no good anymore

[Stefan Monnier]

>> 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

bug#8862: compilation-window-height no good anymore

[martin rudalics]

 > 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

bug#8862: compilation-window-height no good anymore

[Glenn Morris]

Looks like the reported issue was resolved in this message:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8862#41

bug#8862: Stop compilation mode from splitting the window

[jidanni]

8862 is broken again.
Please tell me a way to stop compilation mode from splitting the window!

bug#8862: Stop compilation mode from splitting the window

[jidanni]

>>>>> "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.)

bug#8862: Stop compilation mode from splitting the window

[jidanni]

>>>>> "mr" == martin rudalics <rudalics@gmx.at> writes:
mr> Does ...
mr> work?
Yes! Thanks! Bye.