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: Fri, 03 Mar 2017 09:13:24 +0100 Message-ID: <58B925A4.4060406@gmx.at> References: <0b9853e8ecbdb18bb1b8c05347371a7e@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: 7bit X-Trace: blaine.gmane.org 1488528865 22354 195.159.176.226 (3 Mar 2017 08:14:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 3 Mar 2017 08:14:25 +0000 (UTC) To: david@ngdr.net, 25943@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 03 09:14:21 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 1cjiLz-0005HN-UV for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Mar 2017 09:14:20 +0100 Original-Received: from localhost ([::1]:56667 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjiM5-0001gf-V4 for geb-bug-gnu-emacs@m.gmane.org; Fri, 03 Mar 2017 03:14:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39297) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cjiLm-0001W7-Hr for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 03:14:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cjiLj-0006YE-2Z for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 03:14:06 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39146) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cjiLi-0006Y8-Uk for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 03:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cjiLi-0004Rq-Pv for bug-gnu-emacs@gnu.org; Fri, 03 Mar 2017 03:14: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: Fri, 03 Mar 2017 08:14: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.148852882117044 (code B ref 25943); Fri, 03 Mar 2017 08:14:02 +0000 Original-Received: (at 25943) by debbugs.gnu.org; 3 Mar 2017 08:13:41 +0000 Original-Received: from localhost ([127.0.0.1]:37343 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjiLN-0004Qq-0F for submit@debbugs.gnu.org; Fri, 03 Mar 2017 03:13:41 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:59814) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cjiLL-0004Qa-5g for 25943@debbugs.gnu.org; Fri, 03 Mar 2017 03:13:39 -0500 Original-Received: from [192.168.1.100] ([213.162.68.104]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7m0a-1cNwGe2Oxs-00vMfH; Fri, 03 Mar 2017 09:13:28 +0100 In-Reply-To: <0b9853e8ecbdb18bb1b8c05347371a7e@127.0.0.1> X-Provags-ID: V03:K0:EnIfV7XhrfqVlU9YvkmL93UVvk9zVgAI/KZuydaBTzVVc32yDd7 IjrE91oKSN3+fGHFfLrPylsU6mK93iipEp7necEtV/SoALXCK60acIGc3HhhIF8xW1MFw57 pASfrCCb47QXGQo0QCpDBi9u2tN2ASw0f/X2umlfJGoocIla/+71NDLF/btH/EJq/ESF8+h mvq7iZlPYH+oP5OATlrXQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:+JbqtkBM3i8=:sK4IxCIa4FQtYw8UFpDN+J hNGFuBb+ukdtgen8zjAYnZelOsUlMZ4wS3+O7cZ9WarZmI/WE+oTeVKpbgAITyeRjvhvKmucZ iuAyQdHTIP9zW4//91jRXxRUIN3ic1kSpoghtyu06ds00Uaj9VrcLCH5AJbOEX00fN6DgYaQ3 yP/xERXILKEpDx4Jl1hgxifaRuXvz7PCpws5iI+4U8v0pkI7jCqX6bNmjl8W4lDEoKL22jkTj 0R6SBbJrisO1RI1hf0/Xufn4ecFuR5wQcztUpNedM9m5diRwkAnrYyK7M1Oorwf1px5Cr+Rlg oMo7pLIEoQyK5BSp3zc52hHRQ0NhOg4TUPoBd3oAWqoNb5h92lALyTX3KIQv9KB+4iOidQVI8 3i8kk9d2DppRbpfACbsJyW8DkBSshJiz7GuAo6kaKS+qMmALeuuJ3LBMxouFX1xChukSd5QRd 2QePoTS0919W6eBx/FOFvMRM6vGEH9AUA+j070kYcy44jgA54AXAHZsj545O+J1X8c6sKhjUn vPfn/buMO6/4GpRAs6+XcI+HNLwGovS0DtYhkD3EwAcDOYTFlfLvmiMYv3R8fbkrcoCMvBFD/ QGoeQVAyvjBMPY85jZ+JHqukAfDC+RZlAI99E1jcGSkSBJ67CoXY4EsiIK3duuZyMNy20aCAV T2LMdarvc+sWI9F82Md7PKqicN+gYWiBRb9S3fRu9uE57VbiAD9Hn+dJUZjp1Sz5k0BYU1crx DuXh3I+rZDUc0AJ5zXzqYiHlw7supr2Vi6cte8gN7rC0H77pjxf6/p3K0vwoGcIb+EIVFkOm 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:130089 Archived-At: > ;;; -*-Mode: emacs-lisp; Coding: emacs-mule; fill-column: 100-*- > > ;;; This file is executable and shows some problems indicated below. > Execution is addressed further Thank you for your mail, David Unfortunately, it seems that the text got mangled in between, so please consider making the comments normal text or sending it as attachment. Some short comments: > ;;; The first problem is that 25.1 does not position a new frame correctly > unless the frame is > ;;; visible when created. Starting with a visible frame is tacky because > of the flashing that > ;;; results. Command simple-doit-1 demonstrates this, What does this command demonstrate? The flashing or some wrong positioning? Could you come up with a one-step example where the frame gets positioned differently in the two versions you mention? Here the frame just moves around my screen getting larger with every step. > see below for notes > on execution. > > ;;; I spent a lot of time looking in the wrong places for a bug, but have > concluded that the problem > ;;; is more of a design issue. I think that I have identified what is > happening, but I leave that > ;;; to you to judge. The problem appears at xterm.c:10971, and is alluded > to in window.c:2335-2340. > > ;;; This is from window.c > ;;; /* Yuck!! If we've just created the frame and the > ;;; window-manager requested the user to place it > ;;; manually, the window may still not be considered > ;;; `visible'. I'd argue it should be at least > ;;; something like `iconified', but don't know how to do > ;;; that yet. --Stef */ Can you tell me why you think that this is relevant for the problem at hand? Where does your code need candidate_p? > ;;; This is part of x_make_frame_visible at line xterm.c:10963 > ;;; Don't do this if the window has never been visible before, > ;;; because the window manager may choose the position > ;;; and we don't want to override it. */ > ;;; > ;;; if (! FRAME_VISIBLE_P (f) > ;;; && ! FRAME_ICONIFIED_P (f) > ;;; && ! FRAME_X_EMBEDDED_P (f) > ;;; && f->win_gravity == NorthWestGravity > ;;; && previously_visible) This part of the code was in xterm.c at least in 2003 as if (! FRAME_VISIBLE_P (f) && ! FRAME_ICONIFIED_P (f) && f->output_data.x->win_gravity == NorthWestGravity && previously_visible) Why do you think it's impact on the behavior of your code changed? > ;;; So, my case is that I create a frame and want to position it before I > make it visible, this is > ;;; nothing to do with the window manager. I'm afraid it does. The window manager might not want to position an invisible frame. > I can solve the problem by > eliminating the > ;;; "previously_visible" part of the test above, and I am doing that as a > temporary get-around. > ;;; But, of course, that elimination cuts across your window manager > concern. The previously_visible check should be present in your Emacs 23.2 version. So something else must be involved here. > ;;; The third problem was to have been demonstrated with another command, > but I have been unable to > ;;; reproduce the problem in a simple function. The problem is a sometime > occurring, > ;;; display-wrecking, problem. I wonder if it is not even an emacs > problem, but due to underlying > ;;; rendering library code. The problem is repeatable. Also, it is new > in 25.1 compared with 23.2. > > ;;; What I have done is take a screen shot showing the problem, a .jpg > image is attached, the screen > ;;; shot is cropped. What is shown is two frames, the green frame is a > frame generated by executing > ;;; code (similar to simple-doit-1, but considerably more complicated), > the cream frame is the main > ;;; emacs frame. The black is the xterm background. The frame windows > are displaying the same > ;;; buffer, at the same time, normally these displays are identical > because the buffer is the same. > ;;; The green frame in the image shows a distorted text display, this > frame always is correctly > ;;; sized for the correct text. The break at the sixty-first column is > repeatable, but other > ;;; displays break at other places. The frames look very special - no modelines, no echo area, no scroll bars, no decorations but for the title bar of the green frame. Could you try to remove all these specialities so we can compare the frames more easily? Thanks, martin