From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii 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> <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 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 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: 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 ) 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 ) 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 ) 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 ) 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 ) 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 ) 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 Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Oct 2016 06:40:01 +0000 Resent-Message-ID: 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 ) 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 ) 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 ) 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 ) 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 ) 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" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:123936 Archived-At: > Date: Sun, 2 Oct 2016 14:03:49 -0700 (PDT) > From: Drew Adams > 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.