From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Newsgroups: gmane.emacs.bugs Subject: bug#25943: 21.5 Frame Display Difficulties Date: Fri, 10 Mar 2017 11:44:20 -0700 Message-ID: <2395d7c6fbe7358c894bc1406ffcbf45@127.0.0.1> 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> <58C118CA.8020908@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1489171523 5980 195.159.176.226 (10 Mar 2017 18:45:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 10 Mar 2017 18:45:23 +0000 (UTC) User-Agent: Tuxedo/0.1 Cc: "25943@debbugs.gnu.org" <25943@debbugs.gnu.org> To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 10 19:45:15 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 1cmPXH-0008JM-Qf for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Mar 2017 19:45:08 +0100 Original-Received: from localhost ([::1]:40527 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmPXN-0005QV-IX for geb-bug-gnu-emacs@m.gmane.org; Fri, 10 Mar 2017 13:45:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56311) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmPXG-0005P5-5n for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2017 13:45:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cmPXC-0005Gq-Np for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2017 13:45:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51771) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cmPXC-0005Gj-K2 for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2017 13:45:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cmPXC-0001al-Ce for bug-gnu-emacs@gnu.org; Fri, 10 Mar 2017 13:45:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 10 Mar 2017 18:45:01 +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.14891714636042 (code B ref 25943); Fri, 10 Mar 2017 18:45:01 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 10 Mar 2017 18:44:23 +0000 Original-Received: from localhost ([127.0.0.1]:49970 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmPWZ-0001ZN-ER for submit@debbugs.gnu.org; Fri, 10 Mar 2017 13:44:23 -0500 Original-Received: from magicmail03.frii.com ([216.17.135.172]:34687 helo=magic03.frii.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cmPWX-0001ZF-H6 for 25943@debbugs.gnu.org; Fri, 10 Mar 2017 13:44:22 -0500 Original-Received: (qmail 26290 invoked from network); 10 Mar 2017 18:44:20 -0000 Original-Received: from localhost (HELO mail.frii.com) (david@ngdr.net@127.0.0.1) by magic03.frii.net with SMTP (929c12b4-05c1-11e7-9be1-3799711a23f0); Fri, 10 Mar 2017 11:44:20 -0700 Original-Received: from c-67-165-221-44.hsd1.co.comcast.net ([67.165.221.44]) by mail.frii.com with HTTP (HTTP/1.1 POST); Fri, 10 Mar 2017 11:44:20 -0700 In-Reply-To: <58C118CA.8020908@gmx.at> X-Sender: david@ngdr.net X-MagicMail-OS: MagicMail 2.0-Stable X-MagicMail-UUID: 929c12b4-05c1-11e7-9be1-3799711a23f0 X-MagicMail-Authenticated: david@ngdr.net X-MagicMail-SourceIP: 127.0.0.1 X-MagicMail-RegexMatch: 2 X-MagicMail-EnvelopeFrom: 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:130450 Archived-At: Hello Martin, I am a bit surprised by the content of your reply. I wonder if I have offended you; if I have I apologize; I assure you I do not know how, nor was it intentional. In view of what you have written I do think that I need to do a reset and try to make clear how I see things. I have core code, extended over years, that has run successfully on emacs 18.n, 19.n, 20.n, 21.n, 22.n, and 23.n. The code, and emacs, have run successfully on numerous platforms and operating systems, the ones I remember being DEC/Unix, IBM/aix, PC/Windows NT, and PC/Linux(various). I cannot remember much about the window managers I have used, I just take what is there. Over the years I have become increasingly grateful for emacs because emacs has kept me insulated from the vagaries of the hardware and software on which I have been running. When moving to a new version of emacs, sometimes I have needed to make minor changes, and, since I have a small amount of C code that is necessary for me, I have always needed to modify a few C files, make update patches, etc.; but that is all, the lisp has gone on forever. Upgrading has been simple and, crucially, _possible_! It is not always possible with software to rehost. I want to emphasize the "insulated" part of what I have written. I have successfully transferred my code from emacs version to version, host machine to machine, run across the internet running on one OS and displaying on another, etc.; and all the time emacs has, very simply, got on with it. I am constantly staggered by the flexibility of emacs, at any time, and over time, and its ability, I repeat, to insulate me from the hardware and software changes that are occurring underneath the code that I write. Now I have to upgrade my OS and emacs version again. This time a couple of nasty things have happened. It is very simple: emacs 25.1 has failed. I have no reason to think that my code is faulty; it has not been changed and the same lisp code (not even a copy) is running right now on emacs 23.2 as it has run for a long, long, time on other versions. My code runs on 25.1 except for a couple of, for me, serious, display bugs. I submitted a bug report to the best of my ability; and I still hope that the bugs will be repaired; I still want to use emacs. The above is my starting point, not what you have written. In addition, there are other things that are disturbing. One is that you write "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." So, for the first time in a quarter of a century, I, an emacs user, have to concern myself with the window manager that I am using? Also: "While this might work some of the time with some window managers I wouldn't rely on it." So, successfully transferring emacs and my code in the way that I have in the past has been thrown out of the window, emacs is no longer going to handle such things as it has done so magnificently in the past? The second disturbing point is "If you really need to position and size a new frame, please stick to the following rules:". Sorry, but no. I am not a cowboy programmer; also I am quite compulsive about sticking to conventions and rules; generally, I find that to be good practice. But the rules that you have announced are there for the wrong reason: emacs 25.1 cannot do what its predecessors have done. It should not be the responsibility of a user to cover the failings of a new version of emacs. Thirdly, do you really think that my code is so simple, or so buggy, that I can zip in and change a couple of things to get it working again? I hope not. Also, if a function such as set-frame-position exists and is documented, then it should be usable and it should work. Otherwise, there is a bug. This thread has gone off track, regrettably. Here is my summary of the present status of the three problems I have had with 25.1: Problem one [initial display of a new invisible frame is not correctly placed] has been identified clearly. This problem can be demonstrated with simple lisp code. The problem only occurs when a toolkit is used. There are a couple of get-arounds. The problem source has not been found. Problem two [initial display of a new visible frame can involve non-clearing of the terminal input buffer] has been identified mainly by its solution, which is appropriate use of (discard-input). This problem can be demonstrated with simple lisp code when it occurs, which may be machine dependent. The problem source has not been found. Problem three [buffer display in a new frame can be truncated] has not been demonstrated with simple code. However, this is a serious display problem that has arisen with 25.1. The problem source has not been found. I hope both that the above is a reasonable description of the problems, and that progress can be made on these problems; I am willing to help to the extent that I can. David On Thu, 09 Mar 2017 09:56:42 +0100, martin rudalics wrote: >> 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 fullscreen, > > 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 ‘set-frame-position’ > 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 ‘user-position’ 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