bug#18390: 24.4.50; REGRESSION: `split-window' error

[Drew Adams]

> I don't really know what palette.el is doing, but it could be that it
> doesn't let the Emacs frame time to resize itself before splitting the
> window.

Huh?  Since when does Emacs-Lisp code need to add delays after
calling `make-frame', before splitting its window?  Why would
this be the responsibility of the code that calls `make-frame'?

Where does it say that `make-frame' is asynchronous, or that
it does not block Lisp execution until it is done doing its
job (meaning that the frame has been created).  It returns the
new frame.  What more can code do to know that the frame has
been created and displayed than to assume that the returned
frame is in fact the created-and-displayed frame?

> In any case, I once again ask the question: why should we assume it's
> a bug in Emacs, and not first try looking into what palette.el does?

No one asked you not to first look at what palette.el does.
On the contrary, please do.  I pointed to the code, and it is
pretty clear, I think.

> Actually, adding a (sit-for 0) might be all that's needed,
> if this is the problem (which I'm not at all sure).

1. Where are you suggesting to add `sit-for'?

2. Again, why should Emacs Lisp code suddenly be tasked with doing
   that, trying to sync frame creation and splitting its window?

3. How would you propose testing when the frame exists, is at the
   size specified by the call to `make-frame', and is ready to have
   its window split (without error)?

The code does this:

(let* ((pop-up-frames                   t)
       (window-min-width                5)
       (temp-buffer-setup-hook          nil)
       (temp-buffer-show-functions      nil)
       (width                           100)
       (height                          100)
       (stringlen                       (* width height)))
  (set-buffer (get-buffer-create "Palette (Hue x Saturation)"))
  (make-variable-frame-local '1on1-change-cursor-on-input-method-flag)
  (modify-frame-parameters
   (make-frame
    `((menu-bar-lines . 0) (tool-bar-lines . 0) (left-fringe . 0)
      (right-fringe . 0) (fringe . 0) (height . 100) (width . 115)
      (minibuffer) (vertical-scroll-bars) (cursor-type . box)
      (background-color . "Black") (mouse-color . "Black")
      (cursor-color . "Black") ,(cons 'font palette-font)))
   '((1on1-change-cursor-on-input-method-flag)))

  (with-output-to-temp-buffer "Palette (Hue x Saturation)"
    ...
    (select-window (get-buffer-window
                     "Palette (Hue x Saturation)" 'visible))
    ;; Next 2 lines prevent using a tab bar if `tabbar-mode' is on.
    (set-window-dedicated-p (selected-window) t)
    (setq header-line-format  nil
          window-size-fixed   t)
    (palette-mode)
    (setq buffer-read-only  t)
    (split-window (selected-window) width t)
    (palette-swatch)
    (palette-swatch t)
    (split-window (selected-window) 10 t)
    (palette-brightness-scale)
    (select-window (get-buffer-window "Palette (Hue x Saturation)"
                   'visible)))
(redisplay t) ; Get rid of any header line from `tabbar-mode' etc.

Functions `palette-swatch' and `palette-brightness-scale' take
care of the two smaller windows.  They each bind
`split-window-preferred-function' to (lambda (w) (eq w (get-lru-window))).
The former then calls `display-buffer'; that latter uses
`with-output-to-temp-buffer' to display its buffer.

It's not clear to me (1) why you think there is no Emacs bug
(regression, in fact) here, and (2) what you are suggesting user
code should need to do, to work around this "non-bug".

If I need to work around the regression, I will try to do so.
But I don't see why, and I don't see what the workaround is.

I do agree that it seems, from the fact that this still works
perfectly maybe half the time, that there might be some kind
of frame/window operation timing problem.  There does not seem
to be any logic problem.

But it is the case that with Emacs 24.3 and prior there is no
such timing problem: it just works, every time.