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: Tue, 07 Mar 2017 10:45:28 +0100 Message-ID: <58BE8138.1040607@gmx.at> References: <0b9853e8ecbdb18bb1b8c05347371a7e@127.0.0.1> <58B925A4.4060406@gmx.at> <58BA900B.6040708@gmx.at> <49adf8e1615512ac19189d75b5e04315@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 1488879981 16227 195.159.176.226 (7 Mar 2017 09:46:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2017 09:46:21 +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 Tue Mar 07 10:46:16 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 1clBh5-0003Tl-Ho for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 10:46:11 +0100 Original-Received: from localhost ([::1]:48463 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clBhB-0000t1-GL for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 04:46:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1clBh0-0000ra-75 for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1clBgx-000567-4H for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45400) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1clBgw-00055E-R8 for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1clBgw-0001Z7-0i for bug-gnu-emacs@gnu.org; Tue, 07 Mar 2017 04:46: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: Tue, 07 Mar 2017 09:46: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.14888799505996 (code B ref 25943); Tue, 07 Mar 2017 09:46:01 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 7 Mar 2017 09:45:50 +0000 Original-Received: from localhost ([127.0.0.1]:43599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clBgk-0001Ye-BH for submit@debbugs.gnu.org; Tue, 07 Mar 2017 04:45:50 -0500 Original-Received: from mout.gmx.net ([212.227.15.19]:51172) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1clBgi-0001YP-KF for 25943@debbugs.gnu.org; Tue, 07 Mar 2017 04:45:49 -0500 Original-Received: from [192.168.1.100] ([213.162.68.17]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0Lp3sy-1c6NIF17hM-00esjS; Tue, 07 Mar 2017 10:45:39 +0100 In-Reply-To: <49adf8e1615512ac19189d75b5e04315@127.0.0.1> X-Provags-ID: V03:K0:MJ1b0A6Wf1IcTCL2V2u1PnYA7/ZOkiA2dgklQPKoiY9pBpElbK6 +Euree0pw5wsS2OCgXXE+BVM8f5V4FUeVjs9vOG6qHE+oggZwdiiBz3QXw+ceVCoaEJiugc srfvObiisX729qP2I8ivjObVBY7cc3vLf/OrIGalmqv0R/dogPSOVH66AMKGJnM1ULIPyO6 F1Nk4nFP17p/5AOBldI0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:TpYsoDu2NNw=:LK/gcB5mLDdysW/WVt3XyD 3Ee2d3pcp+IADZ4zEXRHxFoym/tqX5dq109PrIChB/CQGwYiFVkjnhtfNEKZep3aQsYGHAR0n BitLyxS9GdFiVK4HTGZgRY25z+e1Zi3gBETMgqyhO+xuYYprKYdJosHV4N/ZzL4oouaDhcI4P X8KwrvBjIFZ9qFhQZzcW8Korg7qXQl3wBvrwy6PMq1Ao68FFCXPB1xvvTokXBAGP0DwI2aEmh dM4P9CKsmPMB5wSVnDntNPRxGvSPxDYy3hyvJPU65P2l3zhbUTc4sxI1WElIgBErE1Jw3mZkE GZiS6H8dKfDPy3CbFqgcn4sAS3Z75lok1ih7Ly8IDQesrM3bWciaQPBwmZKESggVrsO7PKYJQ bXBUbTtrPjRBFGCodzC+DzL0/ZGKSIyewFHmX3dd/TuiaPdcZtBv46k+jPqtMzFsTwNhdv52e wjD18KMTNeLc98nAA1EFiAhB86CZ70OjsN9Ch4K/6VfEpexA2BulKfZP98zSbOvn1MLqwCBw1 oEJLyYoG0i+FC8pLLJQN3ZCY1Nro9ehH09f7AJLZepfnfAF1GC+OyAS0ABtXLwHA+yQ5kJTMO W6dVLrUTBnl/t6SsEORQCCvE3bd4RiknOm8mqCeP8GgIVVEzkco04/rP6hYjsjDXF9l/1/wqA WETd4YtbK1MzYna8g5je78QpcAI5HrGINhhzw2G+sDbww57G6+Zlf/ktZd8ZpvjdFEX7qOolK slkM10BCG6BmHmaVoFX2ZJLF1KWhdcFf5kGhLJjy2bpvhM27JP+G6FPJzQmp0zV/fhNfBhAO 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:130300 Archived-At: >> It seems related to bug#24526 but when I run your example with >> simple-visibility set to 'icon the frame is positioned at -41 here. = Can >> you try that - I mean, run your code with >> >> (defconst simple-visibility 'icon) > > This does solve the problem. However, interestingly, previously_visib= le > never becomes true, even after multiple appearances of the frame: > > Thread 1 "emacs-25.1.13" hit Breakpoint 1, x_make_frame_visible > (f=3D0x1a80740) at xterm.c:10948 > 10948 bool previously_visible =3D f->output_data.x->has_been_visib= le; > 1: previously_visible =3D false > > As you have written: So something else must be involved here. > ditto: ... a reminder that things might be more complicated. > > Also, this, as a solution, must be considered a get-around; this is > because it is not true that the new frame is/has been iconified. Yes. I just wanted to know how this would behave. There is also https://lists.gnu.org/archive/html/emacs-devel/2017-02/msg00133.html which seems to hint in the same direction. There were some changes in the GTK/X11 code last year I haven't been able to track down yet. > Building --with-x-toolkit=3Dno eliminates problem one, also appears to= > eliminate problem two (see below), I have not seen problem two, as > generated by the sample code, under this no-toolkit build with either = of > calls emacs -Q or emacs with a full load from my .emacs. Wonderful! Not really. Nowadays practically all people build with some form of toolkit support. So no-toolkit is no viable alternative. > FYI, I have a policy, with multiple applications, of not disturbing > recommended practices on the assumption that an item's creator has bet= ter > insight than I. With emacs this means that I build with a simple > ./configure; make. As a result of the policy I get what is delivered = to > me. The key point is that (probably) I have never tried to build with= out > using a toolkit. And now I am wondering just what it is that a toolki= t > offers me. I suppose that most people on GNU/Linux want to build with GTK. In my limited experience GTK builds are the worst ones (excluding the Gnustep builds). They are not bad because GTK is bad. I suppose they are bad because of a few historic constraints established by Emacs itself. IMO toolkit builds could be as smooth as non-toolkit ones and still offer most advantages of the toolkit (better menus and scroll bars, in particular) if these constraints were removed. But doing that is hard. > I apologize, I did not explain well. The effect that I see under 25.1= in > the sample code is that, after pressing f11 once, instead of: > >> version 25.1 >> # l:-41 t: 88 w: 60 h: 6 > > I see: > >> version 25.1 >> # l:-41 t: 88 w: 60 h: 6 >> # l:-31 t: 98 w: 60 h: 7 So "bouncing" happens only once, namely when setting up the initial size? > 1st run 25.1.1 -Q and simple-visibility =3D nil =3D> no "key bounce" e= ffect > 1st run 25.1.1 -Q and simple-visibility =3D t =3D> no "key bounce" e= ffect ! > The ! means I was expecting the effect. > > killed emacs > > 2nd run 25.1.1 -Q and simple-visibility =3D nil =3D> no "key bounce" e= ffect > 2nd run 25.1.1 -Q and simple-visibility =3D t =3D> "key bounce" effe= ct > > killed emacs > > 3rd run 25.1.1 -Q and simple-visibility =3D nil =3D> no "key bounce" e= ffect > 3rd run 25.1.1 -Q and simple-visibility =3D t =3D> "key bounce" effe= ct > 3rd run 25.1.1 -Q and simple-visibility =3D nil =3D> no "key bounce" e= ffect > 3rd run 25.1.1 -Q and simple-visibility =3D t =3D> "key bounce" effe= ct > > Here I evaluated the buffer four times, as indicated. Then I **change= d > workspace** to go back to the emacs where I am writing this text, wrot= e > part of this text, **returned to the workspace** where I am running th= e > test emacs above, and: > > 3rd run 25.1.1 -Q and simple-visibility =3D nil =3D> no "key bounce" e= ffect > 3rd run 25.1.1 -Q and simple-visibility =3D t =3D> no "key bounce" e= ffect ! > > killed emacs > > 4th run 25.1.1 -Q and simple-visibility =3D nil =3D> no "key bounce" e= ffect > 4th run 25.1.1 -Q and simple-visibility =3D t =3D> "key bounce" effe= ct So we can conclude that the effect depends on changing workspace when creating a new frame. Interesting. I never change workspace. >> Does this depend on the width of the window? What happens when you s= et >> =C3=A2=E2=82=AC=CB=9Ctruncate-lines=C3=A2=E2=82=AC=E2=84=A2 to t? Wh= at happens when you disable margins and >> fringes in the window? > > The no-toolkit build does not solve problem three; however, it does se= em > to change where it happens. > > I use popup frames to display arbitrary text, by which I mean texts wi= th, > a priori, unknown numbers of rows and columns. The text is "sized up"= by > my code and the frame size specified accordingly. I already disable > margins, fringes, etc. These popups are very much like tooltip popups= =2E > At one time I had C code, based on tooltip code, that produced the pop= ups. > But, emacs changed, my code no longer worked, and the fact is that for= a > few years now, I believe due to hardware advances, plentiful memory, e= tc., > there has been no point in having special code. The standard make-fra= me, > etc. work very well. So, with regard to the problem, the frames alway= s > are correct for the target text, width and height. Could you try the function =E2=80=98fit-frame-to-buffer=E2=80=99 for sizi= ng the frame and tell me whether it also exhibits problem 3? Just make a normal frame, put your buffer into that frame's selected window and call that function. > Thus, truncate-lines does not really enter into the picture: I size th= e > frame to the text, rather than writing text into a fixed-size frame. = I > think that I see why you ask the question: the problem I have shows > continuation arrows, which do not appear if the software is behaving > itself. Can you tell me where to look to see if I can find out anythi= ng? > It seems to me that the key is to consider that the same buffer is bei= ng > rendered differently in two frames. If =E2=80=98fit-frame-to-buffer=E2=80=99 exhibits problem 3, we don't hav= e to delve into the depths of your code and we can try to improve =E2=80=98fit-frame-to-b= uffer=E2=80=99. If it does not have problem 3, you could try to make your code behave a bit like =E2=80=98fit-frame-to-buffer=E2=80=99. Thanks, martin