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, 04 Mar 2017 10:59:39 +0100 Message-ID: <58BA900B.6040708@gmx.at> References: <0b9853e8ecbdb18bb1b8c05347371a7e@127.0.0.1> <58B925A4.4060406@gmx.at> 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 1488621687 11774 195.159.176.226 (4 Mar 2017 10:01:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 4 Mar 2017 10:01:27 +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 Sat Mar 04 11:01:22 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 1ck6V6-0002Bf-Pw for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Mar 2017 11:01:21 +0100 Original-Received: from localhost ([::1]:34592 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ck6VC-0002dD-SC for geb-bug-gnu-emacs@m.gmane.org; Sat, 04 Mar 2017 05:01:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55849) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ck6Us-0002UG-1C for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 05:01:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ck6Uo-0006no-Td for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 05:01:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40929) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ck6Uo-0006nj-Q9 for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 05:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ck6Uo-0000tA-Hn for bug-gnu-emacs@gnu.org; Sat, 04 Mar 2017 05:01: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, 04 Mar 2017 10:01: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.14886216033290 (code B ref 25943); Sat, 04 Mar 2017 10:01:02 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 4 Mar 2017 10:00:03 +0000 Original-Received: from localhost ([127.0.0.1]:39128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ck6Tq-0000ql-0C for submit@debbugs.gnu.org; Sat, 04 Mar 2017 05:00:02 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:54891) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ck6To-0000q2-1S for 25943@debbugs.gnu.org; Sat, 04 Mar 2017 05:00:00 -0500 Original-Received: from [192.168.1.100] ([213.162.68.79]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M4jbN-1cND0J17Nt-00z0QJ; Sat, 04 Mar 2017 10:59:46 +0100 In-Reply-To: X-Provags-ID: V03:K0:y5c9DU4akUEYEvv4TwJ97F/xPn6OS/Qgg+jZiaGx4F7bKiVTXjq HUUE3lSSv0T5yt5DnoSF9jlMj06JoPW2ONWD/NcisuzRvTSYuqJy11eDee6b8f8MMsgfTdq WxWnfCH2aRzW1mlbP8RtR9S2h3+JEB94mVzUq7rKe3XrByfAOf9M1jeUa5Rca3qUB/YWAcr bAepbY4OevjTONeLocVOQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:i4kBSQ69v1Y=:W0XzBF5XMps+hhtVq7Vd6o DaYdI/48OBA8Blzk+ro8en+ah6N61Tfs3QLlk0uWQi6782fOWr658C1SwxpEYcxeTTzfiELkj WMVPkKVUwGck9q4gFeiWuwGFchWjMXMXrey4AaVw02h2mT0XQtSXBuMFH4Y0SlmBQ7CAMT83H YJWtKjKxhX4fF1EVWhyp8RP2wnZM2k6Ng4KFcV5A9BHZxyP9xLqN2Vd7fq0NMwJ60jkusR5Ts VrJgBrFIBtRqr+CrA74ZZztcNS6bDehMaqHh265hOt+OZCY1p9K6CFe6oWu4EKEuLt+UebUB7 S5uZmuPF6/no5X4kCvxTNVbBsIQXD6n889TOpdP3wK/M5cD63/EEqoreq6MCkz4pCeONEHoKB GK7ZJbh2bu3w11PVB6GGdwpfhOPmqFIR7G8xy0lIec6718Vfs66u/djMGvQFnsdjM1ifT3JHw N8Jlzs1LDUbQ4XOmvMo1LXTRPmEc3eROLxgJh39/fBjKA2rNSkBjRuVL0tRTFpsOCx7tC/YHd 9GkyXOX6UvsPOsdR+gIuFrx7SR4IqoptgJGvtmLWqvd+iztbJYJV9xuElhrmr6QSIViLJr2Sy cpWwZBnkQTo4w/BSZRmWRlabsmkM1H7Q+MACk9eaTBN4U2LnR0Sbjzjf1wL32ULzq8q/CfIls DqCYE9CLAwYLx6Z3kAl3Pz8S0xWpFYvNCjgF987rVItsjqUkJDu48p/pKtuHrH/2uzEmC5RLp pfqUmtgFtZD+8sABPuhzvJ1pJDxLeb9jDdjMR9I+gNnETFc1NTZOeAlfGxJuGd+NvZUqrhVu 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:130159 Archived-At: About problem one: > If the code is evaluated as supplied, and assuming emacs is started wi= th > -Q, and assuming that performance is what I see on my machine, the fir= st > display of the popup is incorrectly positioned; as I write in the > execution instructions: "The problem is the first display of the popup= =2E" > Subsequently performance is correct. The information in the popup its= elf > 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 t= he > popup now is correct: it appears on the right side of the screen, rath= er > than the, incorrect, left side. However, since the popup frame is vis= ible > on creation, it will flash where it is created and then appear correct= ly > sized and in its correct position. This is all there is intended to b= e 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 fi= rst > 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 sim= ple: > 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-comp= ile, > 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 o= f > control over emacs then the state of affairs is bad, isn't it? This w= ould > 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=3Dno)? 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 =E2=80=98simple-visibility=E2=80=99 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 thi= nk > 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 =E2=80=98truncate-lines=E2=80=99 to t? What happens when you disable mar= gins and fringes in the window? Please keep 25943@debbugs.gnu.org CC'd! martin