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

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

[Drew Adams]

The regression was introduced after this build:

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-06-01 on ODIEONE
Repository revision: 117212 michael.albinus@gmx.de-20140601104945-g88x0mwrx=
orz302h
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=3D/c/Devel/emacs/snapshot/trunk
 --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3'
 LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1
 -Ic:/Devel/emacs/include''

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-05-25 on ODIEONE
Repository revision: 117153 tsdh@gnu.org-20140525174054-vzeh4zeg00a1ley8
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=3D/c/Devel/emacs/snapshot/trunk
 --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3'
 LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1
 -Ic:/Devel/emacs/include''

and before this build, one week later:

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-06-01 on ODIEONE
Repository revision: 117212 michael.albinus@gmx.de-20140601104945-g88x0mwrx=
orz302h
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=3D/c/Devel/emacs/snapshot/trunk
 --enable-checking=3Dyes,glyphs 'CFLAGS=3D-O0 -g3'
 LDFLAGS=3D-Lc:/Devel/emacs/lib 'CPPFLAGS=3D-DGC_MCHECK=3D1
 -Ic:/Devel/emacs/include''

Recipe to repro:

1. emacs -Q

2. Load library hexrgb.el, then library palette.el. Both available from
   Emacs Wiki.
   http://www.emacswiki.org/emacs-en/download/hexrgb.el
   http://www.emacswiki.org/emacs-en/download/palette.el

3. M-x set-variable debug-on-error t RET

4. M-x palette RET RET ; Opens color palette for an arbitrary color.

5. You get this backtrace:

Debugger entered--Lisp error: (error "Window #<window 8 on Palette (Hue x S=
aturation)> too small for splitting 3")
  signal(error ("Window #<window 8 on Palette (Hue x Saturation)> too small=
 for splitting 3"))
  error("Window %s too small for splitting 3" #<window 8 on Palette (Hue x =
Saturation)>)
  byte-code("...
  split-window(#<window 8 on Palette (Hue x Saturation)> 100 t)
  (let* ((pop-up-frames t) (window-min-width 5) (fit-frame-inhibit-fitting-=
flag t) (temp-buffer-setup-hook nil) (temp-buffer-show-functions nil) (widt=
h 100) (height 100) (stringlen (* width height))) (set-buffer (get-buffer-c=
reate "Palette (Hue x Saturation)")) (make-variable-frame-local (quote 1on1=
-change-cursor-on-input-method-flag)) (modify-frame-parameters (make-frame =
(list (quote (menu-bar-lines . 0)) (quote (tool-bar-lines . 0)) (quote (lef=
t-fringe . 0)) (quote (right-fringe . 0)) (quote (fringe . 0)) (quote (heig=
ht . 100)) (quote (width . 115)) (quote (minibuffer)) (quote (vertical-scro=
ll-bars)) (quote (cursor-type . box)) (quote (background-color . "Black")) =
(quote (mouse-color . "Black")) (quote (cursor-color . "Black")) (cons (quo=
te font) palette-font))) (quote ((1on1-change-cursor-on-input-method-flag))=
)) (let* ((old-dir default-directory) (buf (save-current-buffer (set-buffer=
 (get-buffer-create "Palette (Hue x Saturation)")) (prog1 (current-buffer) =
(kill-all-local-variables) (setq default-directory old-dir) (setq buffer-re=
ad-only nil) (setq buffer-file-name nil) (setq buffer-undo-list t) (let (..=
. ...) (erase-buffer) (run-hooks ...))))) (standard-output buf)) (prog1 (pr=
ogn (let* ((cells (make-string stringlen 32)) (hue 0.999999) (sat 1.0) (ind=
ex 0) (col "#000000000000") (hhh 0) (sss 0)) (while (< index stringlen) (se=
tq sss 0) (while (< sss height) (setq hhh 0 hue 1.0) (while ... ... ... ...=
) (setq sat ... sss ...))) (set-buffer "Palette (Hue x Saturation)") (setq =
sss 0 index 0) (while (< sss height) (insert (substring cells index ...) 10=
) (setq sss (1+ sss) index (+ index width))))) (internal-temp-output-buffer=
-show buf))) (select-window (get-buffer-window "Palette (Hue x Saturation)"=
 (quote visible))) (set-window-dedicated-p (selected-window) t) (setq heade=
r-line-format nil window-size-fixed t) (palette-mode) (setq buffer-read-onl=
y t) (split-window (selected-window) width t) (palette-swatch) (palette-swa=
tch t) (split-window (selected-window) 10 t) (palette-brightness-scale) (se=
lect-window (get-buffer-window "Palette (Hue x Saturation)" (quote visible)=
)))
  palette("")
  funcall-interactively(palette "")
  call-interactively(palette record nil)
  command-execute(palette record)
  execute-extended-command(nil "palette")
  funcall-interactively(execute-extended-command nil "palette")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

6. I'm sorry to say that I tried to trace this, in detail, from the
   beginning (in `emacs -Q') using `debug-on-entry' for function
   `palette', and the error was not raised.  And yet the error is 100%
   reproducible...  Perhaps the debugger interacts in some way with
   the (window-splitting?) code.

Sorry, I don't have a simpler recipe than this.

In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
 of 2014-08-15 on LEG570
Bzr revision: 117706 rgm@gnu.org-20140815043406-p5hbu97cbm7pulcn
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --enable-checking 'CFLAGS=3D-O0 -g3' CPPFLAGS=3D-DGLYPH_DEBUG=
=3D1'

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

[Drew Adams]

Clarification:

0. I meant after the build of 5-25 (copy-pasted the 6-01 build info
first).  However, see below, #2.

1. The error is raised about half the time, and seemingly randomly.
At the prompt, enter the same color name each time (e.g. `blue'),
for consistency.

You can repeatedly try command `palette', and see that sometimes
the error is raised, sometimes not.

You can quit the palette using `q' (in the small palette frame/buffer).
That kills the buffers used for the palette and deletes its frame.

When the error is raised, another frame is opened also, for some reason,
showing only the main palette buffer but with a large char size. Just
close that extra frame and then use `q' in the (small) palette frame, to
be able to repeat the command.

2. I was wrong that the bug was introduced after 2014-05-25.
I can get the same error (also randomly) in that build.  Same thing
with older builds, back to 2013-08-02.

However, I get no error with a build from 2013-07-21 (or earlier),
no matter how many times I try.  So the regression seems to have
been introduced between these two builds:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-07-21 on ODIEONE
Bzr revision: 113485 lekktu@gmail.com-20130722012547-e3b7qxn1dba5vf20
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-08-02 on ODIEONE
Bzr revision: 113660 lekktu@gmail.com-20130802160313-rbi3o6322mz0m3ye
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

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

[Alan Third]

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

> Recipe to repro:
>
> 1. emacs -Q
>
> 2. Load library hexrgb.el, then library palette.el. Both available from
>    Emacs Wiki.
>    http://www.emacswiki.org/emacs-en/download/hexrgb.el
>    http://www.emacswiki.org/emacs-en/download/palette.el
>
> 3. M-x set-variable debug-on-error t RET
>
> 4. M-x palette RET RET ; Opens color palette for an arbitrary color.
>
> 5. You get this backtrace:

Hi Drew,

This is pretty old, but I can't reproduce it on master (NS port). Do you
know if it's still a problem?
-- 
Alan Third

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

[Drew Adams]

> This is pretty old, but I can't reproduce it on master (NS port). Do you
> know if it's still a problem?

Yes, 100% reproducible, on MS Windows, at least, using Emacs 25.1:

In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

I just followed the recipe in the bug report.

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

[Noam Postavsky]

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

On Fri, Sep 30, 2016 at 5:12 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> This is pretty old, but I can't reproduce it on master (NS port). Do you
>> know if it's still a problem?
>
> Yes, 100% reproducible, on MS Windows, at least, using Emacs 25.1:
>
> In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
>  of 2016-09-17 built on LAPHROAIG
> Windowing system distributor 'Microsoft Corp.', version 6.1.7601
> Configured using:
>  'configure --without-dbus --without-compress-install CFLAGS=-static'
>
> I just followed the recipe in the bug report.
>
>
>

Could not reproduce here, with Windows 10. No windows were split, I
instead got 2 frames titled "Palette (Hue x Saturation)", a narrow one
and a normal sized one.

In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
 of 2016-09-17 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 10.0.14393
Configured using:
 'configure --without-dbus --without-compress-install CFLAGS=-static'

[-- Attachment #2: bug-18930-palette-frames.png --]
[-- Type: image/png, Size: 88740 bytes --]

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

[Drew Adams]

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

> >> This is pretty old, but I can't reproduce it on master (NS port). Do you
> >> know if it's still a problem?
> >
> > Yes, 100% reproducible, on MS Windows, at least, using Emacs 25.1:
> >
> > In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
> >  of 2016-09-17 built on LAPHROAIG
> > Windowing system distributor 'Microsoft Corp.', version 6.1.7601
> > Configured using:
> >  'configure --without-dbus --without-compress-install CFLAGS=-static'
> >
> > I just followed the recipe in the bug report.
> 
> Could not reproduce here, with Windows 10. No windows were split, I
> instead got 2 frames titled "Palette (Hue x Saturation)", a narrow one
> and a normal sized one.
> 
> In GNU Emacs 25.1.1 (x86_64-w64-mingw32)
>  of 2016-09-17 built on LAPHROAIG
> Windowing system distributor 'Microsoft Corp.', version 10.0.14393
> Configured using:
>  'configure --without-dbus --without-compress-install CFLAGS=-static'

Interesting.  I'm using Windows 7.  Is this what `(frame-parameters)'
tells you, for the font info?

(font . "-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1") (font-backend uniscribe gdi)

What is the value of variable `palette-font'?  This is what mine is
(by default, with emacs -Q):

"-outline-Courier-normal-normal-normal-mono-5-*-*-*-c-*-iso8859-1"

----

The screenshot you attached shows that there are at least
some other problems.  This is what you should see:
https://www.emacswiki.org/emacs/ColorPaletteScreenshot

There should be a single frame (besides the original one),
with 3 windows:

* large hue window at left
* narrow swatch window to its right
* very-narrow brightness window at the right edge

And the frame should have no tool-bar, fringe, or minibuffer.

This is what the code does (before creating other windows etc.):

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

Your screenshot seems to show two frames, with the larger one
(behind the narrower one) showing tool-bar, fringe, and minibuffer.
The larger one is showing only the hue buffer (and with a large font).
The smaller one seems to show the hue buffer (at the left) and the
brightness buffer (to the left of the wide black buffer).  And it
shows the swatch buffer (the echo area says that the current color
is gray61).  But it also shows 3 black windows.

I see something similar (equally broken in Emacs 24 and 25) -
see attached screenshot.  But in my case the minibuffer of the
original frame (buffer *scratch*) says this:

Window #<window 8 on Palette (Hue x Saturation)> too small for splitting.

(That's without setting `debug-on-error' to t.  With the value `t'
things are the same, but with another frame for the backtrace and
no error message in the *scratch* frame's echo area.)

There should be only one frame created, not two, and it should
have no tool-bar, fringe, or minibuffer.  The only other frame
should be the original one, which should show the original
buffer, *scratch*.

More info about what you (and I) should see:
https://www.emacswiki.org/emacs/ColorPalette

You didn't get the error, so presumably your window was not too
small to split.  Otherwise, things are just as broken for you, it
seems.  Did you get any relevant messages in *Messages*?  What
happens if you try a larger or smaller font for `palette-font'?

This what `C-h v features' shows, for me (nothing extra, just
hexrgb.el and palette.el loaded):

(debug cus-edit wid-edit cus-start cus-load thingatpt help-fns
 help-mode easymenu palette eyedropper derived hexrgb cl-macs cl
 gv cl-loaddefs pcase cl-lib dired time-date mule-util tooltip
 eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
 mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win
 tool-bar dnd fontset image regexp-opt fringe tabulated-list
 newcomment elisp-mode lisp-mode prog-mode register page menu-bar
 rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
 syntax facemenu font-core frame cl-generic cham georgian
 utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
 japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
 european ethiopic indian cyrillic chinese charscript case-table
 epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded
 nadvice loaddefs button faces cus-face macroexp files text-properties
 overlay sha1 md5 base64 format env code-pages mule custom widget
 hashtable-print-readable backquote w32notify w32 multi-tty
 make-network-process emacs)

[-- Attachment #2: throw-emacs-bug-18390.png --]
[-- Type: image/png, Size: 59453 bytes --]

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

[npostavs]

retitle 18390 [w32] 24.4.50; REGRESSION: `split-window' error
quit

Drew Adams <drew.adams@oracle.com> writes:
> The screenshot you attached shows that there are at least
> some other problems.  This is what you should see:
> https://www.emacswiki.org/emacs/ColorPaletteScreenshot

Hmm, I see the correct thing on my GNU/Linux box, so this problem seems
to be Windows specific.  I will investigate further next week.

In GNU Emacs 25.1.27 (x86_64-unknown-linux-gnu, X toolkit)
 of 2016-09-18 built on zony
Repository revision: f0eb70d8935be90f7c03e187c12d9b60e7214cc6
Windowing system distributor 'The X.Org Foundation', version 11.0.11804000
Configured using:
 'configure --cache-file=../opt-config.cache 'CFLAGS=-O2 -g3
 -march=native' --enable-checking MAKEINFO=makeinfo-4.13a
 --with-x-toolkit=lucid --without-toolkit-scroll-bars --with-gif=no
 --with-jpeg=no'

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

[Drew Adams]

> Hmm, I see the correct thing on my GNU/Linux box, so this problem seems
> to be Windows specific.  I will investigate further next week.

Great.  Thank you.

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

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Fri, 30 Sep 2016 17:33:41 -0400
> Cc: Alan Third <alan@idiocy.org>, 18390@debbugs.gnu.org
> 
> Could not reproduce here, with Windows 10. No windows were split, I
> instead got 2 frames titled "Palette (Hue x Saturation)", a narrow one
> and a normal sized one.

What is the width, in columns, of the wider frame you get?

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

[Drew Adams]

> Could not reproduce here, with Windows 10. No windows were split, I
> instead got 2 frames titled "Palette (Hue x Saturation)", a narrow one
> and a normal sized one.

Did you try repeatedly?  Please see the part of the bug thread
where I mention that the error occurs seemingly randomly - not
every time.  Maybe about 1/2 the time.

Emacs behavior changed suddenly, around the time I mentioned.
From this working 100% of the time before that, it now works
only some of the time, and some of the time the bug is manifested.

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

[Eli Zaretskii]

> Date: Fri, 30 Sep 2016 14:12:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 18390@debbugs.gnu.org
> 
> > This is pretty old, but I can't reproduce it on master (NS port). Do you
> > know if it's still a problem?
> 
> Yes, 100% reproducible, on MS Windows, at least, using Emacs 25.1:

The backtrace shows that this is the reason for signaling the error:

  split-window(#<window 8 on Palette (Hue x Saturation)> 100 t)

This requests to split an 80-column window while leaving the original
window 100 columns, which is clearly impossible.  So why is this a
bug in Emacs and not in palette.el?

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

[Alan Third]

On Sat, Oct 01, 2016 at 10:44:46AM +0300, Eli Zaretskii wrote:
> The backtrace shows that this is the reason for signaling the error:
> 
>   split-window(#<window 8 on Palette (Hue x Saturation)> 100 t)
> 
> This requests to split an 80-column window while leaving the original
> window 100 columns, which is clearly impossible.  So why is this a
> bug in Emacs and not in palette.el?

I can’t see how you know it’s an 80 column window, could you explain
it to me?

Looking at the code in palette.el, it requests a 115 character wide
frame, is it possible that Emacs will return a smaller than requested
frame?

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

If it is then it’s up to palette.el to check what size of frame it
actually got back before trying to split the windows.
-- 
Alan Third

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

[Eli Zaretskii]

> Date: Sat, 1 Oct 2016 14:01:44 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: Drew Adams <drew.adams@oracle.com>, 18390@debbugs.gnu.org
> 
> On Sat, Oct 01, 2016 at 10:44:46AM +0300, Eli Zaretskii wrote:
> > The backtrace shows that this is the reason for signaling the error:
> > 
> >   split-window(#<window 8 on Palette (Hue x Saturation)> 100 t)
> > 
> > This requests to split an 80-column window while leaving the original
> > window 100 columns, which is clearly impossible.  So why is this a
> > bug in Emacs and not in palette.el?
> 
> I can’t see how you know it’s an 80 column window, could you explain
> it to me?

The default width of an Emacs window displayed by "emacs -Q" is 80
columns.  And that is the width of a window I see when I repeat Drew's
recipe and get the same error signaled as in his report.

> Looking at the code in palette.el, it requests a 115 character wide
> frame, is it possible that Emacs will return a smaller than requested
> frame?

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.

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?

> 
>     (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)))
> 
> If it is then it’s up to palette.el to check what size of frame it
> actually got back before trying to split the windows.

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

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

[Alan Third]

On Sat, Oct 01, 2016 at 06:44:50PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 1 Oct 2016 14:01:44 +0100
> > From: Alan Third <alan@idiocy.org>
> > Cc: Drew Adams <drew.adams@oracle.com>, 18390@debbugs.gnu.org
> > 
> > I can’t see how you know it’s an 80 column window, could you explain
> > it to me?
> 
> The default width of an Emacs window displayed by "emacs -Q" is 80
> columns.  And that is the width of a window I see when I repeat Drew's
> recipe and get the same error signaled as in his report.

Sorry, I didn’t realise you were repeating it. I thought you could see
that in the backtrace output in the original bug report and wondered
why I couldn’t.

> > Looking at the code in palette.el, it requests a 115 character wide
> > frame, is it possible that Emacs will return a smaller than requested
> > frame?
> 
> 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.
> 
> Actually, adding a (sit-for 0) might be all that's needed, if this is
> the problem (which I'm not at all sure).

This makes some sense to me, palette.el isn’t doing that much between
creating the frame and splitting the windows.

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

That’s what I was trying to do.

-- 
Alan Third

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.

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

[Drew Adams]

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

FWIW, I've attached screenshots from my setup (not emacs -Q),
from Emacs 23.4 (which is the same as Emacs 22), Emacs 24.3,
and Emacs 24.4.

It is Emacs 24.4 that manifests the bug of this report (but
the bug is not shown in the screenshot).

You can see that already in 24.3 the black lines separating
the windows are doubly thick.

In Emacs 24.4, there is the added glitch that there is an extra
blue line in the brightness window (rightmost window).

All three screenshots show the non-bug condition of the frame.
I present them just to show that things have changed in Emacs.

I can live with the changed behavior (though I don't understand
it - in particular, the thin blue line).  I can try to debug
that separately.  But I thought it might help to show what
happens when this bug does not manifest itself, as well as to
show some of what has changed in Emacs.  The code is the same,
and is pretty straightforward.

[-- Attachment #2: throw-palette-emacs-24-3.png --]
[-- Type: image/png, Size: 19787 bytes --]

[-- Attachment #3: throw-palette-emacs-23.4.png --]
[-- Type: image/png, Size: 16877 bytes --]

[-- Attachment #4: throw-palette-emacs-24.4.png --]
[-- Type: image/png, Size: 23082 bytes --]

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

[Eli Zaretskii]

> Date: Sun, 2 Oct 2016 14:03:49 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 18390@debbugs.gnu.org
> 
> > 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?

These questions are premature.  They might or might not be relevant to
the issue at hand, but we cannot decide that yet, at least I can't.

In general, the fact is that some/most changes in frame geometry are
performed asynchronously, and that has been like that "forever".  But
I'm not at all sure yet this is a factor in this case.

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

It's not a bundled package, so the Emacs project is not responsible
for it and doesn't need to look into its code.  Its developer should.

The original report shows an error that is signaled correctly; if you
say that this didn't happen with older versions, then the problem is
elsewhere, and it is the job of the palette.el's developers to uncover
that place and describe that problem.

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

I said I wasn't sure this was the problem, didn't I?  So again, these
questions are premature.

> The code does this:

Please present a code snippet that can be run; this one has "..." to
stand for something which may or may not be important (please
determine whether it is, don't just put it there if it isn't), and
even if I remove that and add closing parentheses to make this a valid
sexp, it signals an error:

  void variable palette-font

IOW, please show a minimal Lisp snippet that can be evaluated to
demonstrate correct behavior in some old version of Emacs and
incorrect behavior in a newer version.

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

I think this _might_ be a bug in palette.el.  When an unbundled
package stops working correctly, it's up to its developer to
investigate and provide clear evidence that some core API is broken or
changed in incompatible ways with no documented way to get the old
behavior.  Until such evidence is present, it's unreasonable to expect
the core maintainers to study code they are unfamiliar with and not
responsible for.

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

And we won't see that way until we have a clear understanding which
part of the code behaves differently, and why.  We don't yet
understand that at this time.

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

Please present the minimum Lisp snippet that shows this semi-random
behavior in recent Emacs versions, and we can then continue discussing
this in constructive ways.

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

[Noam Postavsky]

tag 18390 = moreinfo
quit

On Mon, Oct 3, 2016 at 2:39 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> Please present the minimum Lisp snippet that shows this semi-random
> behavior in recent Emacs versions, and we can then continue discussing
> this in constructive ways.

Yes, it seems this problem is very dependent on font and window size
configurations, so it's difficult to tell what's going on.

Below, I've include some answers to questions asked upthread, in case
they might be helpful.

On Sun, Oct 2, 2016 at 5:03 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> Could not reproduce here, with Windows 10. No windows were split, I
>> instead got 2 frames titled "Palette (Hue x Saturation)", a narrow one
>> and a normal sized one.
>
> Did you try repeatedly?  Please see the part of the bug thread
> where I mention that the error occurs seemingly randomly - not
> every time.  Maybe about 1/2 the time.
>
> Emacs behavior changed suddenly, around the time I mentioned.
> From this working 100% of the time before that, it now works
> only some of the time, and some of the time the bug is manifested.

Ah, in message #16 it was described as 100% reproducible, so I didn't
realize it was non-deterministic. After trying it a few more times, I
did get the same error. In the error case I still get 2 frames, the
normal-sized one as before, but the smaller frame shows only the hue
buffer on the left, and blackness on the right. And there's a third
frame with the *Backtrace*.

On Sat, Oct 1, 2016 at 3:46 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Fri, 30 Sep 2016 17:33:41 -0400
>> Cc: Alan Third <alan@idiocy.org>, 18390@debbugs.gnu.org
>>
>> Could not reproduce here, with Windows 10. No windows were split, I
>> instead got 2 frames titled "Palette (Hue x Saturation)", a narrow one
>> and a normal sized one.
>
> What is the width, in columns, of the wider frame you get?

80, according to (frame-width). It's the same size as the initial
frame where *scratch* appears.

On Fri, Sep 30, 2016 at 6:39 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> Interesting.  I'm using Windows 7.  Is this what `(frame-parameters)'
> tells you, for the font info?
>
> (font . "-outline-Courier New-normal-normal-normal-mono-17-*-*-*-c-*-iso8859-1") (font-backend uniscribe gdi)

I have different fonts.

(font . "-outline-Courier New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1")
(font-backend uniscribe gdi)

>
> What is the value of variable `palette-font'?  This is what mine is
> (by default, with emacs -Q):
>
> "-outline-Courier-normal-normal-normal-mono-5-*-*-*-c-*-iso8859-1"

"-outline-Arial-normal-italic-normal-sans-5-*-*-*-p-*-iso8859-1"

>
> You didn't get the error, so presumably your window was not too
> small to split.  Otherwise, things are just as broken for you, it
> seems.  Did you get any relevant messages in *Messages*?  What
> happens if you try a larger or smaller font for `palette-font'?

Although the window/frame setup isn't quite right, I get the expected
stuff in *Messages*:

Loading palette...
Color: chocolate1, RGB: (1.0 0.4980392156862745 0.1411764705882353),
HSV: (0.06925418569254185 0.8588235294117648 1.0)

>
> This what `C-h v features' shows, for me (nothing extra, just
> hexrgb.el and palette.el loaded):

Almost the same:

(thingatpt help-fns help-mode easymenu cus-start cus-load palette
eyedropper derived hexrgb cl-macs cl gv cl-loaddefs pcase cl-lib
time-date mule-util tooltip eldoc electric uniquify ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win
w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese
eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook
help simple abbrev minibuffer cl-preloaded nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote w32notify w32 multi-tty make-network-process emacs)

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

[Drew Adams]

> > Did you try repeatedly?  Please see the part of the bug thread
> > where I mention that the error occurs seemingly randomly - not
> > every time.  Maybe about 1/2 the time.
> >
> > Emacs behavior changed suddenly, around the time I mentioned.
> > From this working 100% of the time before that, it now works
> > only some of the time, and some of the time the bug is manifested.
> 
> Ah, in message #16 it was described as 100% reproducible,

Sorry for not being clear enough.  I meant that the bug as reported
(as manifesting only some of the time) is reproducible in those builds
(and not at all in the earlier builds).  IOW, the problem reported
is still as reported.

> so I didn't
> realize it was non-deterministic. After trying it a few more times, I
> did get the same error. In the error case I still get 2 frames, the
> normal-sized one as before, but the smaller frame shows only the hue
> buffer on the left, and blackness on the right. And there's a third
> frame with the *Backtrace*.

If you turn off `debug-on-error' then you should see just what I
described (no `*Backtrace*' frame).

> > You didn't get the error, so presumably your window was not too
> > small to split.  Otherwise, things are just as broken for you, it
> > seems.  Did you get any relevant messages in *Messages*?  What
> > happens if you try a larger or smaller font for `palette-font'?
> 
> Although the window/frame setup isn't quite right, I get the expected
> stuff in *Messages*:
> 
> Loading palette...
> Color: chocolate1, RGB: (1.0 0.4980392156862745 0.1411764705882353),
> HSV: (0.06925418569254185 0.8588235294117648 1.0)

What happens if you use a larger or smaller font?

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

[Noam Postavsky]

On Mon, Oct 3, 2016 at 3:42 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> What happens if you use a larger or smaller font?

I don't know how.

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

[Drew Adams]

> > What happens if you use a larger or smaller font?
> 
> I don't know how.

Customize option `palette-font'?  If you look at the default value
in the code, you see "5" as the size.  Try a font with a different
size.

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

[Noam Postavsky]

On Tue, Oct 4, 2016 at 4:58 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> > What happens if you use a larger or smaller font?
>>
>> I don't know how.
>
> Customize option `palette-font'?  If you look at the default value
> in the code, you see "5" as the size.  Try a font with a different
> size.

I changed the "5" into "1" and then "10". In both cases I got the same
result as before, except the narrower frame was smaller and then
bigger, respectively.

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

[Drew Adams]

> > Customize option `palette-font'?  If you look at the default value
> > in the code, you see "5" as the size.  Try a font with a different
> > size.
> 
> I changed the "5" into "1" and then "10". In both cases I got the same
> result as before, except the narrower frame was smaller and then
> bigger, respectively.

OK.  Thanks for trying.

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

[Lars Ingebrigtsen]

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

Are you still seeing this issue in recent Emacs versions?  If so, do you
have a simple recipe to reproduce the problem?  If not, I doubt there'll
be any further progress here.

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

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

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Are you still seeing this issue in recent Emacs versions?  If so, do you
> have a simple recipe to reproduce the problem?  If not, I doubt there'll
> be any further progress here.

More information was requested, but no response was given within a
month, so I'm closing this bug report.  If the problem still exists,
please open a new bug report with a recipe for reproduction.

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

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

[Drew Adams]

> > Yes, 100% reproducible, on MS Windows, at least, using Emacs 25.1:
> 
> The backtrace shows that this is the reason for signaling the error:
> 
>   split-window(#<window 8 on Palette (Hue x Saturation)> 100 t)
> 
> This requests to split an 80-column window while leaving the original
> window 100 columns, which is clearly impossible.  So why is this a
> bug in Emacs and not in palette.el?

Uh, it works 100% of the time with builds prior to Emacs 24.4 -
more precisely, it works perfectly with Emacs 22, 23, 24.1, 24.2
and 24.3, as well as with pre-Emacs 24.4 builds through 2013-07-21.

The next build I have after that is 2013-08-02.  That build and
all later builds have the regression.

(This is all specified in the bug thread.)

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

[Eli Zaretskii]

> Date: Sun, 2 Oct 2016 14:03:39 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: alan@idiocy.org, 18390@debbugs.gnu.org
> 
> >   split-window(#<window 8 on Palette (Hue x Saturation)> 100 t)
> > 
> > This requests to split an 80-column window while leaving the original
> > window 100 columns, which is clearly impossible.  So why is this a
> > bug in Emacs and not in palette.el?
> 
> Uh, it works 100% of the time with builds prior to Emacs 24.4 -
> more precisely, it works perfectly with Emacs 22, 23, 24.1, 24.2
> and 24.3, as well as with pre-Emacs 24.4 builds through 2013-07-21.

That fact doesn't help with the above in any useful way.  If the Emacs
behavior have changed in some subtle ways since those versions, then
palette.el should have followed suit.

What I see in the failed code is quite clear: palette.el is asking
Emacs to do the impossible.  Why that happens is for the developer of
palette.el to investigate and tell.  It could be that eventually this
will lead to an Emacs bug, but in that case the bug should be found
where it really is and demonstrated to clearly indicate it's a core
bug, ideally without external packages at all.