bug#16738: Errors while resizing vertically

bug#16738: Errors while resizing vertically

[E Sabof]

Another one without a clear recipe. I am using the following function on a fairly regular basis:

(defun es-maximize-window-vertically (&optional window)
    (interactive)
    (cl-callf window-normalize-window window)
    (unless (eq window (frame-root-window))
      (window-resize window (window-max-delta window))))

In combination with:

(setq window-min-height 1)

Sometimes it causes errors such as the ones below. In this state a) I can't resize any windows, using the above function. b) I can still resize using the mouse. c) Once I do, I usually can resize once with this function, but then I get a similar error again.

Evgeni

BACKTRACE1:

Debugger entered--Lisp error: (error "Cannot resize window #<window 128 on *Ack-and-a-half*>")
  signal(error ("Cannot resize window #<window 128 on *Ack-and-a-half*>"))
  error("Cannot resize window %s" #<window 128 on *Backtrace*>)
  window-resize(#<window 128 on *Backtrace*> 28)
  (if (eq window (frame-root-window)) nil (window-resize window (window-max-delta window)))
  es-maximize-window-vertically()
  call-interactively(es-maximize-window-vertically nil nil)
  command-execute(es-maximize-window-vertically)

BACKTRACE2

Debugger entered--Lisp error: (args-out-of-range -17 0 2147483647)
  set-window-new-pixel(#<window 299 on *mu4e-headers*> -17 t)
  window--resize-child-windows(#<window 301> -595 nil #<window 303 on *Backtrace*> nil nil nil nil)
  window--resize-siblings(#<window 303 on *Backtrace*> 595 nil nil)
  window-resize(#<window 303 on *Backtrace*> 35)
  (if (eq window (frame-root-window)) nil (window-resize window (window-max-delta window)))
  es-maximize-window-vertically()
  call-interactively(es-maximize-window-vertically nil nil)
  command-execute(es-maximize-window-vertically)

bug#16738: Errors while resizing vertically

[martin rudalics]

 > Debugger entered--Lisp error: (error "Cannot resize window #<window 128 on *Ack-and-a-half*>")
 >   signal(error ("Cannot resize window #<window 128 on *Ack-and-a-half*>"))
 >   error("Cannot resize window %s" #<window 128 on *Backtrace*>)
 >   window-resize(#<window 128 on *Backtrace*> 28)
 >   (if (eq window (frame-root-window)) nil (window-resize window (window-max-delta window)))
 >   es-maximize-window-vertically()
 >   call-interactively(es-maximize-window-vertically nil nil)
 >   command-execute(es-maximize-window-vertically)

I can easily reproduce such an error here.  Do you have a boxed mode- or
header-line, or anything that makes these lines higher or lower than an
average normal line?

I'll check in a fix for this soon, but I still see a related bug whose
cause I wasn't able to identify yet.

 > BACKTRACE2
 >
 > Debugger entered--Lisp error: (args-out-of-range -17 0 2147483647)
 >   set-window-new-pixel(#<window 299 on *mu4e-headers*> -17 t)
 >   window--resize-child-windows(#<window 301> -595 nil #<window 303 on *Backtrace*> nil nil nil nil)
 >   window--resize-siblings(#<window 303 on *Backtrace*> 595 nil nil)
 >   window-resize(#<window 303 on *Backtrace*> 35)
 >   (if (eq window (frame-root-window)) nil (window-resize window (window-max-delta window)))
 >   es-maximize-window-vertically()
 >   call-interactively(es-maximize-window-vertically nil nil)
 >   command-execute(es-maximize-window-vertically)

This sounds strange.  Paul, how can such a thing happen?

martin

bug#16738: Errors while resizing vertically

[E Sabof]

> I can easily reproduce such an error here.  Do you have a boxed mode- or
> header-line, or anything that makes these lines higher or lower than an
> average normal line?

My header-line has an overline + underline, which apparently make the face 2 pixels higher. I might also have been using non-standard size font-lock faces.

Evgeni

bug#16738: Errors while resizing vertically

[martin rudalics]

> My header-line has an overline + underline, which apparently make the face 2 pixels higher. I might also have been using non-standard size font-lock faces.

This explains it.  You shouldn't see the bug with "normal" header-
and mode-lines.

martin

bug#16738: Errors while resizing vertically

[martin rudalics]

> Another one without a clear recipe. I am using the following function on a fairly regular basis:
> 
> (defun es-maximize-window-vertically (&optional window)
>     (interactive)
>     (cl-callf window-normalize-window window)
>     (unless (eq window (frame-root-window))
>       (window-resize window (window-max-delta window))))
> 
> In combination with:
> 
> (setq window-min-height 1)
> 
> Sometimes it causes errors such as the ones below. In this state a) I can't resize any windows, using the above function. b) I can still resize using the mouse. c) Once I do, I usually can resize once with this function, but then I get a similar error again.
> 
> Evgeni
> 
> BACKTRACE1:
> 
> Debugger entered--Lisp error: (error "Cannot resize window #<window 128 on *Ack-and-a-half*>")
>   signal(error ("Cannot resize window #<window 128 on *Ack-and-a-half*>"))
>   error("Cannot resize window %s" #<window 128 on *Backtrace*>)
>   window-resize(#<window 128 on *Backtrace*> 28)
>   (if (eq window (frame-root-window)) nil (window-resize window (window-max-delta window)))
>   es-maximize-window-vertically()
>   call-interactively(es-maximize-window-vertically nil nil)
>   command-execute(es-maximize-window-vertically)

Hopefully fixed with revision 116504 on trunk.  Please try again.

martin

bug#16738: Errors while resizing vertically

[martin rudalics]

 >  > Debugger entered--Lisp error: (args-out-of-range -17 0 2147483647)
 >  >   set-window-new-pixel(#<window 299 on *mu4e-headers*> -17 t)
 >  >   window--resize-child-windows(#<window 301> -595 nil #<window 303 on
 > *Backtrace*> nil nil nil nil)
 >  >   window--resize-siblings(#<window 303 on *Backtrace*> 595 nil nil)
 >  >   window-resize(#<window 303 on *Backtrace*> 35)
 >  >   (if (eq window (frame-root-window)) nil (window-resize window
 > (window-max-delta window)))
 >  >   es-maximize-window-vertically()
 >  >   call-interactively(es-maximize-window-vertically nil nil)
 >  >   command-execute(es-maximize-window-vertically)
 >
 > This sounds strange.  Paul, how can such a thing happen?

Paul Eggert - this was your change:

	Minor integer overflow fixes (Bug#16033).
	* window.c (Fset_window_new_pixel): Don't let new_pixel go negative.
	This improves on the previous fix to this function.

martin

bug#16738: Errors while resizing vertically

[Paul Eggert]

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

My change adjusted set-window-new-pixel so that it rejects attempts to 
set the new pixel size to a negative value. Here, new-pixel is currently 
0, so (set-window-new-pixel window-17 t) is attempting to change 
new-pixel to be -17.

Are negative new-pixel values allowed?  If so, the attached patch should 
fix the problem.  If not, the problem's probably in the caller.



[-- Attachment #2: newpixel.diff --]
[-- Type: text/x-patch, Size: 674 bytes --]

=== modified file 'src/window.c'
--- src/window.c	2014-02-21 08:02:05 +0000
+++ src/window.c	2014-02-21 20:25:41 +0000
@@ -3702,8 +3702,9 @@
   (Lisp_Object window, Lisp_Object size, Lisp_Object add)
 {
   struct window *w = decode_valid_window (window);
-  EMACS_INT size_min = NILP (add) ? 0 : - XINT (w->new_pixel);
-  EMACS_INT size_max = size_min + min (INT_MAX, MOST_POSITIVE_FIXNUM);
+  EMACS_INT new_pixel = NILP (add) ? 0 : XINT (w->new_pixel);
+  EMACS_INT size_min = max (INT_MIN, MOST_NEGATIVE_FIXNUM) - new_pixel;
+  EMACS_INT size_max = min (INT_MAX, MOST_POSITIVE_FIXNUM) - new_pixel;
 
   CHECK_RANGED_INTEGER (size, size_min, size_max);
   if (NILP (add))

bug#16738: Errors while resizing vertically

[martin rudalics]

 > My change adjusted set-window-new-pixel so that it rejects attempts to
 > set the new pixel size to a negative value. Here, new-pixel is currently
 > 0, so (set-window-new-pixel window-17 t) is attempting to change
 > new-pixel to be -17.

Indeed.  Storing a negative pixel value is an error.

 > Are negative new-pixel values allowed?  If so, the attached patch should
 > fix the problem.  If not, the problem's probably in the caller.

There was a bug in the caller - hopefully fixed now.  No further action
needed from your side.

Thanks, martin

bug#16738: Errors while resizing vertically

[E Sabof]

I've tried the new code. With the following:

(setq window-min-height 1)
(set-face-attribute 'mode-line nil :overline "black")

,I'm unable to make windows any shorter than 2.

Evgeni

bug#16738: Errors while resizing vertically

[martin rudalics]

 > I've tried the new code. With the following:
 >
 > (setq window-min-height 1)
 > (set-face-attribute 'mode-line nil :overline "black")
 >
 > ,I'm unable to make windows any shorter than 2.

2 canonical lines.  But this is to be expected?  Otherwise, Emacs would
truncate the text line by the extra pixels needed for the mode line.

Whenever using a non-standard sized mode- or header-line _and_ a small
window-min-height/-width I recommend setting `window-resize-pixelwise'
to t.

martin

bug#16738: Errors while resizing vertically

[E Sabof]

martin rudalics <rudalics@gmx.at> writes:

> 2 canonical lines.  But this is to be expected?  Otherwise, Emacs would
> truncate the text line by the extra pixels needed for the mode line.

The finer details of pixel and character coexistence on graphical frames tend escape me. If I encounter any more errors, I will report them.

Evgeni

bug#16738: Errors while resizing vertically

[martin rudalics]

 >> 2 canonical lines.  But this is to be expected?  Otherwise, Emacs would
 >> truncate the text line by the extra pixels needed for the mode line.
 >
 > The finer details of pixel and character coexistence on graphical frames tend escape me. If I encounter any more errors, I will report them.

Suppose you have a canonical character height of 8 pixels and a header
and a mode line with 2 additional pixels each.  If you now set
`window-min-height' to 1, Emacs will display a text line of 4 pixels
height if we do not round appropriately.  That wouldn't look good.

martin

bug#16738: Errors while resizing vertically

[martin rudalics]

> Hopefully fixed with revision 116504 on trunk.  Please try again.

Closing.

martin