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.