bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

I cannot use the latest Emacs build at all.  I extensively use thumbnail
frames, which are tiny frames, fully functional, made by shrinking the
frame's font size.  FWIW, this is very important to me.

The code is here:
http://www.emacswiki.org/emacs-en/download/thumb-frm.el
http://www.emacswiki.org/emacs-en/download/frame-cmds.el
http://www.emacswiki.org/emacs-en/download/frame-fns.el

The code is simple.  But presumably you need not examine it.  Just
please, ASAP, restore the link between font size and frame size.

Now, when I hit C-z to thumbify a frame, the font is shrunk, but the
frame is not shrunk accordingly.

The core of the code is this:

(defun enlarge-font (&optional increment frame)
  "Increase size of font in FRAME by INCREMENT.
Interactively, INCREMENT is given by the prefix argument.
Optional FRAME parameter defaults to current frame."
  (interactive "p")
  (setq frame  (or frame  (selected-frame)))
  (let ((fontname  (cdr (assq 'font (frame-parameters frame))))
        (count     enlarge-font-tries))
    (setq fontname  (enlarged-font-name fontname frame increment))
    (while (and (not (x-list-fonts fontname))
                (wholenump (setq count  (1- count))))
      (setq fontname  (enlarged-font-name fontname frame increment)))
    (unless (x-list-fonts fontname) (error "Cannot change font size"))
    (modify-frame-parameters frame (list (cons 'font fontname)))
    ;; Update faces that want a bold or italic version of the default font.
    (when (< emacs-major-version 21) (frame-update-faces frame))))

(defun enlarged-font-name (fontname frame increment)
  "FONTNAME, after enlarging font size of FRAME by INCREMENT.
FONTNAME is the font of FRAME."
  (when (query-fontset fontname)
    (let ((ascii  (assq 'ascii (aref (fontset-info fontname frame) 2))))
      (when ascii (setq fontname  (nth 2 ascii)))))
  (let ((xlfd-fields  (x-decompose-font-name fontname)))
    (unless xlfd-fields (error "Cannot decompose font name"))
    (let ((new-size  (+ (string-to-number
                         (aref xlfd-fields xlfd-regexp-pixelsize-subnum))
                        increment)))
      (unless (> new-size 0) (signal 'font-too-small (list new-size)))
      (aset xlfd-fields xlfd-regexp-pixelsize-subnum
            (number-to-string new-size)))
    ;; Set point size & width to "*", so frame width adjusts to new font
    (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
    (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
    (x-compose-font-name xlfd-fields)))

Though not needed to see the problem, here is the thumbify code that
makes use of `enlarge-font':

(defun thumfr-thumbify-frame (&optional frame)
  "Create a thumbnail version of FRAME (default: selected frame).
Variable `thumfr-frame-parameters' is used to determine
which frame parameters (such as `menu-bar-lines') to remove."
  (interactive)
  (setq frame  (or frame (selected-frame)))
  (let* ((tf-params      (frame-parameter frame 'thumfr-non-thumbnail-frame))
         (non-tf-params  (thumfr-remove-if #'thumfr-thumfr-parameter-p
                                           (frame-parameters frame))))
    (when thumfr-rename-when-thumbify-flag (rename-non-minibuffer-frame))
    (unless (frame-parameter frame 'thumfr-thumbnail-frame) ; No-op if already a thumbnail.
      (set-frame-parameter frame 'thumfr-thumbnail-frame     non-tf-params)
      (set-frame-parameter frame 'thumfr-non-thumbnail-frame nil)
      (condition-case thumfr-thumbify-frame
          (progn
            (enlarge-font (- thumfr-font-difference) frame) ; In `frame-cmds.el'.
            (when tf-params (modify-frame-parameters frame tf-params))
            (when thumfr-next-stack-xoffset
              (set-frame-position frame thumfr-next-stack-xoffset
                                  thumfr-next-stack-yoffset)
              (setq thumfr-next-stack-xoffset  nil
                    thumfr-next-stack-yoffset  nil))
            (modify-frame-parameters frame thumfr-frame-parameters))
        (font-too-small                 ; Try again, with a larger font.
         (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
         (set-frame-parameter frame 'thumfr-thumbnail-frame     nil)
         (unless (> thumfr-font-difference 0)
           (error (error-message-string thumfr-thumbify-frame)))
         (let ((thumfr-font-difference  (1- thumfr-font-difference)))
           (thumfr-thumbify-frame frame)))
        (error
         (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
         (set-frame-parameter frame 'thumfr-thumbnail-frame     nil)
         (error (error-message-string thumfr-thumbify-frame)))))))    

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-01 on ODIEONE
Bzr revision: 115342 eggert@cs.ucla.edu-20131201223313-xvgrjlk0r9aiakes
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' CPPFLAGS=-Ic:/Devel/emacs/include
 LDFLAGS=-Lc:/Devel/emacs/lib'

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

Should have added: This regression occurred between a build from
2013/11/18 and a build from 2013/12/02.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > I cannot use the latest Emacs build at all.  I extensively use thumbnail
 > frames, which are tiny frames, fully functional, made by shrinking the
 > frame's font size.  FWIW, this is very important to me.

Sorry, I didn't intend to break that.  I'll look into this as soon as I
have time.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > I cannot use the latest Emacs build at all.  I extensively use thumbnail
>  > frames, which are tiny frames, fully functional, made by shrinking the
>  > frame's font size.  FWIW, this is very important to me.
> 
> Sorry, I didn't intend to break that.  I'll look into this as soon as I
> have time.

Don't be sorry.  Take your time.  And thank you very much for wanting
to fix this.  I really appreciate it.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> Sorry, I didn't intend to break that.  I'll look into this as soon as I
> have time.

Should be fixed now with revision 115383 on trunk.

Could the kind soul providing Drew with binaries upload a new build
so he may continue his frame bug tests ?

Thanks, martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> Should be fixed now with revision 115383 on trunk.
> 
> Could the kind soul providing Drew with binaries upload a new build
> so he may continue his frame bug tests ?

Excellent - I'll give it a try.

Thanks, to you Martin and to all the other kind souls.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> > Should be fixed now with revision 115383 on trunk.
> 
> Excellent - I'll give it a try.

Unfortunately, it doesn't help.  Exactly the same broken
behavior, I'm afraid.

I tested using this build from Juanma:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-05 on ODIEONE
Bzr revision: 115389 monnier@iro.umontreal.ca-20131205202554-1az0dm7bdk303bgw
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' CPPFLAGS=-Ic:/Devel/emacs/include
 LDFLAGS=-Lc:/Devel/emacs/lib'

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Unfortunately, it doesn't help.  Exactly the same broken
 > behavior, I'm afraid.
 >
 > I tested using this build from Juanma:
 >
 > In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 >  of 2013-12-05 on ODIEONE
 > Bzr revision: 115389 monnier@iro.umontreal.ca-20131205202554-1az0dm7bdk303bgw

Then we have to dig into this further.  Let's stick to this simple
example (where `enlarged-font-name' is just yours):


(defun enlarged-font-name (fontname frame increment)
   "FONTNAME, after enlarging font size of FRAME by INCREMENT.
FONTNAME is the font of FRAME."
   (when (query-fontset fontname)
     (let ((ascii  (assq 'ascii (aref (fontset-info fontname frame) 2))))
       (when ascii (setq fontname  (nth 2 ascii)))))
   (let ((xlfd-fields  (x-decompose-font-name fontname)))
     (unless xlfd-fields (error "Cannot decompose font name"))
     (let ((new-size  (+ (string-to-number
                          (aref xlfd-fields xlfd-regexp-pixelsize-subnum))
                         increment)))
       (unless (> new-size 0) (signal 'font-too-small (list new-size)))
       (aset xlfd-fields xlfd-regexp-pixelsize-subnum
             (number-to-string new-size)))
     ;; Set point size & width to "*", so frame width adjusts to new font
     (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
     (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
     (x-compose-font-name xlfd-fields)))

(defun enlarge-font-by (increment)
   (let* ((old-size (cons (frame-width) (frame-height)))
	 (old-pixel-size (cons (frame-pixel-width) (frame-pixel-height)))
	 (old-font (cdr (assq 'font (frame-parameters (selected-frame)))))
	 (new-font (enlarged-font-name old-font (selected-frame) increment)))
     (modify-frame-parameters (selected-frame) (list (cons 'font new-font)))
     (sit-for 0)
     (with-current-buffer (get-buffer-create "*temp*")
       (goto-char (point-max))
       (insert (format "%s %s %s ->\n%s %s %s\n\n"
		      old-font old-size old-pixel-size new-font
		      (cons (frame-width) (frame-height))
		      (cons (frame-pixel-width) (frame-pixel-height)))))))

;; (eval-buffer)
;; (enlarge-font-by 4)
;; (enlarge-font-by -4)
;; (enlarge-font-by -4)
;; (enlarge-font-by 0)
;; (enlarge-font-by 4)


With emacs -Q evaluating the commented out rows in sequence gets me in *temp*:

-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608) ->
-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 38) (836 . 760)

-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 38) (836 . 760) ->
-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608)

-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608) ->
-outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456)

-outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456) ->
-outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456)

-outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456) ->
-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608)


The sit-for is needed for getting the right new pixel values, the
resizing effect is the same when I comment it out.  What do you get
here?

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Fri, 06 Dec 2013 09:20:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> Cc: 16028@debbugs.gnu.org
> 
> ;; (enlarge-font-by 4)
> ;; (enlarge-font-by -4)
> ;; (enlarge-font-by -4)
> ;; (enlarge-font-by 0)
> ;; (enlarge-font-by 4)
> 
> 
> With emacs -Q evaluating the commented out rows in sequence gets me in *temp*:
> 
> -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608) ->
> -outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 38) (836 . 760)
> 
> -outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 38) (836 . 760) ->
> -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608)
> 
> -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608) ->
> -outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456)
> 
> -outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456) ->
> -outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456)
> 
> -outline-Courier New-normal-normal-normal-mono-9-*-*-*-c-*-iso8859-1 (80 . 38) (436 . 456) ->
> -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 38) (672 . 608)
> 
> 
> The sit-for is needed for getting the right new pixel values, the
> resizing effect is the same when I comment it out.  What do you get
> here?

Perhaps the real-life thumbnail-mode does something to restore the
frame dimensions, thus countermanding the effect of making the font
smaller?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Perhaps the real-life thumbnail-mode does something to restore the
 > frame dimensions, thus countermanding the effect of making the font
 > smaller?

Maybe.  But then `enlarge-font' isn't of much use in this context.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> What do you get here?

;; (enlarge-font-by 4)

-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740) ->
-outline-Courier New-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1 (80 . 37) (1087 . 851)

;; (enlarge-font-by -4)

-outline-Courier New-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1 (80 . 37) (1087 . 851) ->
-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740)

;; (enlarge-font-by -4)

-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740) ->
-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592)

;; (enlarge-font-by 0)

-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592) ->
-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592)

;; (enlarge-font-by 4)

-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592) ->
-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740)

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> What do you get here?
 >
 > ;; (enlarge-font-by 4)
 >
 > -outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740) ->
 > -outline-Courier New-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1 (80 . 37) (1087 . 851)
 >
 > ;; (enlarge-font-by -4)
 >
 > -outline-Courier New-normal-normal-normal-mono-21-*-*-*-c-*-iso8859-1 (80 . 37) (1087 . 851) ->
 > -outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740)
 >
 > ;; (enlarge-font-by -4)
 >
 > -outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740) ->
 > -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592)
 >
 > ;; (enlarge-font-by 0)
 >
 > -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592) ->
 > -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592)
 >
 > ;; (enlarge-font-by 4)
 >
 > -outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (80 . 37) (677 . 592) ->
 > -outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1 (80 . 37) (841 . 740)

So what am I missing?  `enlarge-font' seems to work as expected.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> So what am I missing?  `enlarge-font' seems to work as expected.

Yes, see my followup reply.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Juanma Barranquero]

On Thu, Dec 5, 2013 at 3:02 PM, martin rudalics <rudalics@gmx.at> wrote:

> Could the kind soul providing Drew with binaries upload a new build
> so he may continue his frame bug tests ?

Unsure about the "kind soul" status, but building as we speak.

   J

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> > Could the kind soul providing Drew with binaries upload a new build
> > so he may continue his frame bug tests ?
> 
> Unsure about the "kind soul" status, but building as we speak.

Proof of "kind soul" status, I'd say.  Thanks.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> Perhaps the real-life thumbnail-mode does something to restore the
> frame dimensions, thus countermanding the effect of making the font
> smaller?

This is the core code, for thumbifying & dethumbifying:

(defcustom thumfr-frame-parameters
  '((menu-bar-lines . 0) (tool-bar-lines . 0) (scroll-bar-width . 6))
  "*Frame parameters for thumbnail frames.
Use this to show or hide things like the menu bar, tool bar, tab bar,
and scroll bars for thumbnail frames."
  :type '(repeat (cons symbol sexp))
  :group 'Thumbnail-Frames
  :set (lambda (sym defs)
         (custom-set-default sym defs)
         (dolist (frm  (frame-list))
           (when (and (frame-live-p frm)
                      (frame-parameter frm 'thumfr-thumbnail-frame))
             (modify-frame-parameters frm thumfr-frame-parameters)))))

(defun thumfr-thumbify-frame (&optional frame)
  "Create a thumbnail version of FRAME (default: selected frame).
Variable `thumfr-frame-parameters' is used to determine
which frame parameters (such as `menu-bar-lines') to remove."
  (interactive)
  (setq frame  (or frame (selected-frame)))
  (let* ((tf-params      (frame-parameter frame 'thumfr-non-thumbnail-frame))
         (non-tf-params  (thumfr-remove-if #'thumfr-thumfr-parameter-p
                                           (frame-parameters frame))))
    (when thumfr-rename-when-thumbify-flag (rename-non-minibuffer-frame))
    (unless (frame-parameter frame 'thumfr-thumbnail-frame)
      (set-frame-parameter frame 'thumfr-thumbnail-frame non-tf-params)
      (set-frame-parameter frame 'thumfr-non-thumbnail-frame nil)
      (condition-case thumfr-thumbify-frame
          (progn
            (enlarge-font (- thumfr-font-difference) frame)
            (when tf-params (modify-frame-parameters frame tf-params))
            (when thumfr-next-stack-xoffset
              (set-frame-position frame thumfr-next-stack-xoffset
                                  thumfr-next-stack-yoffset)
              (setq thumfr-next-stack-xoffset  nil
                    thumfr-next-stack-yoffset  nil))
            (modify-frame-parameters frame thumfr-frame-parameters))
        (font-too-small                 ; Try again, with a larger font.
         (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
         (set-frame-parameter frame 'thumfr-thumbnail-frame nil)
         (unless (> thumfr-font-difference 0)
           (error (error-message-string thumfr-thumbify-frame)))
         (let ((thumfr-font-difference  (1- thumfr-font-difference)))
           (thumfr-thumbify-frame frame)))
        (error
         (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
         (set-frame-parameter frame 'thumfr-thumbnail-frame nil)
         (error (error-message-string thumfr-thumbify-frame)))))))

(defun thumfr-dethumbify-frame (&optional frame)
  "Restore thumbnail FRAME to original size (default: selected frame)."
  (interactive)
  (setq frame  (or frame (selected-frame)))
  (let* ((non-tf-params  (frame-parameter frame 'thumfr-thumbnail-frame))
         (tf-params      (thumfr-remove-if #'thumfr-thumfr-parameter-p
                                           (frame-parameters frame))))
    (when non-tf-params                 ; No-op if not a thumbnail.
      (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
      (set-frame-parameter frame 'thumfr-thumbnail-frame nil)
      (condition-case thumfr-dethumbify-frame
          (progn
            (enlarge-font thumfr-font-difference frame)
            (modify-frame-parameters frame non-tf-params))
        (error
         (set-frame-parameter frame 'thumfr-thumbnail-frame non-tf-params)
         (set-frame-parameter frame 'thumfr-non-thumbnail-frame nil)
         (error (error-message-string thumfr-dethumbify-frame))))
      (select-frame-set-input-focus frame)
      (thumfr-only-raise-frame frame))))

(defun thumfr-thumfr-parameter-p (parameter+value)
  "Return non-nil if PARAMETER+VALUE is a `thumb-frm.el' frame parameter.
PARAMETER+VALUE is a frame-parameter cons: (PARAMETER . VALUE).
This means that PARAMETER is either `thumbfr-thumbnail-frame' or
`thumbfr-non-thumbnail-frame'."
  (memq (car parameter+value)
        '(thumfr-thumbnail-frame thumfr-non-thumbnail-frame)))

To be clear (I was not, before; sorry), the problem is not with shrinking
and enlarging the font and having the frame size follow.  For instance, my
commands `zoom-frm-out' and `zoom-frm-in' work fine in this respect.

The problem is with thumbifying (`thumfr-thumbify-frame').

Running it through the debugger, I see that the frame _is_ shrunk
correctly, along with the font, at this point in the code:

(enlarge-font (- thumfr-font-difference) frame)
...
(modify-frame-parameters frame thumfr-frame-parameters)

But if I don't go through the debugger, it does not work.  And if I just
hit `c' in the debugger, instead of `d' throughout, it also does not work.

This is 100% reproducible.  Dunno why stepping through the debugger would
work, and even hitting `c' for the `enlarge-font' call works, but hitting
`c' for the `condition-case' does not.

HTH.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Running it through the debugger, I see that the frame _is_ shrunk
 > correctly, along with the font, at this point in the code:
 >
 > (enlarge-font (- thumfr-font-difference) frame)
 > ...
 > (modify-frame-parameters frame thumfr-frame-parameters)
 >
 > But if I don't go through the debugger, it does not work.  And if I just
 > hit `c' in the debugger, instead of `d' throughout, it also does not work.
 >
 > This is 100% reproducible.  Dunno why stepping through the debugger would
 > work, and even hitting `c' for the `enlarge-font' call works, but hitting
 > `c' for the `condition-case' does not.

Put in some sit-fors.  Check whether and which exception handlers get
called.  Check which frame parameters get set and reset.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> Put in some sit-fors.  Check whether and which exception handlers get
> called.  Check which frame parameters get set and reset.

OK, I found that adding a (sit-for 0) after this call in
`thumfr-thumbify-frame' fixes the problem:

  (enlarge-font (- thumfr-font-difference) frame)

(And no error handlers were called with this simple test.)

Do I need to do that in my code, or will you be doing something to
your fix that incorporates this?

If I need to do it, should I add the sit-for to the end of `enlarge-font'
or add it only after the above call in `thumfr-thumbify-frame'.

IOW, is this something that needs to be fixed in the frame
shrinking/enlarging code, even though I do not generally notice a problem
with that, or should it be handled only here and there, where I happen to
notice a problem.  (Normally, I would probably opt for the latter, but if
you think this is now a wise or necessary thing to do in general, then
let me know.)

Thx.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > OK, I found that adding a (sit-for 0) after this call in
 > `thumfr-thumbify-frame' fixes the problem:
 >
 >   (enlarge-font (- thumfr-font-difference) frame)
 >
 > (And no error handlers were called with this simple test.)
 >
 > Do I need to do that in my code, or will you be doing something to
 > your fix that incorporates this?
 >
 > If I need to do it, should I add the sit-for to the end of `enlarge-font'
 > or add it only after the above call in `thumfr-thumbify-frame'.
 >
 > IOW, is this something that needs to be fixed in the frame
 > shrinking/enlarging code, even though I do not generally notice a problem
 > with that, or should it be handled only here and there, where I happen to
 > notice a problem.  (Normally, I would probably opt for the latter, but if
 > you think this is now a wise or necessary thing to do in general, then
 > let me know.)

Until we resolved this issue leave it in.

IIUC for some reason setting the font apparently doesn't want to resize
the frame immediately.  I could imagine that somewhere in the code I
compare numbers of lines/columns and decide that no resizing is needed
because these are unchanged.

Maybe you could try to insert somwhere at the top level a (ding) in
window--resize-root-window (in window.el) and listen whether it rings
when you try to thumbify a frame (with and without the sit-for).

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > Do I need to do that in my code, or will you be doing something to
>  > your fix that incorporates this?
>  >
>  > If I need to do it, should I add the sit-for to the end of `enlarge-font'
>  > or add it only after the above call in `thumfr-thumbify-frame'.
>  >
>  > IOW, is this something that needs to be fixed in the frame
>  > shrinking/enlarging code, even though I do not generally notice a problem
>  > with that, or should it be handled only here and there, where I happen to
>  > notice a problem.  (Normally, I would probably opt for the latter, but if
>  > you think this is now a wise or necessary thing to do in general, then
>  > let me know.)
> 
> Until we resolved this issue leave it in.

OK, but leave it in where?  That's my question.  After the call to
`enlarge-font' in `thumfr-thumbify-frame'?

> IIUC for some reason setting the font apparently doesn't want to resize
> the frame immediately.  I could imagine that somewhere in the code I
> compare numbers of lines/columns and decide that no resizing is needed
> because these are unchanged.
> 
> Maybe you could try to insert somwhere at the top level a (ding) in
> window--resize-root-window (in window.el) and listen whether it rings
> when you try to thumbify a frame (with and without the sit-for).

I have sound turned off and visual-bell has no effect in my environment.
And I would rather not fiddle with `window--resize-root-window'.

Are you unable to use `thumb-frm.el' for your tests?  AFAIK, it works on
any platform ("works" apart from this bug, I mean).  You should be able
to just load `frame-fns.el', `frame-cmds.el', and `thumb-frm.el', and
try it.  (You don't need all of the code in those 3 libraries, but it
won't hurt to load them for quick testing.)

But sad to say, when I try it from emacs -Q, loading those 3 libraries
and inserting `sit-for' after `enlarge-font' in `thumfr-thumbify-frame',
it does *not* solve the problem.  It works for my setup, but not for
this test from emacs -Q.  Sounds like subtle display timing thingies.
Or maybe font differences.  Or...?

I think it would be better if you could test this stuff on your end.
It is easy to see the problem, at least - just try emacs -Q, load those
3 files, then hit C-z.  Try adding sit-for here or there (where?), to
see if it helps.  I tried and failed (with emacs -Q).

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > OK, but leave it in where?  That's my question.  After the call to
 > `enlarge-font' in `thumfr-thumbify-frame'?

If it works, yes.

 > I have sound turned off and visual-bell has no effect in my environment.
 > And I would rather not fiddle with `window--resize-root-window'.

In *scratch* evaluate

(defvar my-thumbify nil)
(defvar my-counter 0)

(defun window--resize-root-window (window delta horizontal ignore pixelwise)
   "Resize root window WINDOW vertically by DELTA lines.
HORIZONTAL non-nil means resize root window WINDOW horizontally
by DELTA columns.

IGNORE non-nil means ignore any restrictions imposed by fixed
size windows, `window-min-height' or `window-min-width' settings.

This function is only called by the frame resizing routines.  It
resizes windows proportionally and never deletes any windows."
   (when my-thumbify
     (setq my-counter (1+ my-counter)))
   (when (and (windowp window) (numberp delta))
     (let ((pixel-delta
	   (if pixelwise
	       delta
	     (window--size-to-pixel window delta horizontal))))
       (when (window-sizable-p window pixel-delta horizontal ignore t)
	(window--resize-reset (window-frame window) horizontal)
	(window--resize-this-window
	 window pixel-delta horizontal ignore t)))))

and bind my-thumbify to t around your `enlarge-font' call.  Then tell me
the value of my-counter.

 > Are you unable to use `thumb-frm.el' for your tests?  AFAIK, it works on
 > any platform ("works" apart from this bug, I mean).  You should be able
 > to just load `frame-fns.el', `frame-cmds.el', and `thumb-frm.el', and
 > try it.  (You don't need all of the code in those 3 libraries, but it
 > won't hurt to load them for quick testing.)

I believe that your code works just as you say that it does.  So this
won't help.

 > But sad to say, when I try it from emacs -Q, loading those 3 libraries
 > and inserting `sit-for' after `enlarge-font' in `thumfr-thumbify-frame',
 > it does *not* solve the problem.  It works for my setup, but not for
 > this test from emacs -Q.  Sounds like subtle display timing thingies.
 > Or maybe font differences.  Or...?

Maybe.  The problem is to boil this down to a minimum test example.  If
that example is three files long, it will take me a year to find out.

 > I think it would be better if you could test this stuff on your end.
 > It is easy to see the problem, at least - just try emacs -Q, load those
 > 3 files, then hit C-z.  Try adding sit-for here or there (where?), to
 > see if it helps.  I tried and failed (with emacs -Q).

If you don't investigate yourself and come up with a simple, repeatable
example, I'm afraid we won't be able to fix this soon.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> In *scratch* evaluate...
> and bind my-thumbify to t around your `enlarge-font' call.  Then tell me
> the value of my-counter.

I did that, with emacs -Q (loading the 3 (original) files plus your code).

Same problem (yes, I know that what you suggested was not intended as a fix).

`my-counter' = 0 after thumbifying.

[Also, FWIW, When I did C-h v my-counter, the *Help* buffer was shown to
the right of the main buffer, instead of below it.  (Unrelated bug/feature,
no doubt.)  If I do `C-h v' with the frame not thumbified then *Help*
shows up below, as usual.  Perhaps this is because of the pixel width of
the displayed buffer at the reduced font size.]

HTH.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> and bind my-thumbify to t around your `enlarge-font' call.  Then tell me
 >> the value of my-counter.
 >
 > I did that, with emacs -Q (loading the 3 (original) files plus your code).
 > Same problem (yes, I know that what you suggested was not intended as a fix).
 >
 > `my-counter' = 0 after thumbifying.

Actually what I expected after your earlier description.  Could you try
once more with the `condition-case' in `thumfr-thumbify-frame' removed
and see whether that changes anything?

 > [Also, FWIW, When I did C-h v my-counter, the *Help* buffer was shown to
 > the right of the main buffer, instead of below it.  (Unrelated bug/feature,
 > no doubt.)  If I do `C-h v' with the frame not thumbified then *Help*
 > shows up below, as usual.  Perhaps this is because of the pixel width of
 > the displayed buffer at the reduced font size.]

This could be normal - after all it's without your usual customizations
of `display-buffer' IIUC.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> Could you try
> once more with the `condition-case' in `thumfr-thumbify-frame' removed
> and see whether that changes anything?

I did that.  It did not change anything.  And the counter is still 0.

HTH.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> Could you try
 >> once more with the `condition-case' in `thumfr-thumbify-frame' removed
 >> and see whether that changes anything?
 >
 > I did that.  It did not change anything.  And the counter is still 0.

I'm running out of ideas.  I now set the frame as garbaged which should
include the fset_redisplay Eli proposed earlier.  I don't have the
slightest idea when to use which of these so this is just a shot in the
dark.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  >> Could you try
>  >> once more with the `condition-case' in `thumfr-thumbify-frame' removed
>  >> and see whether that changes anything?
>  >
>  > I did that.  It did not change anything.  And the counter is still 0.
> 
> I'm running out of ideas.  I now set the frame as garbaged which should
> include the fset_redisplay Eli proposed earlier.  I don't have the
> slightest idea when to use which of these so this is just a shot in the
> dark.

I tried again with your recipe and a build with your latest try (from
Juanma).  No change in symptoms, unfortunately.  I tried your recipe,
both with and without the condition-case wrapper.  `my-counter' = 0 still.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > I tried again with your recipe and a build with your latest try (from
 > Juanma).  No change in symptoms, unfortunately.  I tried your recipe,
 > both with and without the condition-case wrapper.  `my-counter' = 0 still.

I have no more ideas.  For some reason Emacs either refuses to redisplay
the frame or insists on thinking that it still has the same size and no
size change is needed.  Maybe it's some additional hook you run.  If you
see a chance to do that, try to strip your code from all non-essential
features while still reproducing the bug (this is what any person would
have to do if she wanted to find the cause of this behavior).

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Sun, 08 Dec 2013 18:54:06 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 16028@debbugs.gnu.org
> 
>  > I tried again with your recipe and a build with your latest try (from
>  > Juanma).  No change in symptoms, unfortunately.  I tried your recipe,
>  > both with and without the condition-case wrapper.  `my-counter' = 0 still.
> 
> I have no more ideas.  For some reason Emacs either refuses to redisplay
> the frame or insists on thinking that it still has the same size and no
> size change is needed.

If no one beats me to it, I will try to look into this in a day or
two.

> Maybe it's some additional hook you run.

Does this mean that the following recipe works for you?

  emacs -Q
  M-x load-file RET frame-fns.el RET
  M-x load-file RET frame-cmds.el RET
  M-x load-file RET thumb-frm.el RET
  C-z

It doesn't work for me here, with today's trunk.

If this doesn't work for you, then what hooks did you have in mind?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> If no one beats me to it, I will try to look into this in a day or
> two.

Please do.

>> Maybe it's some additional hook you run.
> 
> Does this mean that the following recipe works for you?
> 
>   emacs -Q
>   M-x load-file RET frame-fns.el RET
>   M-x load-file RET frame-cmds.el RET
>   M-x load-file RET thumb-frm.el RET
>   C-z
> 
> It doesn't work for me here, with today's trunk.

I haven't had tried that.  But since Drew said it doesn't work
I had no reason to doubt that it doesn't work.

> If this doesn't work for you, then what hooks did you have in mind?

I thought that code might have put something on hooks.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Mon, 09 Dec 2013 19:37:06 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
> >   emacs -Q
> >   M-x load-file RET frame-fns.el RET
> >   M-x load-file RET frame-cmds.el RET
> >   M-x load-file RET thumb-frm.el RET
> >   C-z
> > 
> > It doesn't work for me here, with today's trunk.
> 
> I haven't had tried that.  But since Drew said it doesn't work
> I had no reason to doubt that it doesn't work.

Can you please test this on X?  I'd like to know if this is a Windows
specific problem.

TIA

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >>>   emacs -Q
 >>>   M-x load-file RET frame-fns.el RET
 >>>   M-x load-file RET frame-cmds.el RET
 >>>   M-x load-file RET thumb-frm.el RET
 >>>   C-z
 >>>
 >>> It doesn't work for me here, with today's trunk.
 >> I haven't had tried that.  But since Drew said it doesn't work
 >> I had no reason to doubt that it doesn't work.
 >
 > Can you please test this on X?  I'd like to know if this is a Windows
 > specific problem.

On Gtk3+ the default frame shrinks to 315x362 pixels and in addition I
get a

Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion `extra_space >= 0' failed

on the console (which might a more or less well known issue).

I consider such resizing insane because there's no guarantee that a
toolkit will be able to cope with arbitrarily microsized scrollbars.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> I consider such resizing insane because there's no guarantee that a
> toolkit will be able to cope with arbitrarily microsized scrollbars.

There's no guarantee against any fault of a window mgr.

The thumb-frm.el code wraps the shrinking/expanding in a condition-case, 
which restores the original size and other frame parameters in case of
error.  But for that, Emacs must be able to detect the error.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> Can you please test this on X?  I'd like to know if this is a Windows
> specific problem.

A simple way to reproduce this it in a proper bug report:

(defun enlarged-font-name (fontname frame increment)
   "FONTNAME, after enlarging font size of FRAME by INCREMENT.
FONTNAME is the font of FRAME."
   (when (query-fontset fontname)
     (let ((ascii  (assq 'ascii (aref (fontset-info fontname frame) 2))))
       (when ascii (setq fontname  (nth 2 ascii)))))
   (let ((xlfd-fields  (x-decompose-font-name fontname)))
     (unless xlfd-fields (error "Cannot decompose font name"))
     (let ((new-size  (+ (string-to-number
                          (aref xlfd-fields xlfd-regexp-pixelsize-subnum))
                         increment)))
       (unless (> new-size 0) (signal 'font-too-small (list new-size)))
       (aset xlfd-fields xlfd-regexp-pixelsize-subnum
             (number-to-string new-size)))
     ;; Set point size & width to "*", so frame width adjusts to new font
     (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
     (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
     (x-compose-font-name xlfd-fields)))

(defun enlarge-font-by (increment)
   (let* ((old-font (cdr (assq 'font (frame-parameters (selected-frame)))))
	 (new-font (enlarged-font-name old-font (selected-frame) increment)))
     (modify-frame-parameters
      (selected-frame) (list (cons 'font new-font)
			    (cons 'tool-bar-lines 0)
			    (cons 'menu-bar-lines 0)
			    (cons 'scroll-bar-width 6)))))

(enlarge-font-by -4)

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

Yet simpler:

(defun enlarged-font-name (fontname frame increment)
   "FONTNAME, after enlarging font size of FRAME by INCREMENT.
FONTNAME is the font of FRAME."
   (when (query-fontset fontname)
     (let ((ascii  (assq 'ascii (aref (fontset-info fontname frame) 2))))
       (when ascii (setq fontname  (nth 2 ascii)))))
   (let ((xlfd-fields  (x-decompose-font-name fontname)))
     (unless xlfd-fields (error "Cannot decompose font name"))
     (let ((new-size  (+ (string-to-number
                          (aref xlfd-fields xlfd-regexp-pixelsize-subnum))
                         increment)))
       (unless (> new-size 0) (signal 'font-too-small (list new-size)))
       (aset xlfd-fields xlfd-regexp-pixelsize-subnum
             (number-to-string new-size)))
     ;; Set point size & width to "*", so frame width adjusts to new font
     (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
     (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
     (x-compose-font-name xlfd-fields)))

(defun enlarge-font-by (increment)
   (let* ((old-font (cdr (assq 'font (frame-parameters (selected-frame)))))
	 (new-font (enlarged-font-name old-font (selected-frame) increment)))
     (modify-frame-parameters
      (selected-frame) (list (cons 'font new-font)
			    (cons 'scroll-bar-width 6)))))

(enlarge-font-by -4)

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> (defun enlarged-font-name (fontname frame increment)
>    "FONTNAME, after enlarging font size of FRAME by INCREMENT.
> FONTNAME is the font of FRAME."
>    (when (query-fontset fontname)
>      (let ((ascii  (assq 'ascii (aref (fontset-info fontname frame) 2))))
>        (when ascii (setq fontname  (nth 2 ascii)))))
>    (let ((xlfd-fields  (x-decompose-font-name fontname)))
>      (unless xlfd-fields (error "Cannot decompose font name"))
>      (let ((new-size  (+ (string-to-number
>                           (aref xlfd-fields xlfd-regexp-pixelsize-subnum))
>                          increment)))
>        (unless (> new-size 0) (signal 'font-too-small (list new-size)))
>        (aset xlfd-fields xlfd-regexp-pixelsize-subnum
>              (number-to-string new-size)))
>      ;; Set point size & width to "*", so frame width adjusts to new font
>      (aset xlfd-fields xlfd-regexp-pointsize-subnum "*")
>      (aset xlfd-fields xlfd-regexp-avgwidth-subnum "*")
>      (x-compose-font-name xlfd-fields)))
> 
> (defun enlarge-font-by (increment)
>    (let* ((old-font (cdr (assq 'font (frame-parameters (selected-frame)))))
> 	 (new-font (enlarged-font-name old-font (selected-frame)
> increment)))
>      (modify-frame-parameters
>       (selected-frame) (list (cons 'font new-font)
> 			    (cons 'scroll-bar-width 6)))))
> 
> (enlarge-font-by -4)


And this seems to compensate for the bug, at least with the above recipe:

(defun enlarge-font-by (increment)
   (let* ((old-font (cdr (assq 'font (frame-parameters (selected-frame)))))
	 (new-font (enlarged-font-name old-font (selected-frame) increment)))
     (modify-frame-parameters
      (selected-frame) (list (cons 'scroll-bar-width 6)))
     (modify-frame-parameters
      (selected-frame) (list (cons 'font new-font)))))

Switch the order of the two calls to `modify-frame-parameters' and the
bug is manifested again.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Switch the order of the two calls to `modify-frame-parameters' and the
 > bug is manifested again.

Yes.  As a rule always resize the frame last.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > Switch the order of the two calls to `modify-frame-parameters'
>  > and the bug is manifested again.
> 
> Yes.  As a rule always resize the frame last.

FWIW/FYI: I was hoping that that might be a simple solution to my
problem. I tried switching the order, doing the other frame changes
before shrinking or enlarging the font.

Unfortunately, that did not work at all.  It made a big mess, in
all Emacs versions.  For one thing, each shrinking/enlargement
magnified the scale of zoom out/in over the previous one.

I.e., each shrinking/enlargement was greater than the
enlargement/shrinking that immediately preceded it (not just
greater than the last shrinking/enlargement).

You can see this easily in emacs -Q by (loading frame-fns.el,
then frame-cmds.el, then) loading thumb-frm.el but with the calls
to `enlarge-font' moved after the `modify-frame-parameters' calls.

E.g., for thumbify:

(when tf-params (modify-frame-parameters frame tf-params))
(when thumfr-next-stack-xoffset
  (set-frame-position frame thumfr-next-stack-xoffset
                      thumfr-next-stack-yoffset)
  (setq thumfr-next-stack-xoffset  nil
        thumfr-next-stack-yoffset  nil))
(modify-frame-parameters frame thumfr-frame-parameters)
;; Trying this last, not first.
(enlarge-font (- thumfr-font-difference) frame)

And for dethumbify:

(modify-frame-parameters frame non-tf-params)
;; Trying this last, not first.
(enlarge-font thumfr-font-difference frame)

I had to quickly revert to the regular code I use, which calls
`enlarge-font' first, not last.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Unfortunately, that did not work at all.  It made a big mess, in
 > all Emacs versions.  For one thing, each shrinking/enlargement
 > magnified the scale of zoom out/in over the previous one.
 >
 > I.e., each shrinking/enlargement was greater than the
 > enlargement/shrinking that immediately preceded it (not just
 > greater than the last shrinking/enlargement).

Which also demonstrates how fragile your code is.  You maybe rely on
some undocumented behavior, namely that setting the font size can set
the scrollbar width too, despite of the fact that you explicitly set the
scrollbar width to some specific value before.  And your code might
easily fail with toolkits that want to handle the scrollbar width
themselves.

The trap your code fell into can be roughly described as follows:

(1) You ask for changing the pixel size of a frame by setting the font
     size.  Emacs passes the request on to the window manager but on
     Windows it does _not_ store the new pixel size of the frame.

(2) You ask for changing the pixel size of a frame by setting the
     scrollbar width.

Now before my changes, (2) asked the window manager to change the pixel
size of the frame based on its line/column sizes multiplied by the
default font sizes.  After my changes, (2) asks to change the pixel size
of the frame directly from the previously calculated pixel sizes.
However, since on Windows (1) does not record the change of the pixel
size caused by setting the font size, the request in (2) will be based
on the pixel size of the frame before (1) was issued.

I don't know how to fix this properly.  IIUC Emacs cannot wait until
Windows passes the new sizes back to it in (1) just as it does on other
systems.  The sit-for I proposed earlier could work around this.  If
OTOH I restore the calculation for (2) to use the line/column values,
people who want to change the scrollbar width exactly by pixels are
lost.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > Unfortunately, that did not work at all.  It made a big mess, in
>  > all Emacs versions.  For one thing, each shrinking/enlargement
>  > magnified the scale of zoom out/in over the previous one.
>  >
>  > I.e., each shrinking/enlargement was greater than the
>  > enlargement/shrinking that immediately preceded it (not just
>  > greater than the last shrinking/enlargement).
> 
> Which also demonstrates how fragile your code is.

You are welcome to improve it or offer concrete suggestions - please do.

FWIW, it works fine, AFAIK, on all previous versions of Emacs, and on all
platforms I'm aware of.  I use it myself with Emacs 20-24 on MS Windows
and with Emacs 21.3 on GNU/Linux (KDE & GNOME).

> The trap your code fell into can be roughly described as follows:
> 
> (1) You ask for changing the pixel size of a frame by setting the font
>      size.  Emacs passes the request on to the window manager but on
>      Windows it does _not_ store the new pixel size of the frame.
> 
> (2) You ask for changing the pixel size of a frame by setting the
>      scrollbar width.

Why should asking to change the scroll-bar width constitute a request to
also change the pixel size of the frame?  Or did you mean only that
changing the scroll-bar width will change the frame width slightly?
The latter I could probably live with.

> Now before my changes, (2) asked the window manager to change the pixel
> size of the frame based on its line/column sizes multiplied by the
> default font sizes.  After my changes, (2) asks to change the pixel size
> of the frame directly from the previously calculated pixel sizes.
> However, since on Windows (1) does not record the change of the pixel
> size caused by setting the font size, the request in (2) will be based
> on the pixel size of the frame before (1) was issued.

Good to understand.  Thx.  Not sure what that means in terms of trying
to get my code to work properly with your new code (as well as with
prior Emacs code).  Concrete suggestions welcome.

> I don't know how to fix this properly.  IIUC Emacs cannot wait until
> Windows passes the new sizes back to it in (1) just as it does on other
> systems.  The sit-for I proposed earlier could work around this.  If
> OTOH I restore the calculation for (2) to use the line/column values,
> people who want to change the scrollbar width exactly by pixels are
> lost.

Are they necessarily lost, or is there some other way to accommodate both?

BTW, as far as you can tell, is it just the scroll bar that is the problem
(wrt my code)?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Why should asking to change the scroll-bar width constitute a request to
 > also change the pixel size of the frame?

Because that's what x_set_scroll_bar_width in frame.c does.
Unfortunately so, IMHO.

 > Or did you mean only that
 > changing the scroll-bar width will change the frame width slightly?
 > The latter I could probably live with.

When x_set_scroll_bar_width asks to change the frame size, it has to
provide the new size in some way.  In your particular case, it uses that
of _before_ the font change since Windows did not propagate the new
values back to us.

 >> Now before my changes, (2) asked the window manager to change the pixel
 >> size of the frame based on its line/column sizes multiplied by the
 >> default font sizes.  After my changes, (2) asks to change the pixel size
 >> of the frame directly from the previously calculated pixel sizes.
 >> However, since on Windows (1) does not record the change of the pixel
 >> size caused by setting the font size, the request in (2) will be based
 >> on the pixel size of the frame before (1) was issued.
 >
 > Good to understand.  Thx.  Not sure what that means in terms of trying
 > to get my code to work properly with your new code (as well as with
 > prior Emacs code).  Concrete suggestions welcome.

I'm afraid there's not much you can do here.

 >> I don't know how to fix this properly.  IIUC Emacs cannot wait until
 >> Windows passes the new sizes back to it in (1) just as it does on other
 >> systems.  The sit-for I proposed earlier could work around this.  If
 >> OTOH I restore the calculation for (2) to use the line/column values,
 >> people who want to change the scrollbar width exactly by pixels are
 >> lost.
 >
 > Are they necessarily lost, or is there some other way to accommodate both?
 >
 > BTW, as far as you can tell, is it just the scroll bar that is the problem
 > (wrt my code)?

Hopefully, scrollbars on Windows are the only problem for you.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > Why should asking to change the scroll-bar width constitute a
>  > request to also change the pixel size of the frame?
> 
> Because that's what x_set_scroll_bar_width in frame.c does.
> Unfortunately so, IMHO.

Well, I don't understand, but maybe I do not need to.  Is that something
new?  The regression is new.  If the C code has always done that, it has
not been problematic for thumbnail frames before now.

>  > Or did you mean only that
>  > changing the scroll-bar width will change the frame width slightly?
>  > The latter I could probably live with.
> 
> When x_set_scroll_bar_width asks to change the frame size, it has to
> provide the new size in some way.  In your particular case, it uses that
> of _before_ the font change since Windows did not propagate the new
> values back to us.
> 
>  >> Now before my changes, (2) asked the window manager to change the pixel
>  >> size of the frame based on its line/column sizes multiplied by the
>  >> default font sizes.  After my changes, (2) asks to change the pixel size
>  >> of the frame directly from the previously calculated pixel sizes.
>  >> However, since on Windows (1) does not record the change of the pixel
>  >> size caused by setting the font size, the request in (2) will be based
>  >> on the pixel size of the frame before (1) was issued.
>  >
>  > Good to understand.  Thx.  Not sure what that means in terms of trying
>  > to get my code to work properly with your new code (as well as with
>  > prior Emacs code).  Concrete suggestions welcome.
> 
> I'm afraid there's not much you can do here.

You mean the only solution is to stop using Emacs 24 after 24.3?

>  >> I don't know how to fix this properly.  IIUC Emacs cannot wait until
>  >> Windows passes the new sizes back to it in (1) just as it does on other
>  >> systems.  The sit-for I proposed earlier could work around this.  If
>  >> OTOH I restore the calculation for (2) to use the line/column values,
>  >> people who want to change the scrollbar width exactly by pixels are
>  >> lost.
>  >
>  > Are they necessarily lost, or is there some other way to accommodate
>  > both?
>  >
>  > BTW, as far as you can tell, is it just the scroll bar that is the
>  > problem (wrt my code)?
> 
> Hopefully, scrollbars on Windows are the only problem for you.

Well at least that is good news.  As a workaround, then, I could presumably
turn off the scroll bar on thumbnail frames.  That would be a fairly large
loss of functionality, but at least it would make (de)thumbifying possible
again.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> Because that's what x_set_scroll_bar_width in frame.c does.
 >> Unfortunately so, IMHO.
 >
 > Well, I don't understand, but maybe I do not need to.  Is that something
 > new?  The regression is new.  If the C code has always done that, it has
 > not been problematic for thumbnail frames before now.

You've been exploiting an undocumented feature, namely that setting the
scrollbar width takes as reference values the numbers of lines and
columns of a frame it had before an unacknowledged action preceding the
current one.

 > You mean the only solution is to stop using Emacs 24 after 24.3?

If you insist on using the old code, maybe.

 >> Hopefully, scrollbars on Windows are the only problem for you.
 >
 > Well at least that is good news.  As a workaround, then, I could presumably
 > turn off the scroll bar on thumbnail frames.  That would be a fairly large
 > loss of functionality, but at least it would make (de)thumbifying possible
 > again.

You should try the solution I sketched in my other mail.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Fri, 13 Dec 2013 11:13:02 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 16028@debbugs.gnu.org
> 
>  > You mean the only solution is to stop using Emacs 24 after 24.3?
> 
> If you insist on using the old code, maybe.

I see no reasons why any non-bundled package couldn't have code that
did different things depending on Emacs version.

>  >> Hopefully, scrollbars on Windows are the only problem for you.
>  >
>  > Well at least that is good news.  As a workaround, then, I could presumably
>  > turn off the scroll bar on thumbnail frames.  That would be a fairly large
>  > loss of functionality, but at least it would make (de)thumbifying possible
>  > again.
> 
> You should try the solution I sketched in my other mail.

Yes, please do.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  >> Because that's what x_set_scroll_bar_width in frame.c does.
>  >> Unfortunately so, IMHO.
>  >
>  > Well, I don't understand, but maybe I do not need to.  Is that something
>  > new?  The regression is new.  If the C code has always done that, it has
>  > not been problematic for thumbnail frames before now.
> 
> You've been exploiting an undocumented feature, namely that setting the
> scrollbar width takes as reference values the numbers of lines and
> columns of a frame it had before an unacknowledged action preceding the
> current one.

That's one interpretation.

Actually, before Emacs on MS Windows changed so that the scroll bar did
not _automatically_ shrink with the font size, I did nothing at all to
the scroll bar.  Didn't have to.  In Emacs 20, shrinking the font is
sufficient to shrink the scroll bar as well.

To compensate for the fact that Emacs stopped shrinking the scroll bar
along with the font and frame, I added an explicit (user-configurable)
scroll-bar width for thumbified frames.  (And before I realized that that
workaround was possible I just eliminated the scroll bar in thumbified
frames for Emacs > 20.)

>  > You mean the only solution is to stop using Emacs 24 after 24.3?
> 
> If you insist on using the old code, maybe.

I don't insist on any particular code.  It's the behavior I'm after,
not a particular implementation.  Of course, if other things are
equal then I would prefer an implementation that works across Emacs
versions.  But as a start I'm just looking for an implementation that
works, i.e., a fix/workaround for the regression.

Stefan mentioned that I should not need to change my code for this
regression, that it is just an Emacs bug that needs to be fixed.  If
that is the case then so much the better.  But I am willing to change
my code as needed.  I just need to know what changes I need to make.

> You should try the solution I sketched in my other mail.

What solution was that?  Can you state it again, in the context of
the thumb-frm.el code?  I believe I've tried everything I saw suggested
here, but I'm open to a fix for my code, of course.  I've been asking
for it.  The last suggestion I recall was to change the order, and I
reported the problems that caused.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > What solution was that?  Can you state it again, in the context of
 > the thumb-frm.el code?  I believe I've tried everything I saw suggested
 > here, but I'm open to a fix for my code, of course.  I've been asking
 > for it.  The last suggestion I recall was to change the order, and I
 > reported the problems that caused.

To thumbify

(1) Save the current frame pixel size, font and scrollbar width.

(2) Set the new font size.

(3) Set the new scrollbar width.

(4) Set the new pixel size to some calculated from the one saved in
     (1) and the scale factor used in (2).

To dethumbify

(5) Set the new font size to the one saved in (1).

(6) Set the new scrollbar width to the one saved in (1).

(7) Set the new frame pixel size to the one saved in (1).

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > What solution was that?  Can you state it again, in the context of
>  > the thumb-frm.el code?  I believe I've tried everything I saw suggested
>  > here, but I'm open to a fix for my code, of course.  I've been asking
>  > for it.  The last suggestion I recall was to change the order, and I
>  > reported the problems that caused.
> 
> To thumbify
> (1) Save the current frame pixel size, font and scrollbar width.
> (2) Set the new font size.
> (3) Set the new scrollbar width.
> (4) Set the new pixel size to some calculated from the one saved in
>     (1) and the scale factor used in (2).
> 
> To dethumbify
> (5) Set the new font size to the one saved in (1).
> (6) Set the new scrollbar width to the one saved in (1).
> (7) Set the new frame pixel size to the one saved in (1).

a. I don't know how to get the frame pixel size.  Do you mean only
`frame-pixel-width'?

b. I need to allow users to specify settings for thumbified frames
(option `thumfr-frame-parameters').

c. I need to be able to record the current frame parameters and use
them to restore - for both thumbified and non-thumbified frames.
I store this info in frame parameters `thumfr-thumbnail-frame' and
`thumfr-non-thumbnail-frame'.

Perhaps you can make a concrete suggestion, since you seem to understand
what you have in mind by (1)-(7).  I do not.

But when I asked for concrete suggestions for "trying to get my code to
work properly with your new code" you replied "I'm afraid there's not
much you can do here."

The code for `thumfr-thumbify-frame' and `thumfr-dethumbify-frame' is
only 50 lines long, and (i) some of that is for stacking offsets, which
is irrelevant here, and (ii) some of it is `font-too-small' error handling,
to retry with a slightly larger font.

Here is the essential code (30 lines):

(defun thumfr-thumbify-frame (&optional frame)
  (interactive)
  (setq frame  (or frame (selected-frame)))
  (let* ((tf-params      (frame-parameter frame 'thumfr-non-thumbnail-frame))
         (non-tf-params  (cl-remove-if #'thumfr-thumfr-parameter-p
                                       (frame-parameters frame))))
    (unless (frame-parameter frame 'thumfr-thumbnail-frame)
      (set-frame-parameter frame 'thumfr-thumbnail-frame non-tf-params)
      (set-frame-parameter frame 'thumfr-non-thumbnail-frame nil)
      (condition-case thumfr-thumbify-frame
          (progn (enlarge-font (- thumfr-font-difference) frame)
                 (when tf-params (modify-frame-parameters frame tf-params))
                 (modify-frame-parameters frame thumfr-frame-parameters))
        (error (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
               (set-frame-parameter frame 'thumfr-thumbnail-frame nil)
               (error (error-message-string thumfr-thumbify-frame)))))))

(defun thumfr-dethumbify-frame (&optional frame)
  (interactive)
  (setq frame  (or frame (selected-frame)))
  (let* ((non-tf-params  (frame-parameter frame 'thumfr-thumbnail-frame))
         (tf-params      (cl-remove-if #'thumfr-thumfr-parameter-p
                                       (frame-parameters frame))))
    (when non-tf-params
      (set-frame-parameter frame 'thumfr-non-thumbnail-frame tf-params)
      (set-frame-parameter frame 'thumfr-thumbnail-frame nil)
      (condition-case thumfr-dethumbify-frame
          (progn (enlarge-font thumfr-font-difference frame)
                 (modify-frame-parameters frame non-tf-params))
        (error (set-frame-parameter frame 'thumfr-thumbnail-frame non-tf-params)
               (set-frame-parameter frame 'thumfr-non-thumbnail-frame nil)
               (error (error-message-string thumfr-dethumbify-frame)))))))

Helper code:

(defun thumfr-thumfr-parameter-p (parameter+value)
  (memq (car parameter+value)
        '(thumfr-thumbnail-frame thumfr-non-thumbnail-frame)))

(defcustom thumfr-frame-parameters
  '((menu-bar-lines . 0) (tool-bar-lines . 0) (scroll-bar-width . 6))
  :type '(repeat (cons symbol sexp)) :group 'Thumbnail-Frames
  :set (lambda (sym defs)
         (custom-set-default sym defs)
         (dolist (frm  (frame-list))
           (when (and (frame-live-p frm)
                      (frame-parameter frm 'thumfr-thumbnail-frame))
             (modify-frame-parameters frm thumfr-frame-parameters)))))

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> To thumbify
 >> (1) Save the current frame pixel size, font and scrollbar width.
 >> (2) Set the new font size.
 >> (3) Set the new scrollbar width.
 >> (4) Set the new pixel size to some calculated from the one saved in
 >>     (1) and the scale factor used in (2).
 >>
 >> To dethumbify
 >> (5) Set the new font size to the one saved in (1).
 >> (6) Set the new scrollbar width to the one saved in (1).
 >> (7) Set the new frame pixel size to the one saved in (1).
 >
 > a. I don't know how to get the frame pixel size.  Do you mean only
 > `frame-pixel-width'?

And `frame-pixel-height'.  You can use the line/column values instead.
Just that if the frame did not have an integral multiple of
lines/columns before, you won't restore the exact size afterwards.

 > b. I need to allow users to specify settings for thumbified frames
 > (option `thumfr-frame-parameters').

Process them in (3) and revert them before (7).

 > c. I need to be able to record the current frame parameters and use
 > them to restore - for both thumbified and non-thumbified frames.
 > I store this info in frame parameters `thumfr-thumbnail-frame' and
 > `thumfr-non-thumbnail-frame'.

Save them in (1) and restore them before (7).

 > Perhaps you can make a concrete suggestion, since you seem to understand
 > what you have in mind by (1)-(7).  I do not.

What is it you don't understand?

 > But when I asked for concrete suggestions for "trying to get my code to
 > work properly with your new code" you replied "I'm afraid there's not
 > much you can do here."

Let's hope I was wrong when I said that.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Thu, 12 Dec 2013 11:17:46 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 16028@debbugs.gnu.org
> 
> The trap your code fell into can be roughly described as follows:
> 
> (1) You ask for changing the pixel size of a frame by setting the font
>      size.  Emacs passes the request on to the window manager but on
>      Windows it does _not_ store the new pixel size of the frame.
> 
> (2) You ask for changing the pixel size of a frame by setting the
>      scrollbar width.
> 
> Now before my changes, (2) asked the window manager to change the pixel
> size of the frame based on its line/column sizes multiplied by the
> default font sizes.  After my changes, (2) asks to change the pixel size
> of the frame directly from the previously calculated pixel sizes.
> However, since on Windows (1) does not record the change of the pixel
> size caused by setting the font size, the request in (2) will be based
> on the pixel size of the frame before (1) was issued.

Since we can now resize a frame pixelwise with an explicit request
(right?), would it be possible to fix the above by

  (3) Ask for change of the frame size by giving explicit dimensions
      in pixel units.

?  If not, why not?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > Since we can now resize a frame pixelwise with an explicit request
 > (right?), would it be possible to fix the above by
 >
 >   (3) Ask for change of the frame size by giving explicit dimensions
 >       in pixel units.
 >
 > ?  If not, why not?

We always could resize frames pixelwise and also did so IIRC, for
example, when faking maximized or fullscreen frames.  After that, we
either left the last pixels of the echo area dangling, left some empty
space between side by side windows, or extended the rightmost fringe by
some pixels.  All this because change_frame_size wasn't able to resize
pixelwise.  The display engine worked pixelwise for a long time already,
as can be easily seen, for example, when drawing a fullscreen modeline.

If you want to change the frame size pixelwise from Lisp, you can now
use `set-frame-size'.  But this won't solve the problem that issuing two
requests in sequel is still inherently broken on Windows.  The problem
here is that we don't resynch with Windows after calling
my_set_window_pos in x_set_window_size as I explained earlier.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Thu, 12 Dec 2013 19:10:42 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
> If you want to change the frame size pixelwise from Lisp, you can now
> use `set-frame-size'.  But this won't solve the problem that issuing two
> requests in sequel is still inherently broken on Windows.  The problem
> here is that we don't resynch with Windows after calling
> my_set_window_pos in x_set_window_size as I explained earlier.

But if we somehow could provide Drew with the frame dimensions that
_should_ have resulted from the two changes his code does, then he
could add a call to set-frame-size to request precisely those
dimensions, and that should fix his problem, no?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > But if we somehow could provide Drew with the frame dimensions that
 > _should_ have resulted from the two changes his code does, then he
 > could add a call to set-frame-size to request precisely those
 > dimensions, and that should fix his problem, no?

I'm not sure.  In principle Drew should be able to thumbify as follows:

(1) Save the current pixel sizess, font and scrollbar width.

(2) Set the new font size.

(3) Set the new scrollbar width.

(4) Set the new pixel sizes to some calculated from the ones saved in
     (1) and the scale factor used in (2).

To dethumbify he would have to

(5) Set the new font size to the one saved in (1).

(6) Set the new scrollbar width to the one saved in (1).

(7) Set the new frame pixel sizes to the ones saved in (1).

I don't know whether this correctly restores window start positions but
at least it seems the only sane way to fix his problem with the current
trunk.

We could obviously store the new pixel values and either let any size
changing functions use the new values or provide a Lisp interface to
them and let Drew use that value in his calculations.  Doing so would,
however, not eliminate the fact that the state of Emacs is inconsistent
while a resize operation is pending because the value returned by
`frame-pixel-height' is not in line with that of `frame-height'.  The
programmer would still have to be aware of this inconsistency and
explaining such a thing in the manual or a doc-string would be quite a
nuisance.  BTW, when creating a new frame, the inconsistency should be
observable on GNU/Linux as well.

I see only two ways to solve this inconsistency:

(1) Find some way to synch with the window manager as we do on
     GNU/Linux.

(2) Apply the size changes with the commented-out code.  The comment
     motivating why we should not do this on Windows because of the
     menubar wrapping issue doesn't make sense to me anyway: If we and
     Windows can handle wrapping, we'll do that when Windows gets back to
     us.  And the worst thing that could happen to us is that parts of
     the frame (including the modeline) might get obscured.  But this is
     something I plan to do anyway when shrinking a frame below the
     minimum size to accomodate all of its windows.

WDYT?

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Fri, 13 Dec 2013 11:12:39 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
>  > But if we somehow could provide Drew with the frame dimensions that
>  > _should_ have resulted from the two changes his code does, then he
>  > could add a call to set-frame-size to request precisely those
>  > dimensions, and that should fix his problem, no?
> 
> I'm not sure.  In principle Drew should be able to thumbify as follows:
> 
> (1) Save the current pixel sizess, font and scrollbar width.
> 
> (2) Set the new font size.
> 
> (3) Set the new scrollbar width.
> 
> (4) Set the new pixel sizes to some calculated from the ones saved in
>      (1) and the scale factor used in (2).
> 
> To dethumbify he would have to
> 
> (5) Set the new font size to the one saved in (1).
> 
> (6) Set the new scrollbar width to the one saved in (1).
> 
> (7) Set the new frame pixel sizes to the ones saved in (1).
> 
> I don't know whether this correctly restores window start positions but
> at least it seems the only sane way to fix his problem with the current
> trunk.

I'd say we should try that.

> I see only two ways to solve this inconsistency:
> 
> (1) Find some way to synch with the window manager as we do on
>      GNU/Linux.

I don't see experts on board who would know how to do that.

> (2) Apply the size changes with the commented-out code.  The comment
>      motivating why we should not do this on Windows because of the
>      menubar wrapping issue doesn't make sense to me anyway: If we and
>      Windows can handle wrapping, we'll do that when Windows gets back to
>      us.  And the worst thing that could happen to us is that parts of
>      the frame (including the modeline) might get obscured.  But this is
>      something I plan to do anyway when shrinking a frame below the
>      minimum size to accomodate all of its windows.

We could uncomment that code and see what trouble, if any, it causes.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > We could uncomment that code and see what trouble, if any, it causes.

Done in revision 115521.  The code is executed, however, iff the new
variable `w32-enable-frame-resize-hack' is t.  So after getting the new
version, Drew can try whether setting this variable changes the behavior
in his sense.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Sat, 14 Dec 2013 12:22:28 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
>  > We could uncomment that code and see what trouble, if any, it causes.
> 
> Done in revision 115521.  The code is executed, however, iff the new
> variable `w32-enable-frame-resize-hack' is t.

I'd say that variable should be t by default.  Otherwise, we will
never know if it does any trouble until it's too late.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> I'd say that variable should be t by default.  Otherwise, we will
> never know if it does any trouble until it's too late.

Let's first see whether it helps at all.  What I did was to emulate
something like "Drew could you try this patch for w32term.c?".

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Sat, 14 Dec 2013 14:45:47 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
> > I'd say that variable should be t by default.  Otherwise, we will
> > never know if it does any trouble until it's too late.
> 
> Let's first see whether it helps at all.

It does for me, so why shouldn't it for Drew?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> It does for me, so why shouldn't it for Drew?

Because Drew's special.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Sat, 14 Dec 2013 18:17:08 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
> > It does for me, so why shouldn't it for Drew?
> 
> Because Drew's special.

I thought I was special, too.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> I thought I was special, too.

I never met anyone as patient as you on this list.
So you're special too, but in the opposite sense.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 > I'd say that variable should be t by default.

Should be t by default now.  If there are no problems in the next weeks
I'll hardcode the behavior.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > I'd say that variable should be t by default.
> 
> Should be t by default now.  If there are no problems in the next weeks
> I'll hardcode the behavior.

Great; thanks.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

>  > We could uncomment that code and see what trouble, if any, it causes.
> 
> Done in revision 115521.  The code is executed, however, iff the new
> variable `w32-enable-frame-resize-hack' is t.  So after getting the new
> version, Drew can try whether setting this variable changes the behavior
> in his sense.

Yes, thank you very much.  Haven't bothered to test much, but setting that
variable to non-nil seems to remove the regression.

Thanks very much, to both of you, and to Juanma for providing the Windows
builds.  This bug fix makes a big difference for me.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Lars Ingebrigtsen]

Drew Adams <drew.adams@oracle.com> writes:

>>  > We could uncomment that code and see what trouble, if any, it causes.
>> 
>> Done in revision 115521.  The code is executed, however, iff the new
>> variable `w32-enable-frame-resize-hack' is t.  So after getting the new
>> version, Drew can try whether setting this variable changes the behavior
>> in his sense.
>
> Yes, thank you very much.  Haven't bothered to test much, but setting that
> variable to non-nil seems to remove the regression.
>
> Thanks very much, to both of you, and to Juanma for providing the Windows
> builds.  This bug fix makes a big difference for me.

This was a very long thread, but I think the conclusion is that this bug
was fixed.  Closing.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Drew Adams]

> This was a very long thread, but I think the conclusion is that this
> bug was fixed.  Closing.

Yes, it was fixed.  Thx.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

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

 >     (modify-frame-parameters
 >      (selected-frame) (list (cons 'font new-font)
 >                 (cons 'scroll-bar-width 6)))))

What happes is that when we ask Windows to change the frame's size, we
don't record the new sizes.  When we ask Windows to change the scrollbar
width, we start again with the old sizes.  I can handle this case by
commenting in some code in w32term.c as in the attached diff.  But that
code was commented our for a reason.  So I don't know what to do.

martin

PS: I don't know why it worked earlier.  In principle, the potential for
this bug was always here.

[-- Attachment #2: w32term.diff --]
[-- Type: text/plain, Size: 997 bytes --]

=== modified file 'src/w32term.c'
--- src/w32term.c	2013-12-07 17:48:52 +0000
+++ src/w32term.c	2013-12-10 14:52:22 +0000
@@ -5726,7 +5726,7 @@
 		       SWP_NOZORDER | SWP_NOMOVE | SWP_NOACTIVATE);
   }
 
-#if 0
+/** #if 0 **/
   /* The following mirrors what is done in xterm.c. It appears to be
      for informing lisp of the new size immediately, while the actual
      resize will happen asynchronously. But on Windows, the menu bar
@@ -5754,7 +5754,7 @@
 
      We pass 1 for DELAY since we can't run Lisp code inside of
      a BLOCK_INPUT.  */
-  change_frame_size (f, width, height, 0, 1, 0, 0);
+  change_frame_size (f, width, height, 0, 1, 0, pixelwise);
   FRAME_PIXEL_WIDTH (f) = pixelwidth;
   FRAME_PIXEL_HEIGHT (f) = pixelheight;
 
@@ -5772,7 +5772,7 @@
      Actually checking whether it is outside is a pain in the neck,
      so don't try--just let the highlighting be done afresh with new size.  */
   cancel_mouse_face (f);
-#endif
+/** #endif **/
 
   unblock_input ();
 }

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Tue, 10 Dec 2013 11:49:40 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 16028@debbugs.gnu.org
> 
> Yet simpler:

What do you get on X with this recipe?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> What do you get on X with this recipe?

The frame's pixel size shrinks from 744x630 to 587x455.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Tue, 10 Dec 2013 17:51:54 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 16028@debbugs.gnu.org
> 
> > What do you get on X with this recipe?
> 
> The frame's pixel size shrinks from 744x630 to 587x455.

On Windows it shrinks for me from 672x608 to 666x600.  Is that what
you see?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

> On Windows it shrinks for me from 672x608 to 666x600.  Is that what
> you see?

Yes.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Fri, 06 Dec 2013 17:20:55 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 16028@debbugs.gnu.org
> 
> IIUC for some reason setting the font apparently doesn't want to resize
> the frame immediately.

It's redisplay that actually does that, isn't it?

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

>> IIUC for some reason setting the font apparently doesn't want to resize
>> the frame immediately.
> 
> It's redisplay that actually does that, isn't it?

Or should do that.  x_set_font does a lot to make redisplay happen.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Fri, 06 Dec 2013 19:57:09 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
> x_set_font does a lot to make redisplay happen.

You mean the call to clear_current_matrices?  AFAIR, that's not
enough: it just ensures that _when_ redisplay happens, every screen
line will get redrawn.  But it doesn't force redisplay.

Perhaps try calling fset_redisplay for that frame.

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> x_set_font does a lot to make redisplay happen.
 >
 > You mean the call to clear_current_matrices?  AFAIR, that's not
 > enough: it just ensures that _when_ redisplay happens, every screen
 > line will get redrawn.  But it doesn't force redisplay.
 >
 > Perhaps try calling fset_redisplay for that frame.

If there are no errors, x_set_font inevitably calls x_new_font which on
window inevitably calls x_set_window_size which inevitably calls
my_set_window_pos.  Or do you see some way out for this?  So my only
explanation is that something in Drew's setup signals an error which
causes this to return earlier.

BTW I could hardly analyze this at the moment because now I'm bitten by
the "modeline doesn't update correctly" virus.  `find-tag-noselect',
when trying to go to the definition of x_new_font, switches from
nsterm.m to w32term.c to xterm.c as expected but after going to nsterm.m
the modeline buffer id is stuck at nsterm.m.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Eli Zaretskii]

> Date: Sat, 07 Dec 2013 10:46:44 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, 16028@debbugs.gnu.org
> 
>  >> x_set_font does a lot to make redisplay happen.
>  >
>  > You mean the call to clear_current_matrices?  AFAIR, that's not
>  > enough: it just ensures that _when_ redisplay happens, every screen
>  > line will get redrawn.  But it doesn't force redisplay.
>  >
>  > Perhaps try calling fset_redisplay for that frame.
> 
> If there are no errors, x_set_font inevitably calls x_new_font which on
> window inevitably calls x_set_window_size which inevitably calls
> my_set_window_pos.

But my_set_window_pos just tells Windows to redraw the frame according
to the current dimensions.  It's the current dimensions that need to
be changed, and that is done by redisplay, when it notices that the
font was changed and therefore the dimensions of the glyph matrices
need to be updated.

> BTW I could hardly analyze this at the moment because now I'm bitten by
> the "modeline doesn't update correctly" virus.  `find-tag-noselect',
> when trying to go to the definition of x_new_font, switches from
> nsterm.m to w32term.c to xterm.c as expected but after going to nsterm.m
> the modeline buffer id is stuck at nsterm.m.

Probably due to Stefan's changes.  "M-x redraw-display RET" should put
you out of your misery.  (It's entirely possible that just "M-x" will
do.)

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[martin rudalics]

 >> If there are no errors, x_set_font inevitably calls x_new_font which on
 >> window inevitably calls x_set_window_size which inevitably calls
 >> my_set_window_pos.
 >
 > But my_set_window_pos just tells Windows to redraw the frame according
 > to the current dimensions.  It's the current dimensions that need to
 > be changed, and that is done by redisplay, when it notices that the
 > font was changed and therefore the dimensions of the glyph matrices
 > need to be updated.

my_set_window_pos sends a resize request to Windows so the frame size
should visibly change.  redisplay then can do whatever it wants - but it
can't undo the frame size change.

 >> BTW I could hardly analyze this at the moment because now I'm bitten by
 >> the "modeline doesn't update correctly" virus.  `find-tag-noselect',
 >> when trying to go to the definition of x_new_font, switches from
 >> nsterm.m to w32term.c to xterm.c as expected but after going to nsterm.m
 >> the modeline buffer id is stuck at nsterm.m.
 >
 > Probably due to Stefan's changes.  "M-x redraw-display RET" should put
 > you out of your misery.  (It's entirely possible that just "M-x" will
 > do.)

I filed a bug report.

martin

bug#16028: 24.3.50; Latest build completely breaks my thumnail frames code

[Stefan Monnier]

> OK, I found that adding a (sit-for 0) after this call in
> `thumfr-thumbify-frame' fixes the problem:
[...]
> Do I need to do that in my code,

No.  It's simply a bug that we need to fix.


        Stefan