From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#25943: 21.5 Frame Display Difficulties Date: Thu, 09 Mar 2017 09:56:42 +0100 Message-ID: <58C118CA.8020908@gmx.at> References: <0b9853e8ecbdb18bb1b8c05347371a7e@127.0.0.1> <58B925A4.4060406@gmx.at> <58BA900B.6040708@gmx.at> <49adf8e1615512ac19189d75b5e04315@127.0.0.1> <58BE8138.1040607@gmx.at> <142b4d1d519a6bf87a5fe320d9eeb419@127.0.0.1> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1489049895 30780 195.159.176.226 (9 Mar 2017 08:58:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 9 Mar 2017 08:58:15 +0000 (UTC) Cc: 25943@debbugs.gnu.org To: david@ngdr.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Mar 09 09:58:10 2017 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 1cltte-0006sP-V3 for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Mar 2017 09:58:07 +0100 Original-Received: from localhost ([::1]:32838 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clttk-0003hy-RC for geb-bug-gnu-emacs@m.gmane.org; Thu, 09 Mar 2017 03:58:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49838) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cltte-0003hp-G3 for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2017 03:58:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clttb-000746-Br for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2017 03:58:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48931) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clttb-000742-7w for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2017 03:58:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cltta-0006Qv-UA for bug-gnu-emacs@gnu.org; Thu, 09 Mar 2017 03:58:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 09 Mar 2017 08:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25943 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 25943-submit@debbugs.gnu.org id=B25943.148904982724666 (code B ref 25943); Thu, 09 Mar 2017 08:58:02 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 9 Mar 2017 08:57:07 +0000 Original-Received: from localhost ([127.0.0.1]:47130 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cltsh-0006Pm-HP for submit@debbugs.gnu.org; Thu, 09 Mar 2017 03:57:07 -0500 Original-Received: from mout.gmx.net ([212.227.15.15]:64686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cltsg-0006PI-7r for 25943@debbugs.gnu.org; Thu, 09 Mar 2017 03:57:06 -0500 Original-Received: from [192.168.1.100] ([213.162.68.62]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MBFgr-1cvZ3q2lQj-00ABAy; Thu, 09 Mar 2017 09:56:55 +0100 In-Reply-To: <142b4d1d519a6bf87a5fe320d9eeb419@127.0.0.1> X-Provags-ID: V03:K0:CHp9JDcSIvZvRIYFSAwd82A5Dcml8eyYd+Vuvp0iLSYi1hbaOsE tgl+U4gmctDnvnAlK8A6dy8pgB55Ac0U+NiXpzbR8P/sSaQdYahzTHull9+46Wvb1EUD90t 9TMVoTxbePl046l+Fa+cs7jbiQfyuBCr9XgSROL8a/GjqA6OHrF8fo3D3Qc3M+q5r12JcLM kuyGpivl6PTSaaKXIxIew== X-UI-Out-Filterresults: notjunk:1;V01:K0:qhaO8R6xGEw=:HJVZAXNVXy/zwgNpdfK1qn Uh3UlQcEC0CTZ2dkF4opgWPN9AIHsjW7y2rgzbLkYp/PUY8nTWSH8xBSUMrPrtKhphiRba78r IejmVqFw8+BLYvmamQckvFHas2f916qR7MnfS0jW0W6DgPzLEztbGTjmNVTQO7vIJRhRT0coM PStT1pTMBWlvbBfRWTWScT7pxx0s0T1iJC2WdOlbWw7gef+IuhOkU5oIzDGnihzSn1DcBJqcU jX1wmPv5oAzI2CgH5yMdePxATX/Qz1fmTftMrKtsxvFwz+rLuBhLE+LOZ3AoUycCsc7HZpdFc T6vX2/MHV7tCTqFmEjtB5sj4/ZQooZ4TpvQ8lzrJ+fGCTMG5KckmwkbTnUbOJR269nhEoUWwq puj5ZRsppAlwlaVew1aKD2ufUJGeeY0DKxLLErKxhBmgdRCMpQQIiOnYgCyJGyLFjdn9XAdw+ UVGd6eiIwznMOcETK26Er0pER/gj9DnuILnZfpwzxvL7kUez5F8Ts1/8CPioFsOd9jMtmhB4c pjVZgIUlOv9j8pORvD+3i+0XE6zpoe9WaFE8JVC4siulw0kweVDqYSNNMnhntdYjNimAXgYXD B+y9DCJNppz+cuLByI4P1krYcHV+NZ+nXHt+UnJkdwF5+1MZH+U66YxMwMJddcOLVJHaOyFkg 9qdghBQzUWV+ZajOFAel57zLOmy5HVDV0nGSc+WFoQ8aohXqVNirvoOsXhZ1epAH+9VhIVPAT 1puvFmPArcTLWqALvbVp/EccBEleBaTO4FkbCoAYB0tM8HND17TWUUmfhuY05RE1Q29ixNel 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:130368 Archived-At: > It appears that you and I use our operating systems and emacs very > differently! You use one workspace and never change. I use nine > workspaces, run each application in its own workspace, often fullscree= n, The latter seems to indicate that popping up an additional frame on the same workspace is the exception, not the rule. > and flip between them according to need. I generally use one workspace, maximized frames and all sorts of key combinations to switch between frames and windows. > It sounds as though you use > mouse activated menus, scroll bars, and a mouse. In general only when testing or trying to reproduce scenarios described in bug reports. > Yes. It seems to me that problems one and two both are initialization= > faults in some code or other. So let's concentrate on these "initialization faults" first. The basic motivation for your code is that "Starting with a visible frame is tacky because of the flashing that results". Hence you want to start with an invisible frame and show it only after you're done with positioning and sizing it. In a nutshell, you do (let ((invoking-frame (selected-frame)) (simple-frame (make-frame '((visibility . nil))))) (set-frame-size simple-frame 60 6) (set-frame-position simple-frame -41 (frame-parameter invoking-frame 'top)) (select-frame-set-input-focus simple-frame)) This will first create a frame with some default size and position, then resize the frame and finally reposition it. While this might work some of the time with some window managers I wouldn't rely on it. As a rule, users should not specify frame positions manually. Window managers dislike it. Not because they think they are better at it but because it disturbs their usual flow of control. If you really need to position and size a new frame, please stick to the following rules: (1) Use frame parameters for specifying the position. First they give you more freedom. For example, you can't use =E2=80=98set-frame-pos= ition=E2=80=99 to put a frame at the right edge of your display. More importantly,= they allow Emacs to do its work _before_ the frame becomes visible. (2) Use frame parameters for specifying the size. Again this allows Emacs to do the associated calculations before the frame becomes visible. When specifying the frame position via a negative offset (your "-41"= above), rule (2) becomes even more important because Emacs has to calculate the prospective size of your frame before it can calculate= its prospective position. (3) Add a =E2=80=98user-position=E2=80=99 entry to your frame parameters.= It might not help with all but it might help with some window managers to clarify= your intentions. A sub-rule of (2): Use negative offsets with care. The original sin of the API of all window managing programs is that an application has to specify the size of the inner (aka "client") rectangle and the position of the outer (aka "display") rectangle. Extracting the size differences between these rectangles is difficult and sometimes virtually impossible (just think of wrapping tool or menu bars resulting from changing the major mode of a buffer shown in the selected window). Everything Emacs can provide here is just some approximative behavior. Consequently, I would suggest to rewrite the above form as follows: (let ((simple-frame (make-frame `((visibility . nil) (left . -41) (top . ,(frame-parameter nil 'top)) (width . 60) (height . 6))))) (select-frame-set-input-focus simple-frame)) Please try it and tell me whether it gives better results. Thanks, martin