From mboxrd@z Thu Jan  1 00:00:00 1970
Path: news.gmane.org!.POSTED!not-for-mail
From: Eli Zaretskii <eliz@gnu.org>
Newsgroups: gmane.emacs.bugs
Subject: bug#18390: 24.4.50; REGRESSION: `split-window' error
Date: Mon, 03 Oct 2016 09:39:50 +0300
Message-ID: <83vaxaos09.fsf@gnu.org>
References: <04dc6e08-382f-46a2-8d57-62522529e7c4@default>
	<m28tu914ww.fsf@breton.holly.idiocy.org>
	<901673d8-75c2-494f-956d-9f938a8e87b4@default> <83a8eoms29.fsf@gnu.org>
	<20161001130144.GA39607@breton.holly.idiocy.org>
	<83lgy8kr9p.fsf@gnu.org>
	<75deb4d8-48f0-43ef-814a-037e01190fdf@default>
Reply-To: Eli Zaretskii <eliz@gnu.org>
NNTP-Posting-Host: blaine.gmane.org
X-Trace: blaine.gmane.org 1475476821 15993 195.159.176.226 (3 Oct 2016 06:40:21 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Mon, 3 Oct 2016 06:40:21 +0000 (UTC)
Cc: alan@idiocy.org, 18390@debbugs.gnu.org
To: Drew Adams <drew.adams@oracle.com>
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Oct 03 08:40:16 2016
Return-path: <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Envelope-to: geb-bug-gnu-emacs@m.gmane.org
Original-Received: from lists.gnu.org ([208.118.235.17])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1bqwv8-0003Aq-JI
	for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Oct 2016 08:40:14 +0200
Original-Received: from localhost ([::1]:34049 helo=lists.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>)
	id 1bqwv7-0007mR-4d
	for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Oct 2016 02:40:13 -0400
Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52083)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1bqwv0-0007k9-Iq
	for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 02:40:07 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1bqwuw-00083O-4Y
	for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 02:40:06 -0400
Original-Received: from debbugs.gnu.org ([208.118.235.43]:36250)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1bqwuw-00083K-12
	for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 02:40:02 -0400
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
	(envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1bqwuv-0006dd-Sq
	for bug-gnu-emacs@gnu.org; Mon, 03 Oct 2016 02:40:01 -0400
X-Loop: help-debbugs@gnu.org
Resent-From: Eli Zaretskii <eliz@gnu.org>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Mon, 03 Oct 2016 06:40:01 +0000
Resent-Message-ID: <handler.18390.B18390.147547679025494@debbugs.gnu.org>
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 18390
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: unreproducible
Original-Received: via spool by 18390-submit@debbugs.gnu.org id=B18390.147547679025494
	(code B ref 18390); Mon, 03 Oct 2016 06:40:01 +0000
Original-Received: (at 18390) by debbugs.gnu.org; 3 Oct 2016 06:39:50 +0000
Original-Received: from localhost ([127.0.0.1]:42440 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces@debbugs.gnu.org>)
	id 1bqwuk-0006d8-Ir
	for submit@debbugs.gnu.org; Mon, 03 Oct 2016 02:39:50 -0400
Original-Received: from eggs.gnu.org ([208.118.235.92]:32826)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <eliz@gnu.org>) id 1bqwui-0006ct-UV
	for 18390@debbugs.gnu.org; Mon, 03 Oct 2016 02:39:49 -0400
Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <eliz@gnu.org>) id 1bqwuZ-00080h-4n
	for 18390@debbugs.gnu.org; Mon, 03 Oct 2016 02:39:43 -0400
Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53785)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@gnu.org>)
	id 1bqwuZ-00080b-13; Mon, 03 Oct 2016 02:39:39 -0400
Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4908
	helo=home-c4e4a596f7)
	by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
	(Exim 4.82) (envelope-from <eliz@gnu.org>)
	id 1bqwuX-0004hK-VE; Mon, 03 Oct 2016 02:39:38 -0400
In-reply-to: <75deb4d8-48f0-43ef-814a-037e01190fdf@default> (message from Drew
	Adams on Sun, 2 Oct 2016 14:03:49 -0700 (PDT))
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 208.118.235.43
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
	the Swiss army knife of text editors" <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <https://lists.gnu.org/mailman/options/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/archive/html/bug-gnu-emacs/>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Subscribe: <https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org
Original-Sender: "bug-gnu-emacs"
	<bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org>
Xref: news.gmane.org gmane.emacs.bugs:123936
Archived-At: <http://permalink.gmane.org/gmane.emacs.bugs/123936>

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