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: Mon, 06 Mar 2017 18:51:21 -0700 Message-ID: <49adf8e1615512ac19189d75b5e04315@127.0.0.1> References: <0b9853e8ecbdb18bb1b8c05347371a7e@127.0.0.1> <58B925A4.4060406@gmx.at> <58BA900B.6040708@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 1488859332 26304 195.159.176.226 (7 Mar 2017 04:02:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Mar 2017 04:02:12 +0000 (UTC) User-Agent: Tuxedo/0.1 Cc: 25943@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Mar 07 05:02:08 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 1cl6K7-0006Hw-3L for geb-bug-gnu-emacs@m.gmane.org; Tue, 07 Mar 2017 05:02:07 +0100 Original-Received: from localhost ([::1]:47185 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cl6KD-0005mg-9H for geb-bug-gnu-emacs@m.gmane.org; Mon, 06 Mar 2017 23:02:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60356) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cl6K5-0005mK-Mf for bug-gnu-emacs@gnu.org; Mon, 06 Mar 2017 23:02:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cl6K2-0007WC-Ed for bug-gnu-emacs@gnu.org; Mon, 06 Mar 2017 23:02:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45254) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cl6K2-0007Vp-B4 for bug-gnu-emacs@gnu.org; Mon, 06 Mar 2017 23:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cl6K1-0006dQ-Vk for bug-gnu-emacs@gnu.org; Mon, 06 Mar 2017 23:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 07 Mar 2017 04:02: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.148885927625409 (code B ref 25943); Tue, 07 Mar 2017 04:02:01 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 7 Mar 2017 04:01:16 +0000 Original-Received: from localhost ([127.0.0.1]:43453 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cl6JH-0006bk-Bv for submit@debbugs.gnu.org; Mon, 06 Mar 2017 23:01:16 -0500 Original-Received: from magicmail02.frii.com ([216.17.135.171]:51825 helo=magic02.frii.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cl4Ha-0003OK-9p for 25943@debbugs.gnu.org; Mon, 06 Mar 2017 20:51:23 -0500 Original-Received: (qmail 27718 invoked from network); 7 Mar 2017 01:51:21 -0000 Original-Received: from localhost (HELO mail.frii.com) (david@ngdr.net@127.0.0.1) by magic02.frii.com with SMTP (9026f896-02d8-11e7-9734-330220ff91d9); Mon, 06 Mar 2017 18:51:21 -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); Mon, 06 Mar 2017 18:51:21 -0700 In-Reply-To: <58BA900B.6040708@gmx.at> X-Sender: david@ngdr.net X-MagicMail-OS: MagicMail 2.0-Stable X-MagicMail-UUID: 9026f896-02d8-11e7-9734-330220ff91d9 X-MagicMail-Authenticated: david@ngdr.net X-MagicMail-SourceIP: 127.0.0.1 X-MagicMail-RegexMatch: 2 X-MagicMail-EnvelopeFrom: X-Mailman-Approved-At: Mon, 06 Mar 2017 23:01:14 -0500 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:130295 Archived-At: Hello Martin, > 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_visible never becomes true, even after multiple appearances of the frame: Thread 1 "emacs-25.1.13" hit Breakpoint 1, x_make_frame_visible (f=0x1a80740) at xterm.c:10948 10948 bool previously_visible = f->output_data.x->has_been_visible; 1: previously_visible = 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. > Incidentally, I have a patched version here which seems to fix problem > one for GTK but the problem is still present for Lucid/Motif. Problem > one never occurs when building without toolkit support here, BTW. Can > you try such a build (the option is --with-x-toolkit=no)? I'd be also > interested whether you can see your other problems when building without > toolkit support. Building --with-x-toolkit=no 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! FYI, I have a policy, with multiple applications, of not disturbing recommended practices on the assumption that an item's creator has better 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 without using a toolkit. And now I am wondering just what it is that a toolkit offers me. > I don't fully understand what you mean with > > the effect can be something like key bounce, and this can be seen when > the first text appears in the popup: two text lines may appear, > instead of one. > > What is a "key bounce" You can read about key bounce on the web. A typical result is typing food and getting foood or fooood on the screen. My effect is only similar to key bounce, not the real thing. > About problem two: I see no difference regardless of whether I change > the value of ‘simple-visibility’ or comment-in or comment-out the line > > ;;; (if newish (discard-input)) If you never see the problem, then you do not need this line. I still need to use (discard-input in my code, but it is no longer necessary in the sample code that I sent to you, with the no-toolkit build. > and what are the "two text lines" that may > appear? Can you give me an example for the latter? 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 I have checked this many times, so I am confident it occurs. As indicated above, it has not happened with the no-toolkit build. What also is true, however, is that it does not always happen with a toolkit. Where should the build process find the source code? . What compiler should emacs be built with? gcc -g Should Emacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should Emacs use a relocating allocator for buffers? no Should Emacs use mmap(2) for buffer allocation? no What window system should Emacs use? x11 What toolkit should Emacs use? GTK3 Where do we find X Windows header files? Standard dirs Where do we find X Windows libraries? Standard dirs .... Being compulsive, I checked again just now: I am using my usual emacs (lots of modifications) to type this text in a workspace under Mint 18.1 with its cinnamon window manager. In another workspace I am running an xterm and from that xterm I run command ..../emacs-25.1.1 -Q. This emacs is totally unmodified from what is in the FSF .tar file and was built with ./configure; make, i.e., as above. 1st run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect 1st run 25.1.1 -Q and simple-visibility = t => no "key bounce" effect ! The ! means I was expecting the effect. killed emacs 2nd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect 2nd run 25.1.1 -Q and simple-visibility = t => "key bounce" effect killed emacs 3rd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect 3rd run 25.1.1 -Q and simple-visibility = t => "key bounce" effect 3rd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect 3rd run 25.1.1 -Q and simple-visibility = t => "key bounce" effect Here I evaluated the buffer four times, as indicated. Then I **changed workspace** to go back to the emacs where I am writing this text, wrote part of this text, **returned to the workspace** where I am running the test emacs above, and: 3rd run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect 3rd run 25.1.1 -Q and simple-visibility = t => no "key bounce" effect ! killed emacs 4th run 25.1.1 -Q and simple-visibility = nil => no "key bounce" effect 4th run 25.1.1 -Q and simple-visibility = t => "key bounce" effect > About problem three: > > > Problem three is a disaster for me, and may cause me to hang on to 23.2 > > for as long as I can. However, I am reporting it simply because I think > > that the emacs developers should know that it is happening. Also, and I > > am hoping for this, someone on the team may have some insight into the > > problem. > > Does this depend on the width of the window? What happens when you set > ‘truncate-lines’ to t? What happens when you disable margins and > fringes in the window? The no-toolkit build does not solve problem three; however, it does seem to change where it happens. I use popup frames to display arbitrary text, by which I mean texts with, 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. At one time I had C code, based on tooltip code, that produced the popups. 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, etc., there has been no point in having special code. The standard make-frame, etc. work very well. So, with regard to the problem, the frames always are correct for the target text, width and height. Thus, truncate-lines does not really enter into the picture: I size the 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 anything? It seems to me that the key is to consider that the same buffer is being rendered differently in two frames. > Please keep 25943@debbugs.gnu.org CC'd! > > martin David On Sat, 04 Mar 2017 10:59:39 +0100, martin rudalics wrote: > About problem one: > > > If the code is evaluated as supplied, and assuming emacs is started with > > -Q, and assuming that performance is what I see on my machine, the first > > display of the popup is incorrectly positioned; as I write in the > > execution instructions: "The problem is the first display of the popup." > > Subsequently performance is correct. The information in the popup > > itself > > shows the values of left, top, width, and height; this is intended to be > > helpful in seeing what is going on. > > > > If the value of simple-visibility is changed to 't, and the file > > re-eveluated, then the performance changes. The first appearance of the > > popup now is correct: it appears on the right side of the screen, rather > > than the, incorrect, left side. However, since the popup frame is > > visible > > on creation, it will flash where it is created and then appear correctly > > sized and in its correct position. This is all there is intended to be > > in > > the demonstration. > > Thanks. I hopefully understand what you mean now and can reproduce the > behavior with current master. > > > However, you may see the second problem emerge. > > I'm not there yet. > > > This > > problem can be solved by un-commenting the discard-input line. > > > > Up until, and including, 23.2, and with 23.2 running on its contempory > > OS, > > and with simple-visibility set to 'nil, the behaviour is correct on > > first > > appearance of the frame popup. > > Unfortunately, all my old GNU/Linux builds are gone due to a crash a > couple of years ago so I just believe you that this worked with 23.2. > > > I have grouped these commentary items of yours. The point is very > > simple: > > a get-around that works is to comment the previously_visible value. I > > am > > using this get-around. Probably it is not worth your while to > > re-compile, > > but if you do, I think that you will see the correction to the first > > positioning of the frame popup. If a window manager has that amount of > > control over emacs then the state of affairs is bad, isn't it? This > > would > > be a new development. > > I didn't recompile - it's quite obvious from looking at the code that > the window manager is allowed to override your positioning request in > this case. > > 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) > > Incidentally, I have a patched version here which seems to fix problem > one for GTK but the problem is still present for Lucid/Motif. Problem > one never occurs when building without toolkit support here, BTW. Can > you try such a build (the option is --with-x-toolkit=no)? I'd be also > interested whether you can see your other problems when building without > toolkit support. > > >> The previously_visible check should be present in your Emacs 23.2 > >> version. So something else must be involved here. > > > > Yes it is, and yes. I do not know enough about the design of emacs > > internals to suggest where the repair should be made, rather than the > > get-around above. > > My remark was not meant to invalidate your observations. It's just a > reminder that things might be more complicated. > > > About problem two: I see no difference regardless of whether I change > the value of ‘simple-visibility’ or comment-in or comment-out the line > > ;;; (if newish (discard-input)) > > I don't fully understand what you mean with > > the effect can be something like key bounce, and this can be seen when > the first text appears in the popup: two text lines may appear, > instead of one. > > What is a "key bounce" and what are the "two text lines" that may > appear? Can you give me an example for the latter? Do > > version 26.0 > # l:-41 t: 88 w: 60 h: 6 > > already constitute two text lines or do > > version 26.0 > # l:-41 t: 88 w: 60 h: 6 > # l:-31 t: 98 w: 60 h: 7 > > these? Here, regardless what I do, only one line gets added when I > press a key. > > > About problem three: > > > Problem three is a disaster for me, and may cause me to hang on to 23.2 > > for as long as I can. However, I am reporting it simply because I think > > that the emacs developers should know that it is happening. Also, and I > > am hoping for this, someone on the team may have some insight into the > > problem. > > Does this depend on the width of the window? What happens when you set > ‘truncate-lines’ to t? What happens when you disable margins and > fringes in the window? > > > Please keep 25943@debbugs.gnu.org CC'd! > > martin