From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#18390: 24.4.50; REGRESSION: `split-window' error Date: Sun, 2 Oct 2016 14:03:49 -0700 (PDT) Message-ID: <75deb4d8-48f0-43ef-814a-037e01190fdf@default> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1475442779 11265 195.159.176.226 (2 Oct 2016 21:12:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 2 Oct 2016 21:12:59 +0000 (UTC) Cc: 18390@debbugs.gnu.org To: Eli Zaretskii , Alan Third Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Oct 02 23:12:55 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 1bqo40-0001Zy-K1 for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Oct 2016 23:12:49 +0200 Original-Received: from localhost ([::1]:60887 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqo3z-0007QA-2b for geb-bug-gnu-emacs@m.gmane.org; Sun, 02 Oct 2016 17:12:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39389) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqnvd-0001Zi-5m for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2016 17:04:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqnvX-0005NG-9Q for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2016 17:04:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:36091) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqnvX-0005NB-5T for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2016 17:04:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bqnvW-0005wj-VO for bug-gnu-emacs@gnu.org; Sun, 02 Oct 2016 17:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Oct 2016 21:04:02 +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.147544224022834 (code B ref 18390); Sun, 02 Oct 2016 21:04:02 +0000 Original-Received: (at 18390) by debbugs.gnu.org; 2 Oct 2016 21:04:00 +0000 Original-Received: from localhost ([127.0.0.1]:42279 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqnvT-0005wE-PO for submit@debbugs.gnu.org; Sun, 02 Oct 2016 17:04:00 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:33584) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqnvR-0005vy-8t for 18390@debbugs.gnu.org; Sun, 02 Oct 2016 17:03:57 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u92L3pgo019034 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 2 Oct 2016 21:03:51 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id u92L3pKR009115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 2 Oct 2016 21:03:51 GMT Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u92L3of6030879; Sun, 2 Oct 2016 21:03:50 GMT In-Reply-To: <83lgy8kr9p.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6753.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] 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:123923 Archived-At: > 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.