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: Sat, 11 Mar 2017 11:21:08 +0100 Message-ID: <58C3CF94.3080604@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> <58C118CA.8020908@gmx.at> <2395d7c6fbe7358c894bc1406ffcbf45@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 1489227833 22294 195.159.176.226 (11 Mar 2017 10:23:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 11 Mar 2017 10:23:53 +0000 (UTC) Cc: "25943@debbugs.gnu.org" <25943@debbugs.gnu.org> To: david@ngdr.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Mar 11 11:23:44 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 1cmeBX-0004O8-I7 for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Mar 2017 11:23:39 +0100 Original-Received: from localhost ([::1]:42701 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmeBd-0001zZ-DA for geb-bug-gnu-emacs@m.gmane.org; Sat, 11 Mar 2017 05:23:45 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52034) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cmeBP-0001z0-FZ for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2017 05:23:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cme9y-00079O-F0 for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2017 05:23:31 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52105) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cme9y-00079B-8b for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2017 05:22:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cme9y-0005Eb-2t for bug-gnu-emacs@gnu.org; Sat, 11 Mar 2017 05:22: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: Sat, 11 Mar 2017 10:22: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.148922768620054 (code B ref 25943); Sat, 11 Mar 2017 10:22:02 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 11 Mar 2017 10:21:26 +0000 Original-Received: from localhost ([127.0.0.1]:50304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cme9O-0005DO-9T for submit@debbugs.gnu.org; Sat, 11 Mar 2017 05:21:26 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:63233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cme9L-0005D6-AV for 25943@debbugs.gnu.org; Sat, 11 Mar 2017 05:21:24 -0500 Original-Received: from [192.168.1.100] ([213.162.68.14]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MFgxF-1d0iVg3RBt-00Ed10; Sat, 11 Mar 2017 11:21:13 +0100 In-Reply-To: <2395d7c6fbe7358c894bc1406ffcbf45@127.0.0.1> X-Provags-ID: V03:K0:QtagDgCTHOhIWKb84LrG6O6wNjs4XIPwrIXQoJRCpGQgRqmcxDr M6BxfRB6urCBSS93haKvEU1zwdeliyE15oh7LLoKWuLCWFG7Wp1Dwk7ani6IsGETR+4E2KQ QSrVnrgptHxW4egWrHQdzVfDL4xxHGZ852TaniHvPgRkveAVTXZKJ0oKRjeEJtJXRWNndTs pDUN8EvM+r9jc34ZWjMxg== X-UI-Out-Filterresults: notjunk:1;V01:K0:s7j9QlE7puU=:NyStNZ9FsB1lTKND9em7Kz a3ZZKyiBKYwMRpsKvlp7pD0pHhfG5HJjGgGeyIhzgzNVnInZiTbcEP+W93xHATXnVW7Lx/NFn 4cH9JA2+k1/XNnodfJfn5ROZOrMDOfr8voq55eg4Fg+/+txnWnv77d5hNjxgYOme9mdE+mkiQ aIBiYwbbKIZS/ECTTh2vfGQ2myAynW50D/jFQF+WHxWy3lsUyxeT8SzWhqrlUoSQAp3vqgXRb 3YcXaHaEPp+DC3hwbieZswASJRFOyVMJwKU44AfZgwnQdCcBEovQF1LKRkGqGXYc2G33BAne4 0GzAQrixuUXyZHwhKoyhvUeFRwRWl87NPlZn3Xo58MB7VnA3XnpHW3x3Z16wlGzkB7rmoOSWF zoVE8xPTcNbE+YHbwSZao3CwzkfwW4VX9xER2sSs70l1VpmEeHWNInN+LkvyPFkrHsbK/CWZH Va+haZ7eWnANxCv5kA5D3fITMftd1qtF+HXC3/4iBBtox1FF5xrzkeSAK/T+RAyBW22kM/29Q RYPbQRdjdYKdi8I6WicSi/bdAPIDitk9sVymBvuyrsjrN/9OAUX3MRHHtJgTTQAMAGOuyVG9J 9eOxJPcjIevTUbgac9rybK1PhEQUKWAc9BFYE32vBZvd9pDSKLWxNjet3KAWNVfBKYnXZnoOI Y+HJoY1rSj9ePCfYJ6WfKTUyGjfpvBA2cON45QImwgwc44X8u/BMkE10w+N9YTHtafw/XxOlb okQm1G7/ydvINsCfEERUhFLUzJqoJsJjB8m4URJs81u17VlSueTo3WpafEQsNUKKN+ys2QYB 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:130480 Archived-At: > 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, n= or > was it intentional. You have not offended me. Quite on the contrary, your messages were a pleasure to read and I have to apologize for the content of my reply. Please forgive me for its rude tone. > 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. Ove= r > the years I have become increasingly grateful for emacs because emacs = has > kept me insulated from the vagaries of the hardware and software on wh= ich > 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 o= n > 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 ha= ve > 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 th= e > hardware and software changes that are occurring underneath the code t= hat > I write. > > Now I have to upgrade my OS and emacs version again. This time a coup= le > 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 change= d > 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 tha= t > the bugs will be repaired; I still want to use emacs. Thanks for your explanations. Sadly Jan Dj=C3=A4rv - our only colleague skilled in developing the Emacs-GTK/X11 interface - has left Emacs more than a year ago and we are now left with a couple of unresolved bugs and without any assistance in this area. Moreover, pressure from recent releases of GTK increases as well (compare Bug#25851) so I'm afraid that Emacs will not be able to keep up pace with your expectations. > The above is my starting point, not what you have written. In additio= n, > there are other things that are disturbing. One is that you write > > "As a rule, users should not specify frame positions manually. W= indow > 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, ha= ve > to concern myself with the window manager that I am using? Also: "Whi= le > 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 th= at 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 pas= t? The rules I sketched were not aimed at you in particular. These rules have been collected from commentaries in the sources of Emacs, GTK, GDK, X11 and miscellaneous bug reports. They comprise more or less what we, in our documentations, have concealed in this regard so far. I plan to eventually update the Elisp documentations accordingly. Most problems in this area result from attempting to position the initial or a new Emacs frame - a frame whose (typically X) window has not been created yet. If such a frame is made visible "soon", positioning it more likely succeeds but has the unpleasant side-effect described by N. Jackson as As for additional flicker, when I start Emacs things jump about like a= scalded cat, including a phantom random vertical scroll bar that often= makes a momentary appearance in the middle of my display. I've never really understood why Emacs does this then other programs seem to mana= ge without such problems, but I've come to accept the behaviour -- after all, it's only momentary while Emacs starts up ... and summarized by you as Starting with a visible frame is tacky because of the flashing that results. It would be nice if we were able to make your approach work in general and ask Mr. Jackson to use it too but for doing that we would need your help. I don't know why your code has worked successfully with Emacs 23 and doesn't work with Emacs 25 any more. One way to find out is by bisecting the Emacs sources (I can't do that here because it would take me a couple of days with my slow hardware). And even if we find the offending commit, we might not be able to revert it because it could have helped to solve a similar problem with another window manager. Anyway, if you have git and the necessary resources, bisecting would be a valuable first step. > The second disturbing point is "If you really need to position and siz= e a > new frame, please stick to the following rules:". Sorry, but no. I a= m > not a cowboy programmer; also I am quite compulsive about sticking to > conventions and rules; generally, I find that to be good practice. Bu= t > the rules that you have announced are there for the wrong reason: emac= s > 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 ema= cs. I fully agree with you. Here, Emacs 26 has become too slow to do many things I was able to do with Emacs 23 and if it were not for a few features I try to develop, I'd certainly stick with Emacs 23 instead. > Thirdly, do you really think that my code is so simple, or so buggy, t= hat > 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 i= s > documented, then it should be usable and it should work. Otherwise, > there is a bug. There _is_ a bug. Unfortunately, there's not only one bug but quite a number of them. And so far I found only a somewhat hackish solution to fix them here. I'll eventually push a "fix" to the repository but this will certainly not become part of the Emacs 25 series. > This thread has gone off track, regrettably. Here is my summary of th= e > 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= =2E > There are a couple of get-arounds. The problem source has not been fo= und. The problem source is that =E2=80=98set-frame-position=E2=80=99 calculate= s an incorrect, off-screen position for the frame and that your window manager corrects that position with on-screen settings of its choice. You should be able to verify this claim by running Emacs under gdb, putting a breakpoint at the beginning of the function x_set_offset in xterm.c and retrieving the values of modified_left and modified_top as passed to XMoveWindow. > 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 probl= em > 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 displa= y > problem that has arisen with 25.1. The problem source has not been fo= und. Both of these problems might be related to the fact that you start with an initially invisible frame and the redisplay engine doesn't catch up with the new dimensions when the frame gets eventually exposed/mapped. There have been some code changes wrt the display engine redrawing a frame only when it's needed, so maybe we should look there. But I'm afraid that it might not make much sense to investigate the sources of these problems as long as they are potentially shadowed by the first problem. > 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. Please do that. And even if you're reluctant doing that, please try to set up your frame by using the 'left and 'top frame parameters. At the very least doing that should confirm that =E2=80=98set-frame-position=E2=80= =99 is indeed the major culprit. Thanks, martin