* bug#25943: 21.5 Frame Display Difficulties
@ 2017-03-03 3:51 david
2017-03-03 8:13 ` martin rudalics
0 siblings, 1 reply; 27+ messages in thread
From: david @ 2017-03-03 3:51 UTC (permalink / raw)
To: 25943
[-- Attachment #1: Type: text/plain, Size: 12716 bytes --]
\f;;;\x1f -*-Mode: emacs-lisp; Coding: emacs-mule; fill-column: 100-*-
;;; This file is executable and shows some problems indicated below.
Execution is addressed further
;;; down. The generating OS, etc. information is at the end of this file.
;;; Background information: I am updating from emacs 23.2 running on
Trisquel 5.0, to 25.1 running
;;; on Mint 18.1 and Trisquel 7. So I have jumped over v24. I have over
50K lines of elisp that
;;; have run successfully for over 20 years. I have modified, extended,
and updated the code over
;;; the years as necessary, but the code still is basically the original.
23.2 on Trisquel has been
;;; great, but I am sure that you will understand the need to get up to
date with OS and emacs.
;;; Also, I hope that you understand that it is important to me to keep my
software running
;;; correctly.
;;; Regrettably, 25.1 does not support my code very well, this is in
contrast to 23.2, and, really,
;;; all previous versions dating back at least to v19, where it does work
well. I am trying to
;;; solve the problems, currently there are two of them that are serious
from my point of view, and
;;; one other that is a nuisance.
\f
;;; 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, 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 */
;;; 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)
;;; 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 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.
\f
;;; The second problem concerns user input, as is required in the current
file. The (discard-input)
;;; code immediately before the read-event in simple-doit-1, and which has
not been necessary with
;;; previous versions of emacs, has a disadvantage whether or not it is in
place. If it is not
;;; there (you need to comment the line to see this effect), 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. If (discard-input) is in the code, the
performance is better, but if a
;;; series of key entries must be made, a requirement in my code, then the
user must consciously
;;; pause between key entries. This is a user-nuisance kind of problem.
;;; An additional facet of this problem is that it does not always
manifest itself. Thus,
;;; sometimes, you will not see the two text lines appear together without
obvious input. This
;;; second problem is described here for information, you may or may not
be able to reproduce it.
;;; Either way it is a degradation of performance of emacs. This problem
has appeared in my code's
;;; performance in the change between 23.2 and 25.1.
\f
;;; 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.
;;; I realize that solving this problem may be, at least, very difficult.
I am hoping that you have
;;; some insight into the how and why. I am simply letting you know that
what is happening, and it
;;; is new, after twenty-odd years.
\f
;;; To run this code, first check the lines immediately below to
understand what they do, and modify
;;; the binding if desired. Then, evaluate the file, press the bound key,
and follow the
;;; instructions in the echo area, pressing any key several times until
the left value (shown in the
;;; popup as l:-NN) goes positive. The problem is the first display of
the popup. Next, change the
;;; value of the visibility switch below, re-evaluate. and repeat the key
press, etc.
;; Change to see different performance under 25.1 (also 24.5, I checked
24.5 at some point).
(defconst simple-visibility 'nil)
;; Binding. Change as required.
(global-set-key [f11] 'simple-doit-1)
\f
;; A service variable.
(defvar .emacs-current-emacs-version
(let ((lead-in "GNU Emacs ") ; an assumption, correct for 23.2, 24.5,
and 25.1
(dot "\\.")
(version (emacs-version))
(dummy "NOT INITIALIZED"))
(setq dummy (substring version (length lead-in)))
(substring dummy 0 (string-match dot dummy (1+ (string-match
dot dummy))) ))
"The current emacs version, as a string, with format NN.N")
\f
(defun simple-doit-1 ()
"Tests frame sizing and positioning."
(interactive)
(let ((simple-frame (make-frame `((name . "Simple Frame")
(visibility .
,simple-visibility))) )
(simple-buffer (get-buffer-create "Simple Buffer")))
(set-window-buffer (frame-selected-window simple-frame)
simple-buffer)
(with-current-buffer simple-buffer (erase-buffer)
(insert (format "version %s"
.emacs-current-emacs-version)))
(let* ((invoking-frame (selected-frame))
(newish (<= 25.1 (string-to-number
.emacs-current-emacs-version)))
(invoke-origin (if newish
(frame-position invoking-frame)
'(0 . 25)))
(invoke-left (car invoke-origin))
(invoke-top (cdr invoke-origin))
(left -41)
(top invoke-top)
(width 60)
(height 6))
(unwind-protect
(while (progn
(set-frame-size simple-frame width height)
(set-frame-position simple-frame left top)
(select-frame-set-input-focus simple-frame)
(set-buffer simple-buffer)
(goto-char (point-max))
(insert (format "\n%s l:%3d t:%3d w:%3d h:%3d"
(selected-frame) left top width
height))
(setq left (+ left 10)
top (+ top 10)
height (+ height 1))
;;; (if newish (discard-input))
;; loop test
(not (equal
(read-event "press any key to continue, escape
to terminate")
'escape))) )
;; end no body while
;; Protected.
(select-frame invoking-frame)
(delete-frame simple-frame))) ))
\f
;;; The End.
;;; david@ngdr.net
;;; 2 March 2017
;;; In GNU Emacs 25.1.13 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9)
;;; of 2017-02-25 built on Erota
;;; Windowing system distributor 'The X.Org Foundation', version
11.0.11804000
;;; System Description: Linux Mint 18.1 Serena
;;;
;;; Configured using:
;;; 'configure CFLAGS=-g'
;;;
;;; Configured features:
;;; XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY FREETYPE XFT ZLIB
;;; TOOLKIT_SCROLL_BARS GTK3 X11
;;;
;;; Important settings:
;;; value of $LANG: en_US.UTF-8
;;; locale-coding-system: utf-8-unix
;;;
;;; Major mode: Info
;;;
;;; Minor modes in effect:
;;; display-time-mode: t
;;; show-paren-mode: t
;;; shell-dirtrack-mode: t
;;; tooltip-mode: t
;;; global-eldoc-mode: t
;;; electric-indent-mode: t
;;; mouse-wheel-mode: t
;;; tool-bar-mode: t
;;; menu-bar-mode: t
;;; file-name-shadow-mode: t
;;; global-font-lock-mode: t
;;; font-lock-mode: t
;;; blink-cursor-mode: t
;;; auto-composition-mode: t
;;; auto-encryption-mode: t
;;; auto-compression-mode: t
;;; buffer-read-only: t
;;; column-number-mode: t
;;; line-number-mode: t
;;; transient-mark-mode: t
;;; Load-path shadows:
;;; None found.
;;;
;;; Features:
;;; (shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
;;; password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode
;;; mail-parse rfc2231 mailabbrev gmm-utils mailheader browse-url ispell
;;; image-mode sh-script smie executable sgml-mode cl-extra cc-mode
;;; cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine
;;; cc-vars cc-defs dabbrev misearch multi-isearch mailalias sendmail
;;; rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode mail-prsvr
;;; mail-utils advice effective-impressive-communications Favourites
;;; fileset-Web fileset-Emacs25 fileset-Nepenthes fileset-VTrack
;;; fileset-NDM Local-filesets MinorTools time paren Load-Nepenthes
;;; Load-Environ MoreTools fileset-NavigationShellExtensionsCompilable
;;; fileset-NavigationShellKernelCompilable ConfigViews MaintenanceHelp
;;; FileProcessing ExtendedHelp DocumentMap Spawn ManInfo Logging
;;; GenericTools Fileset tex-mode shell pcomplete makeinfo texinfo compile
;;; comint ansi-color ring Common Maintenance SearchAndMod Path-Environ
;;; Load-NavigationShell FixupKeymaps Texinfo NewFile find-func
;;; HelpAtPoint Customize ToolsHelp noutline outline easy-mmode Tools
;;; ModeChange ModeChangeHelp NavShellHelp KeyDisplayEdit KeyDisplayHelp
;;; EmacsHelp dired NavigationShell PopEdit KeyDisplay Path-NavShell info
;;; speedbar sb-image ezimage dframe derived easymenu cl-macs gv
;;; cl-loaddefs pcase cl-lib Basis time-date mule-util tooltip eldoc
;;; electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win
;;; term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
;;; tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
;;; menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
;;; syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
;;; misc-lang vietnamese tibetan thai tai-viet lao korean japanese
;;; eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic
;;; indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook
;;; help simple abbrev minibuffer cl-preloaded nadvice loaddefs button
;;; faces cus-face macroexp files text-properties overlay sha1 md5 base64
;;; format env code-pages mule custom widget hashtable-print-readable
;;; backquote dbusbind inotify dynamic-setting system-font-setting
;;; font-render-setting move-toolbar gtk x-toolkit x multi-tty
;;; make-network-process emacs)
;;;
;;; Memory information:
;;; ((conses 16 307931 161132)
;;; (symbols 48 29413 0)
;;; (miscs 40 323 2286)
;;; (strings 32 48593 29093)
;;; (string-bytes 1 1599176)
;;; (vectors 16 20546)
;;; (vector-slots 8 568963 16849)
;;; (floats 8 292 1019)
;;; (intervals 56 10070 3360)
;;; (buffers 976 157)
;;; (heap 1024 437759 51414))
[-- Attachment #2: Screenshot from 2017-02-25 10-08-23.jpg --]
[-- Type: application/octet-stream, Size: 123778 bytes --]
^ permalink raw reply [flat|nested] 27+ messages in thread* bug#25943: 21.5 Frame Display Difficulties 2017-03-03 3:51 bug#25943: 21.5 Frame Display Difficulties david @ 2017-03-03 8:13 ` martin rudalics [not found] ` <af552a322a8a630796cbddf1133b6dbe@127.0.0.1> 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-03 8:13 UTC (permalink / raw) To: david, 25943 > \f;;;\x1f -*-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 ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <af552a322a8a630796cbddf1133b6dbe@127.0.0.1>]
* bug#25943: 21.5 Frame Display Difficulties [not found] ` <af552a322a8a630796cbddf1133b6dbe@127.0.0.1> @ 2017-03-04 9:59 ` martin rudalics 2017-03-07 1:51 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-04 9:59 UTC (permalink / raw) To: david; +Cc: 25943 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 #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 already constitute two text lines or do version 26.0 #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 #<frame Simple Frame 0337dac8> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-04 9:59 ` martin rudalics @ 2017-03-07 1:51 ` david 2017-03-07 9:45 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-03-07 1:51 UTC (permalink / raw) To: martin rudalics; +Cc: 25943 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 > #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 I see: > version 25.1 > #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 > #<frame Simple Frame 0337dac8> 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 <rudalics@gmx.at> 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 > #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 > > already constitute two text lines or do > > version 26.0 > #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 > #<frame Simple Frame 0337dac8> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-07 1:51 ` david @ 2017-03-07 9:45 ` martin rudalics 2017-03-08 22:58 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-07 9:45 UTC (permalink / raw) To: david; +Cc: 25943 >> 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. 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=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! 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 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 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 >> #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 > > I see: > >> version 25.1 >> #<frame Simple Frame 0337dac8> l:-41 t: 88 w: 60 h: 6 >> #<frame Simple Frame 0337dac8> 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 = 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 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 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. Could you try the function ‘fit-frame-to-buffer’ for sizing 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 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. If ‘fit-frame-to-buffer’ exhibits problem 3, we don't have to delve into the depths of your code and we can try to improve ‘fit-frame-to-buffer’. If it does not have problem 3, you could try to make your code behave a bit like ‘fit-frame-to-buffer’. Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-07 9:45 ` martin rudalics @ 2017-03-08 22:58 ` david 2017-03-09 8:56 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-03-08 22:58 UTC (permalink / raw) To: martin rudalics; +Cc: 25943 [-- Attachment #1: Type: text/plain, Size: 3274 bytes --] Hello Martin, Summaries: > So we can conclude that the effect depends on changing workspace when > creating a new frame. Interesting. I never change workspace. I think that your conclusion goes a little too far; for example, simply re-starting emacs can do it as well. > 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. It appears that you and I use our operating systems and emacs very differently! You use one workspace and never change. I use nine workspaces, run each application in its own workspace, often fullscreen, and flip between them according to need. It sounds as though you use mouse activated menus, scroll bars, and a mouse. I eliminate the menu bar and scroll bars and control emacs with key bindings, no mouse. I am in favour of supporting these different ways of doing things, however, just in case there is any question about that. > 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; .... > > So "bouncing" happens only once, namely when setting up the initial > size? Yes. It seems to me that problems one and two both are initialization faults in some code or other. > Could you try the function ‘fit-frame-to-buffer’ for sizing 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. I have created simple-doit-2, attached, which shows what happens (this uses code in the original executable file). There are two ways shown to raise the frame, which give two slightly different behaviours. I am pretty sure that problem 3 is buried deeper than this; and I have a sneaky suspicion that this, too, is an initialization problem. > > 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. > > If ‘fit-frame-to-buffer’ exhibits problem 3, we don't have to delve into > the depths of your code and we can try to improve ‘fit-frame-to-buffer’. > If it does not have problem 3, you could try to make your code behave a > bit like ‘fit-frame-to-buffer’. I do not think that problem 3 is caused by a mis-match between buffer content and frame size. Note that the original screenshot shows a gap between the right of the text and the right side of the frame. David [-- Attachment #2: doit-2-as-sent.el --] [-- Type: text/plain, Size: 2375 bytes --] \f (global-set-key [f12] 'simple-doit-2) (defun simple-doit-2 () "Tests fit-frame-to-buffer." (interactive) (let ((simple-frame (make-frame `((name . "Simple Frame") (visibility . ,simple-visibility))) ) (simple-buffer (get-buffer-create "Simple Buffer"))) (set-window-buffer (frame-selected-window simple-frame) simple-buffer) (with-current-buffer simple-buffer (erase-buffer) (insert (format "version %s" .emacs-current-emacs-version))) ;;; (raise-frame simple-frame) (let* ((invoking-frame (selected-frame)) (newish (<= 25.1 (string-to-number .emacs-current-emacs-version))) (invoke-origin (if newish (frame-position invoking-frame) '(0 . 25))) (invoke-left (car invoke-origin)) (invoke-top (cdr invoke-origin)) (left -41) (top invoke-top) (width 60) (height 6)) (unwind-protect (while (progn ;;; (set-frame-size simple-frame width height) (set-frame-position simple-frame left top) (or (frame-visible-p simple-frame) (raise-frame simple-frame)) (select-frame-set-input-focus simple-frame) (set-buffer simple-buffer) (goto-char (point-max)) (insert (format "\n%s l:%3d t:%3d w:%3d h:%3d" (selected-frame) left top width height)) (fit-frame-to-buffer simple-frame) (setq left (+ left 10) top (+ top 10) height (+ height 1)) (if newish (discard-input)) ;; loop test (not (equal (read-event "press any key to continue, escape to terminate") 'escape))) ) ;; end no body while ;; Protected. (select-frame invoking-frame) (delete-frame simple-frame))) )) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-08 22:58 ` david @ 2017-03-09 8:56 ` martin rudalics 2017-03-10 18:44 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-09 8:56 UTC (permalink / raw) To: david; +Cc: 25943 > It appears that you and I use our operating systems and emacs very > differently! You use one workspace and never change. I use nine > workspaces, run each application in its own workspace, often fullscreen, The latter seems to indicate that popping up an additional frame on the same workspace is the exception, not the rule. > and flip between them according to need. I generally use one workspace, maximized frames and all sorts of key combinations to switch between frames and windows. > It sounds as though you use > mouse activated menus, scroll bars, and a mouse. In general only when testing or trying to reproduce scenarios described in bug reports. > Yes. It seems to me that problems one and two both are initialization > faults in some code or other. So let's concentrate on these "initialization faults" first. The basic motivation for your code is that "Starting with a visible frame is tacky because of the flashing that results". Hence you want to start with an invisible frame and show it only after you're done with positioning and sizing it. In a nutshell, you do (let ((invoking-frame (selected-frame)) (simple-frame (make-frame '((visibility . nil))))) (set-frame-size simple-frame 60 6) (set-frame-position simple-frame -41 (frame-parameter invoking-frame 'top)) (select-frame-set-input-focus simple-frame)) This will first create a frame with some default size and position, then resize the frame and finally reposition it. While this might work some of the time with some window managers I wouldn't rely on it. As a rule, users should not specify frame positions manually. Window managers dislike it. Not because they think they are better at it but because it disturbs their usual flow of control. If you really need to position and size a new frame, please stick to the following rules: (1) Use frame parameters for specifying the position. First they give you more freedom. For example, you can't use ‘set-frame-position’ to put a frame at the right edge of your display. More importantly, they allow Emacs to do its work _before_ the frame becomes visible. (2) Use frame parameters for specifying the size. Again this allows Emacs to do the associated calculations before the frame becomes visible. When specifying the frame position via a negative offset (your "-41" above), rule (2) becomes even more important because Emacs has to calculate the prospective size of your frame before it can calculate its prospective position. (3) Add a ‘user-position’ entry to your frame parameters. It might not help with all but it might help with some window managers to clarify your intentions. A sub-rule of (2): Use negative offsets with care. The original sin of the API of all window managing programs is that an application has to specify the size of the inner (aka "client") rectangle and the position of the outer (aka "display") rectangle. Extracting the size differences between these rectangles is difficult and sometimes virtually impossible (just think of wrapping tool or menu bars resulting from changing the major mode of a buffer shown in the selected window). Everything Emacs can provide here is just some approximative behavior. Consequently, I would suggest to rewrite the above form as follows: (let ((simple-frame (make-frame `((visibility . nil) (left . -41) (top . ,(frame-parameter nil 'top)) (width . 60) (height . 6))))) (select-frame-set-input-focus simple-frame)) Please try it and tell me whether it gives better results. Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-09 8:56 ` martin rudalics @ 2017-03-10 18:44 ` david 2017-03-11 10:21 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-03-10 18:44 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org Hello Martin, 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, nor was it intentional. 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. Over the years I have become increasingly grateful for emacs because emacs has kept me insulated from the vagaries of the hardware and software on which 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 on 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 have 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 the hardware and software changes that are occurring underneath the code that I write. Now I have to upgrade my OS and emacs version again. This time a couple 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 changed 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 that the bugs will be repaired; I still want to use emacs. The above is my starting point, not what you have written. In addition, there are other things that are disturbing. One is that you write "As a rule, users should not specify frame positions manually. Window 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, have to concern myself with the window manager that I am using? Also: "While 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 that 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 past? The second disturbing point is "If you really need to position and size a new frame, please stick to the following rules:". Sorry, but no. I am not a cowboy programmer; also I am quite compulsive about sticking to conventions and rules; generally, I find that to be good practice. But the rules that you have announced are there for the wrong reason: emacs 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 emacs. Thirdly, do you really think that my code is so simple, or so buggy, that 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 is documented, then it should be usable and it should work. Otherwise, there is a bug. This thread has gone off track, regrettably. Here is my summary of the 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. There are a couple of get-arounds. The problem source has not been found. 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 problem 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 display problem that has arisen with 25.1. The problem source has not been found. 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. David On Thu, 09 Mar 2017 09:56:42 +0100, martin rudalics <rudalics@gmx.at> wrote: >> It appears that you and I use our operating systems and emacs very > > differently! You use one workspace and never change. I use nine > > workspaces, run each application in its own workspace, often fullscreen, > > The latter seems to indicate that popping up an additional frame on the > same workspace is the exception, not the rule. > > > and flip between them according to need. > > I generally use one workspace, maximized frames and all sorts of key > combinations to switch between frames and windows. > > > It sounds as though you use > > mouse activated menus, scroll bars, and a mouse. > > In general only when testing or trying to reproduce scenarios described > in bug reports. > > > Yes. It seems to me that problems one and two both are initialization > > faults in some code or other. > > So let's concentrate on these "initialization faults" first. The basic > motivation for your code is that "Starting with a visible frame is tacky > because of the flashing that results". Hence you want to start with an > invisible frame and show it only after you're done with positioning and > sizing it. In a nutshell, you do > > (let ((invoking-frame (selected-frame)) > (simple-frame (make-frame '((visibility . nil))))) > (set-frame-size simple-frame 60 6) > (set-frame-position > simple-frame -41 (frame-parameter invoking-frame 'top)) > (select-frame-set-input-focus simple-frame)) > > This will first create a frame with some default size and position, then > resize the frame and finally reposition it. While this might work some > of the time with some window managers I wouldn't rely on it. > > As a rule, users should not specify frame positions manually. Window > managers dislike it. Not because they think they are better at it but > because it disturbs their usual flow of control. If you really need to > position and size a new frame, please stick to the following rules: > > (1) Use frame parameters for specifying the position. First they give > you more freedom. For example, you can't use ‘set-frame-position’ > to put a frame at the right edge of your display. More importantly, > they allow Emacs to do its work _before_ the frame becomes visible. > > (2) Use frame parameters for specifying the size. Again this allows > Emacs to do the associated calculations before the frame becomes > visible. > > When specifying the frame position via a negative offset (your "-41" > above), rule (2) becomes even more important because Emacs has to > calculate the prospective size of your frame before it can calculate > its prospective position. > > (3) Add a ‘user-position’ entry to your frame parameters. It might not > help with all but it might help with some window managers to clarify > your intentions. > > A sub-rule of (2): Use negative offsets with care. The original sin of > the API of all window managing programs is that an application has to > specify the size of the inner (aka "client") rectangle and the position > of the outer (aka "display") rectangle. Extracting the size differences > between these rectangles is difficult and sometimes virtually impossible > (just think of wrapping tool or menu bars resulting from changing the > major mode of a buffer shown in the selected window). Everything Emacs > can provide here is just some approximative behavior. > > Consequently, I would suggest to rewrite the above form as follows: > > (let ((simple-frame > (make-frame > `((visibility . nil) > (left . -41) > (top . ,(frame-parameter nil 'top)) > (width . 60) > (height . 6))))) > (select-frame-set-input-focus simple-frame)) > > Please try it and tell me whether it gives better results. > > Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-10 18:44 ` david @ 2017-03-11 10:21 ` martin rudalics 2017-03-23 7:59 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-11 10:21 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > 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, nor > 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. Over > the years I have become increasingly grateful for emacs because emacs has > kept me insulated from the vagaries of the hardware and software on which > 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 on > 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 have > 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 the > hardware and software changes that are occurring underneath the code that > I write. > > Now I have to upgrade my OS and emacs version again. This time a couple > 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 changed > 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 that > the bugs will be repaired; I still want to use emacs. Thanks for your explanations. Sadly Jan Djärv - 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 addition, > there are other things that are disturbing. One is that you write > > "As a rule, users should not specify frame positions manually. Window > 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, have > to concern myself with the window manager that I am using? Also: "While > 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 that 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 past? 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 manage 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 size a > new frame, please stick to the following rules:". Sorry, but no. I am > not a cowboy programmer; also I am quite compulsive about sticking to > conventions and rules; generally, I find that to be good practice. But > the rules that you have announced are there for the wrong reason: emacs > 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 emacs. 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, that > 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 is > 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 the > 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. > There are a couple of get-arounds. The problem source has not been found. The problem source is that ‘set-frame-position’ calculates 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 problem > 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 display > problem that has arisen with 25.1. The problem source has not been found. 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 ‘set-frame-position’ is indeed the major culprit. Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-11 10:21 ` martin rudalics @ 2017-03-23 7:59 ` martin rudalics 2017-03-28 22:43 ` david 2017-04-11 6:49 ` martin rudalics 0 siblings, 2 replies; 27+ messages in thread From: martin rudalics @ 2017-03-23 7:59 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 2164 bytes --] > I'll eventually push a "fix" to the repository but this > will certainly not become part of the Emacs 25 series. I've pushed a fix to master now. So if you can work with master please update your copy and set, in your init file, the variable `x-gtk-use-window-move' to t and see whether your problem one is fixed now. To everyone who sets negative frame positions in her programs or init file: Please try loading the attached file frame-position.el, evaluate it, call `frame-position-make' which will create twelve frames evenly distributed among the corners of your screen and finally run the function `frame-position-list' whose return value lists position and size information about these frames. Here this gets me a list like ((display-pixel-width . 1680) (display-pixel-height . 1050) (arg (p-left . 40) (p-top . 40) (left . 40) (top . 40) (width . 750) (height . 360)) ... (arg (p-left . -40) (p-top . -40) (left . 904) (top . 564) (width . 750) (height . 360) (r-left . -26) (r-top . -126)) ... (fun (p-left . -40) (p-top . -40) (left . 890) (top . 564) (width . 750) (height . 360) (r-left . -40) (r-top . -126))) The "arg" frames were produced by supplying sizes and positions via the argument list of `make-frame'. The "par" frames were produced by calling `modify-frame-parameters' with the sizes and positions after the frame was made and making the frame visible after that. The "fun" frames were produced by setting frame sizes and positions after the frame was made and making the frame visible after that. p-left stands for the programmed and r-left for the realized left position. p-top and r-top do that for the top position. Ideally, these values are the same, often they aren't. Here, the difference between the "arg" and the "fun" values is that the latter apparently already counts in 14 pixels for the scroll bar. Besides that, the values are still far from correct on GNU/Linux since they do not account for the window manager decorations. I would be interested if people get results that differ from the examples I gave above. Thanks, martin [-- Attachment #2: frame-position.el --] [-- Type: application/emacs-lisp, Size: 2748 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-23 7:59 ` martin rudalics @ 2017-03-28 22:43 ` david 2017-03-29 7:36 ` martin rudalics 2017-04-11 6:49 ` martin rudalics 1 sibling, 1 reply; 27+ messages in thread From: david @ 2017-03-28 22:43 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 4614 bytes --] Hello Martin, I have run your frame-position code a few times; I have not had time to do anything else. GNU Emacs 25.1.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.18.9) of 2017-03-19 Linux Mint 18.1 Serena (GNU/Linux 4.4.0-53-generic x86_64) The screenshots show the result of running your code under both 23.2 and 25.1. As you can see, 23.2 produced the four stacks of three frames as expected. Also clear is that three of the four stacks under 25.1 are not even: there is positional scatter. What is not clear is that the 25.1 stacks do not always have three frames each. I modified your code to help me look at what was happening, this code is attached. I ran both sets of code several times. The results are interesting because the behaviour usually changed from run to run; in other words the code is not deterministic. The attached file list-output-unmodified shows output from a 25.1 run that had 5 frames in the left top corner, 3 frames in the right bottom corner, and 2 in each of the other corners. I emphasize that these stack sizes are not consistent. I am unable to do anything similar for 23.2 because function frame-position does not exist in 23.2. The modified code labels the frames and so it is possible to see which are the rogue frames in any given run. A correct run gives the result below, and it is easy to see how this is correct since 1-4 are the arg frames, 5-8 are par, 9-C are fun, and the position order is LT, LB, RT, RB. The 9-C frames are on top of the stack, so they are the first that are seen. LT 951 RT B73 LB A62 RB C84 Here are some results from other runs: 9651 B73 see list-output-1 A2 C84 BA987651 3 see list-output-2 2 C4 9651 B73 A2 C84 987651 B3 A2 C4 Mostly, but not always, the 9-C (fun) frames are consistently in their correct corner. This is true for the 1-4 (arg) frames as well; I do not have any record of a deviation, so arg frames may be perfect. The 5-8 (par) frames are the deviants, which seem to go the the Left Top corner. I hope that this helps. I shall do more as soon as I have time. David On Thu, 23 Mar 2017 08:59:49 +0100, martin rudalics <rudalics@gmx.at> wrote: >> I'll eventually push a "fix" to the repository but this > > will certainly not become part of the Emacs 25 series. > > I've pushed a fix to master now. So if you can work with master please > update your copy and set, in your init file, the variable > `x-gtk-use-window-move' to t and see whether your problem one is fixed > now. > > To everyone who sets negative frame positions in her programs or init > file: Please try loading the attached file frame-position.el, evaluate > it, call `frame-position-make' which will create twelve frames evenly > distributed among the corners of your screen and finally run the > function `frame-position-list' whose return value lists position and > size information about these frames. Here this gets me a list like > > ((display-pixel-width . 1680) > (display-pixel-height . 1050) > (arg > (p-left . 40) > (p-top . 40) > (left . 40) > (top . 40) > (width . 750) > (height . 360)) > ... > (arg > (p-left . -40) > (p-top . -40) > (left . 904) > (top . 564) > (width . 750) > (height . 360) > (r-left . -26) > (r-top . -126)) > ... > (fun > (p-left . -40) > (p-top . -40) > (left . 890) > (top . 564) > (width . 750) > (height . 360) > (r-left . -40) > (r-top . -126))) > > The "arg" frames were produced by supplying sizes and positions via the > argument list of `make-frame'. The "par" frames were produced by > calling `modify-frame-parameters' with the sizes and positions after the > frame was made and making the frame visible after that. The "fun" > frames were produced by setting frame sizes and positions after the > frame was made and making the frame visible after that. > > p-left stands for the programmed and r-left for the realized left > position. p-top and r-top do that for the top position. Ideally, these > values are the same, often they aren't. Here, the difference between > the "arg" and the "fun" values is that the latter apparently already > counts in 14 pixels for the scroll bar. > > Besides that, the values are still far from correct on GNU/Linux since > they do not account for the window manager decorations. I would be > interested if people get results that differ from the examples I gave > above. > > Thanks, martin [-- Attachment #2: Screenshot from 2017-03-28 12-14-48.png --] [-- Type: application/octet-stream, Size: 300816 bytes --] [-- Attachment #3: Screenshot from 2017-03-28 12-12-54.png --] [-- Type: application/octet-stream, Size: 376881 bytes --] [-- Attachment #4: frame-position-modified.el --] [-- Type: text/plain, Size: 3500 bytes --] (setq x-gtk-use-window-move t) \f (defun frame-position-make-frame-arg (p-left p-top id) (let ((frame (make-frame `((name . ,id) (p-type . arg) (p-left . ,p-left) (left . ,p-left) (p-top . ,p-top) (top . ,p-top) (width . 80) (height . 20))))) frame)) (defun frame-position-make-frame-par (p-left p-top id) (let ((frame (make-frame `((name . ,id) (visibility . nil) (p-type . par) (p-left . ,p-left) (p-top . ,p-top))))) (modify-frame-parameters frame `((left . ,p-left) (top . ,p-top) (width . 80) (height . 20))) (make-frame-visible frame) frame)) (defun frame-position-make-frame-fun (p-left p-top id) (let ((frame (make-frame `((name . ,id) (visibility . nil) (p-type . fun) (p-left . ,p-left) (p-top . ,p-top))))) (set-frame-size frame 80 20) (set-frame-position frame p-left p-top) (make-frame-visible frame) frame)) \f (defconst frame-position-frame-list '()) (defun frame-position-make () (interactive) (let (frame) (dolist (frame (frame-list)) (set-frame-parameter frame 'p-type nil))) (setq frame-position-frame-list (list (frame-position-make-frame-arg 40 40 "1 Left Top") (frame-position-make-frame-arg 40 -40 "2 Left Bottom") (frame-position-make-frame-arg -40 40 "3 Right Top") (frame-position-make-frame-arg -40 -40 "4 Right Bottom") (frame-position-make-frame-par 40 40 "5 Left Top") (frame-position-make-frame-par 40 -40 "6 Left Bottom") (frame-position-make-frame-par -40 40 "7 Right Top") (frame-position-make-frame-par -40 -40 "8 Right Bottom") (frame-position-make-frame-fun 40 40 "9 Left Top") (frame-position-make-frame-fun 40 -40 "A Left Bottom") (frame-position-make-frame-fun -40 40 "B Right Top") (frame-position-make-frame-fun -40 -40 "C Right Bottom"))) ) \f (defvar display-pixel-width (display-pixel-width)) (defvar display-pixel-height (display-pixel-height)) (defun frame-position-test-1 (frame) (let* ((type (frame-parameter frame 'p-type)) (name (frame-parameter frame 'name)) (p-left (frame-parameter frame 'p-left)) (p-top (frame-parameter frame 'p-top)) (pos (frame-position frame)) (left (car pos)) (top (cdr pos)) (width (frame-pixel-width frame)) (height (frame-pixel-height frame)) (list (list type (cons 'name name) (cons 'p-left p-left) (cons 'p-top p-top) (cons 'left left) (cons 'top top) (cons 'width width) (cons 'height height)))) (when (< p-left 0) (let ((r-left (+ (- display-pixel-width) left width))) (setq list (nconc list (list (cons 'r-left r-left)))))) (when (< p-top 0) (let ((r-top (+ (- display-pixel-height) top height))) (setq list (nconc list (list (cons 'r-top r-top)))))) (YS list)) ) (defun frame-position-list () (interactive) (let ((list (list (cons 'display-pixel-height display-pixel-height) (cons 'display-pixel-width display-pixel-width))) frame) (dolist (frame (nreverse frame-position-frame-list)) (when (frame-parameter frame 'p-type) (setq list (cons (frame-position-test-1 frame) list)))) list)) \f ;; (eval-buffer) ;; (frame-position-make) ;; (insert (format "\n%s" (pp (nreverse (frame-position-list))))) [-- Attachment #5: list-output-unmodified --] [-- Type: text/plain, Size: 1563 bytes --] This output corresponds to stacks of frames like this: LT 5 frames LB 2 .. RT 2 .. RB 3 .. ( (fun (p-left . -40) (p-top . -40) (left . 1183) (top . 704) (width . 816) (height . 400) (r-left . -49) (r-top . -48)) (fun (p-left . -40) (p-top . 40) (left . 1183) (top . 32) (width . 816) (height . 400) (r-left . -49)) (fun (p-left . 40) (p-top . -40) (left . 31) (top . 704) (width . 816) (height . 400) (r-top . -48)) (fun (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (par (p-left . -40) (p-top . -40) (left . 1183) (top . 704) (width . 816) (height . 400) (r-left . -49) (r-top . -48)) (par (p-left . -40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241)) (par (p-left . 40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-top . -722)) (par (p-left . 40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400)) (arg (p-left . -40) (p-top . -40) (left . 1181) (top . 694) (width . 816) (height . 400) (r-left . -51) (r-top . -58)) (arg (p-left . -40) (p-top . 40) (left . 1181) (top . 32) (width . 816) (height . 400) (r-left . -51)) (arg (p-left . 40) (p-top . -40) (left . 31) (top . 694) (width . 816) (height . 400) (r-top . -58)) (arg (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (display-pixel-height . 1152) (display-pixel-width . 2048)) [-- Attachment #6: list-output-1 --] [-- Type: text/plain, Size: 1781 bytes --] ( (arg (name . "1 Left Top") (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (arg (name . "2 Left Bottom") (p-left . 40) (p-top . -40) (left . 31) (top . 694) (width . 816) (height . 400) (r-top . -58)) (arg (name . "3 Right Top") (p-left . -40) (p-top . 40) (left . 1181) (top . 32) (width . 816) (height . 400) (r-left . -51)) (arg (name . "4 Right Bottom") (p-left . -40) (p-top . -40) (left . 1181) (top . 694) (width . 816) (height . 400) (r-left . -51) (r-top . -58)) (par (name . "5 Left Top") (p-left . 40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400)) (par (name . "6 Left Bottom") (p-left . 40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-top . -722)) (par (name . "7 Right Top") (p-left . -40) (p-top . 40) (left . 1183) (top . 32) (width . 816) (height . 400) (r-left . -49)) (par (name . "8 Right Bottom") (p-left . -40) (p-top . -40) (left . 1183) (top . 704) (width . 816) (height . 400) (r-left . -49) (r-top . -48)) (fun (name . "9 Left Top") (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (fun (name . "A Left Bottom") (p-left . 40) (p-top . -40) (left . 31) (top . 704) (width . 816) (height . 400) (r-top . -48)) (fun (name . "B Right Top") (p-left . -40) (p-top . 40) (left . 1183) (top . 32) (width . 816) (height . 400) (r-left . -49)) (fun (name . "C Right Bottom") (p-left . -40) (p-top . -40) (left . 1183) (top . 704) (width . 816) (height . 400) (r-left . -49) (r-top . -48)) (display-pixel-height . 1152) (display-pixel-width . 2048)) [-- Attachment #7: list-output-2 --] [-- Type: text/plain, Size: 1781 bytes --] ( (arg (name . "1 Left Top") (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (arg (name . "2 Left Bottom") (p-left . 40) (p-top . -40) (left . 31) (top . 694) (width . 816) (height . 400) (r-top . -58)) (arg (name . "3 Right Top") (p-left . -40) (p-top . 40) (left . 1181) (top . 32) (width . 816) (height . 400) (r-left . -51)) (arg (name . "4 Right Bottom") (p-left . -40) (p-top . -40) (left . 1181) (top . 694) (width . 816) (height . 400) (r-left . -51) (r-top . -58)) (par (name . "5 Left Top") (p-left . 40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400)) (par (name . "6 Left Bottom") (p-left . 40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-top . -722)) (par (name . "7 Right Top") (p-left . -40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241)) (par (name . "8 Right Bottom") (p-left . -40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241) (r-top . -722)) (fun (name . "9 Left Top") (p-left . 40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400)) (fun (name . "A Left Bottom") (p-left . 40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-top . -722)) (fun (name . "B Right Top") (p-left . -40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241)) (fun (name . "C Right Bottom") (p-left . -40) (p-top . -40) (left . 1183) (top . 704) (width . 816) (height . 400) (r-left . -49) (r-top . -48)) (display-pixel-height . 1152) (display-pixel-width . 2048)) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-28 22:43 ` david @ 2017-03-29 7:36 ` martin rudalics 2017-03-29 19:53 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-29 7:36 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > I have run your frame-position code a few times; I have not had time to do > anything else. I suppose you did not (or were not able to) apply my patch so (setq x-gtk-use-window-move t) had not effect on the outcome of your runs. Right? > I am unable to do anything similar for 23.2 because > function frame-position does not exist in 23.2. I forgot. Instead of (pos (frame-position frame)) (left (car pos)) (top (cdr pos)) use (left (frame-parameter frame 'left)) (top (frame-parameter frame 'top)) for Emacs 23. > Mostly, but not always, the 9-C (fun) frames are consistently in their > correct corner. This is true for the 1-4 (arg) frames as well; I do not > have any record of a deviation, so arg frames may be perfect. The 5-8 > (par) frames are the deviants, which seem to go the the Left Top corner. Your results for 25.1 are better than mine. Here only the "arg" runs position correctly. The "fun" and "par" frames all end up in the top left corner. So if you do want to continue working with an unpatched Emacs 25.1 and want more or less correct positioning you will have to use the "arg" notation. Otherwise you will have to either patch your 25.1 or switch to the current development version. ( (arg ... (name . "4 Right Bottom") (p-left . -40) (p-top . -40) (left . 1181) (top . 694) (width . 816) (height . 400) (r-left . -51) (r-top . -58)) It might be interesting to see where these differences in the "arg" case come from - 11 pixels horizontally and 18 pixels vertically. What does M-: (frame-geometry) in that frame return? Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-29 7:36 ` martin rudalics @ 2017-03-29 19:53 ` david 2017-03-30 7:29 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-03-29 19:53 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 2126 bytes --] On Wed, 29 Mar 2017 09:36:13 +0200, martin rudalics <rudalics@gmx.at> wrote: >> I have run your frame-position code a few times; I have not had time to >> do > > anything else. > > I suppose you did not (or were not able to) apply my patch so > > (setq x-gtk-use-window-move t) > > had not effect on the outcome of your runs. Right? That is correct; I want to try your change; I hope to get to it soon. > > > I am unable to do anything similar for 23.2 because > > function frame-position does not exist in 23.2. > > I forgot. Instead of > > (pos (frame-position frame)) > (left (car pos)) > (top (cdr pos)) > > use > > (left (frame-parameter frame 'left)) > (top (frame-parameter frame 'top)) > > for Emacs 23. I did not think that this would be important. I attach a run for 23.2 this time. FYI, it turns out that the code must be (id (eval (frame-parameter... in order to handle parameters such as (+ -9) > > > Mostly, but not always, the 9-C (fun) frames are consistently in their > > correct corner. This is true for the 1-4 (arg) frames as well; I do not > > have any record of a deviation, so arg frames may be perfect. The 5-8 > > (par) frames are the deviants, which seem to go the the Left Top corner. > > Your results for 25.1 are better than mine. Here only the "arg" runs > position correctly. The "fun" and "par" frames all end up in the top > left corner. So if you do want to continue working with an unpatched > Emacs 25.1 and want more or less correct positioning you will have to > use the "arg" notation. Otherwise you will have to either patch your > 25.1 or switch to the current development version. > > ( > (arg > ... > (name . "4 Right Bottom") > (p-left . -40) > (p-top . -40) > (left . 1181) > (top . 694) > (width . 816) > (height . 400) > (r-left . -51) > (r-top . -58)) > > It might be interesting to see where these differences in the "arg" case > come from - 11 pixels horizontally and 18 pixels vertically. What does > > M-: (frame-geometry) > > in that frame return? See Run 5 attached. > > Thanks, martin [-- Attachment #2: other-output-5 --] [-- Type: text/plain, Size: 2516 bytes --] ;; Run 5. ;; In C Right Bottom frame, misplaced at Left Top. (frame-geometry) ( (outer-position -9 . 30) (outer-size 836 . 447) (external-border-size 10 . 10) (title-bar-size 0 . 27) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) ;; In 4 Right Bottom frame, correctly placed at Right Bottom. (frame-geometry) ( (outer-position 1181 . 694) (outer-size 836 . 447) (external-border-size 10 . 10) (title-bar-size 0 . 27) (menu-bar-external . t) (menu-bar-size 0 . 0) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) ;; In main Emacs frame. (frame-position-list) ( (arg (name . "1 Left Top") (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (arg (name . "2 Left Bottom") (p-left . 40) (p-top . -40) (left . 31) (top . 694) (width . 816) (height . 400) (r-top . -58)) (arg (name . "3 Right Top") (p-left . -40) (p-top . 40) (left . 1181) (top . 32) (width . 816) (height . 400) (r-left . -51)) (arg (name . "4 Right Bottom") (p-left . -40) (p-top . -40) (left . 1181) (top . 694) (width . 816) (height . 400) (r-left . -51) (r-top . -58)) (par (name . "5 Left Top") (p-left . 40) (p-top . 40) (left . 31) (top . 32) (width . 816) (height . 400)) (par (name . "6 Left Bottom") (p-left . 40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-top . -722)) (par (name . "7 Right Top") (p-left . -40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241)) (par (name . "8 Right Bottom") (p-left . -40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241) (r-top . -722)) (fun (name . "9 Left Top") (p-left . 40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400)) (fun (name . "A Left Bottom") (p-left . 40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-top . -722)) (fun (name . "B Right Top") (p-left . -40) (p-top . 40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241)) (fun (name . "C Right Bottom") (p-left . -40) (p-top . -40) (left . -9) (top . 30) (width . 816) (height . 400) (r-left . -1241) (r-top . -722)) (display-pixel-height . 1152) (display-pixel-width . 2048)) [-- Attachment #3: other-output-6-23.2 --] [-- Type: text/plain, Size: 1752 bytes --] ;; 23.2 In C Right Bottom, correctly placed. (frame-position-list) ( (arg (name . "1 Left Top") (p-left . 40) (p-top . 40) (left . 30) (top . 30) (width . 656) (height . 340)) (arg (name . "2 Left Bottom") (p-left . 40) (p-top . -40) (left . 30) (top . 735) (width . 656) (height . 340) (r-top . -77)) (arg (name . "3 Right Top") (p-left . -40) (p-top . 40) (left . 1342) (top . 30) (width . 656) (height . 340) (r-left . -50)) (arg (name . "4 Right Bottom") (p-left . -40) (p-top . -40) (left . 1342) (top . 735) (width . 656) (height . 340) (r-left . -50) (r-top . -77)) (par (name . "5 Left Top") (p-left . 40) (p-top . 40) (left . 30) (top . 30) (width . 656) (height . 340)) (par (name . "6 Left Bottom") (p-left . 40) (p-top . -40) (left . 30) (top . 735) (width . 656) (height . 340) (r-top . -77)) (par (name . "7 Right Top") (p-left . -40) (p-top . 40) (left . 1342) (top . 30) (width . 656) (height . 340) (r-left . -50)) (par (name . "8 Right Bottom") (p-left . -40) (p-top . -40) (left . 1342) (top . 735) (width . 656) (height . 340) (r-left . -50) (r-top . -77)) (fun (name . "9 Left Top") (p-left . 40) (p-top . 40) (left . 30) (top . 30) (width . 656) (height . 340)) (fun (name . "A Left Bottom") (p-left . 40) (p-top . -40) (left . 30) (top . 735) (width . 656) (height . 340) (r-top . -77)) (fun (name . "B Right Top") (p-left . -40) (p-top . 40) (left . 1342) (top . 30) (width . 656) (height . 340) (r-left . -50)) (fun (name . "C Right Bottom") (p-left . -40) (p-top . -40) (left . 1342) (top . 735) (width . 656) (height . 340) (r-left . -50) (r-top . -77)) (display-pixel-height . 1152) (display-pixel-width . 2048)) ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-29 19:53 ` david @ 2017-03-30 7:29 ` martin rudalics 2017-04-01 4:35 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-03-30 7:29 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > I did not think that this would be important. I attach a run for 23.2 > this time. FYI, it turns out that the code must be > (id (eval (frame-parameter... in order to handle parameters such as (+ > -9) Hmm... I thought all your Emacs 23.2 frames were on-screen. You mean in order to use the same test procedure for both 23.2 and 25.2, I presume. > ;; Run 5. > > ;; In C Right Bottom frame, misplaced at Left Top. > (frame-geometry) > > ( > (outer-position -9 . 30) > (outer-size 836 . 447) > (external-border-size 10 . 10) > (title-bar-size 0 . 27) > (menu-bar-external . t) > (menu-bar-size 0 . 0) > (tool-bar-external . t) > (tool-bar-position . top) > (tool-bar-size 0 . 0) > (internal-border-width . 0)) > > ;; In 4 Right Bottom frame, correctly placed at Right Bottom. > (frame-geometry) > > ( > (outer-position 1181 . 694) > (outer-size 836 . 447) > (external-border-size 10 . 10) > (title-bar-size 0 . 27) > (menu-bar-external . t) > (menu-bar-size 0 . 0) > (tool-bar-external . t) > (tool-bar-position . top) > (tool-bar-size 0 . 0) > (internal-border-width . 0)) I didn't make myself clear enough. A frame gets misplaced at the left top of your screen because its position was miscalculated in a way that would have put the frame off-screen. Since you likely use one display only, your window manager then puts the frame at some default place (the -9 and 30 values in your case). Here it puts them right at the top left display corner. `frame-geometry' won't reveal anything new wrt whether a frame was misplaced that way. What I menat was to find out the differences between `fun', `arg' and `par' when the window manager places the frame more or less "correctly" where you want it like at (1181 . 694). Some frame parameters seem to affect that, like the size of the scroll, menu or tool bar and we could find out how. But according to `frame-geometry' you use neither menu nor tool bars. Right? This means that I have no clue wrt how the height of your frames gets miscalculated. And for the width I probably need the default width of your scroll bars. So I would need your `frame-geometry' output from emacs -Q plus that of (frame-parameter nil 'scroll-bar-width) in order to find out. All values reported should be (hopefully) the same regardless of how wrongly Emacs wants to place the frame and where the window manager eventually puts it. martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-30 7:29 ` martin rudalics @ 2017-04-01 4:35 ` david 2017-04-01 7:36 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-04-01 4:35 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 1916 bytes --] Hello Martin, I have some new information that may help with problem 3. Quite often I run emacs on one machine and control it from another over my small home network. I am updating my operating systems as well as updating emacs. One attached screenshot shows the display on one machine (Mneme) running Linux Mint 18.1 when accessing emacs 25.1 running on another (Thalia) running Linux Trisquel 7; the connection was by X tunneling over ssh. The display shown is repeatable. The important thing from our point of view is that the screenshot shows the problem 3 effect. Furthermore, it shows the effect with the main emacs frame as well as with a popup. The cream coloured area is emacs, but this should be covering the whole of the large grey area; I start emacs with the entry (fullscreen . maximized) as part of its initial-frame-alist. The maroon coloured area is part of a subsequent popup, which should be covering the smaller grey area, which is the popup frame. It is clear that the text in the popup is truncated both horizontally and vertically in precisely the way that I have reported before when running and displaying on one machine. The other screenshot shows just the main emacs frame; I put a find-file line in my .emacs; the file contains the numbers shown. The line width is 102 and I do have this line in my .emacs: (setq emacs-lisp-docstring-fill-column 100). However, at fullscreen, I can display two windows side-by-side at this width, and the docstring fill column probably is a red herring. By watching the start-up it appears that the cream coloured area is the same size as the initial size of emacs before the (fullscreen . maximized) takes effect. I am hoping that these screenshots will throw some light on problem 3. The key question now appears to address why the main emacs frame is not filled properly, my popups can be eliminated as the cause of the problem. David [-- Attachment #2: Screenshot from 2017-03-31 18-00-27.png --] [-- Type: application/octet-stream, Size: 91354 bytes --] [-- Attachment #3: Screenshot from 2017-03-31 22-02-52.png --] [-- Type: application/octet-stream, Size: 145733 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-01 4:35 ` david @ 2017-04-01 7:36 ` martin rudalics [not found] ` <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1> 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-04-01 7:36 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > I am hoping that these screenshots will throw some light on problem 3. > The key question now appears to address why the main emacs frame is not > filled properly, my popups can be eliminated as the cause of the problem. The only thing that comes to my mind without investigating this more deeply is that you do some sort of scaling on that display. Have you anywhere set GDK_SCALE (or GDK_DPI_SCALE) to something greater 1? GTK Emacsen can't digest that yet and it will take some time to teach them the right way. Otherwise, as a first step please do any experiments with emacs -Q only (we'll deal with your init file later) so we can see see how menu and toll bars relate to the problem. Then tell me the return value of the following forms evaluated for the maximized (cream colored) frame. (display-monitor-attributes-list) (frame-geometry) (frame-edges nil 'outer-edges) (frame-edges nil 'native-edges) (frame-edges nil 'internal-edges) Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1>]
* bug#25943: 21.5 Frame Display Difficulties [not found] ` <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1> @ 2017-04-02 7:55 ` martin rudalics 2017-04-04 0:35 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-04-02 7:55 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > I think that I have done what you ask, with both 25.1 and 23.2. However, > none of the listed functions exists on 23.2 Indeed. > 08-19-37: the result of invoking 25.1 with -Q over the network with ssh > > 08-23-08: after loading .emacs > > 08-24-07: after enlarging the frame by clicking on the top right + > > 08-47-05: a new invocation, no -Q > > 09-05-33: the result of invoking 23.2 with -Q over the network with ssh > > 09-06-42: after loading .emacs (the same file as above, not even a copy) > > 09-07-41: after enlarging the frame by clicking on the top right + > > 09-10-06: a new invocation, no -Q I'm not 100% sure whether these results are for the right display/frame. Also I see that you don't have any image support so your tool bars are empty and useless for comparing. Please repeat as follows: (setq frame (make-frame '((tool-bar-lines . 0)))) (list (display-monitor-attributes-list frame) (frame-geometry frame) (frame-edges frame 'outer-edges) (frame-edges frame 'native-edges) (frame-edges frame 'internal-edges)) Then please run the function (window--dump-frame frame) and obtain the dump from the buffer *window-frame-dump*. I'm only interested in emacs -Q runs for Emacs 25.2 so please do not load your .emacs and always stay in Lisp interaction mode. I need two runs of the above - a first one right after your created the frame and a second one after you maximized it. Also please yank the results into the mail body, it's hard for me to decipher them from the png images. What I did note from your images is that your 23.2 build (I suppose it's the one you always referred to in our past discussions) is not a GTK build but one without toolkit support. So it seems that we've been always comparing apples and oranges and I'm quite confident that if your 23.2 build had been a GTK one you would've experienced exactly the same problems then as you do now with the 25.2 build. However, the fact that maximizing is not propagated correctly to the frame's windows for the 25.2 version must be investigated. Maybe the frame dump will help. How do you maximize? Does any of the following produce better frames? (set-frame-parameter frame 'fullscreen 'maximized) (set-frame-parameter frame 'fullscreen 'fullboth) (set-frame-parameter frame 'fullscreen 'fullheight) (set-frame-parameter frame 'fullscreen 'fullwidth) Thanks for your efforts, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-02 7:55 ` martin rudalics @ 2017-04-04 0:35 ` david 2017-04-04 7:25 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-04-04 0:35 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 10585 bytes --] ;; This buffer is for text that is not saved, and for Lisp evaluation. ;; To create a file, visit it with C-x C-f and enter text in its buffer. \f ;; Immediately after invoking emacs with -Q. (setq frame (make-frame '((tool-bar-lines . 0))) ) #<frame emacs@Thalia 0x131b0b0> (list (display-monitor-attributes-list frame) (frame-geometry frame) (frame-edges frame 'outer=edges) (frame-edges frame 'native-edges) (frame-edges frame 'internal-edges)) ((((name . "VGA-1") (geometry 0 0 2048 1152) (workarea 0 38 2048 1114) (mm-size 510 287) (frames #<frame *scratch* 0x12b3a50> #<frame *scratch* 0x131b0b0>) (source . "Gdk"))) ((outer-position 589 . 186) (outer-size 852 . 764) (external-border-size 10 . 10) (title-bar-size 0 . 27) (menu-bar-external . t) (menu-bar-size 832 . 33) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) (599 256 1431 940) (599 256 1431 940) (599 256 1431 940)) (window--dump-frame frame) nil frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 frame text pixel: 800 x 684 cols/lines: 80 x 36 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 832 x 665 new: 0 char left: 0 top: 0 size: 83 x 35 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 646 char: 80 x 34 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 665 size: 832 x 19 new: 0 char left: 0 top: 35 size: 83 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 19 char: 80 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 \f ;; Immediately after maximizing by clicking on the top-right +. Note that the value of frame is ;; different. frame #<frame *scratch* 0x131b0b0> (list (display-monitor-attributes-list frame) (frame-geometry frame) (frame-edges frame 'outer=edges) (frame-edges frame 'native-edges) (frame-edges frame 'internal-edges)) ((((name . "VGA-1") (geometry 0 0 2048 1152) (workarea 0 38 2048 1114) (mm-size 510 287) (frames #<frame *scratch* 0x12b3a50> #<frame *scratch* 0x131b0b0>) (source . "Gdk"))) ((outer-position 0 . 38) (outer-size 2048 . 1114) (external-border-size 0 . 1) (title-bar-size 0 . 28) (menu-bar-external . t) (menu-bar-size 2048 . 33) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151)) (window--dump-frame frame) nil frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 frame text pixel: 800 x 684 cols/lines: 80 x 36 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 832 x 665 new: 0 char left: 0 top: 0 size: 83 x 35 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 646 char: 80 x 34 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 665 size: 832 x 19 new: 0 char left: 0 top: 35 size: 83 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 19 char: 80 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 \f ;; Just after obtaining the information above the (real, not reported) workarea expanded to its ;; "proper" maximized size with no intentional input from me. I ran the checks again, and the ;; results are different. frame #<frame *scratch* 0x131b0b0> (list (display-monitor-attributes-list frame) (frame-geometry frame) (frame-edges frame 'outer=edges) (frame-edges frame 'native-edges) (frame-edges frame 'internal-edges)) ((((name . "VGA-1") (geometry 0 0 2048 1152) (workarea 0 38 2048 1114) (mm-size 510 287) (frames #<frame *scratch* 0x12b3a50> #<frame *scratch* 0x131b0b0>) (source . "Gdk"))) ((outer-position 0 . 38) (outer-size 2048 . 1114) (external-border-size 0 . 1) (title-bar-size 0 . 28) (menu-bar-external . t) (menu-bar-size 2048 . 33) (tool-bar-external . t) (tool-bar-position . top) (tool-bar-size 0 . 0) (internal-border-width . 0)) (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151)) (window--dump-frame frame) nil frame pixel: 2048 x 1051 cols/lines: 205 x 55 units: 10 x 19 frame text pixel: 2016 x 1051 cols/lines: 201 x 55 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 2048 x 1032 new: 0 char left: 0 top: 0 size: 204 x 54 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 2016 x 1013 char: 201 x 53 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 1032 size: 2048 x 19 new: 0 char left: 0 top: 54 size: 204 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 2016 x 19 char: 201 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 \f ;; I started a new emacs and ran (setq frame (make-frame '((tool-bar-lines . 0))) ). Then I set the ;; fullscreen parameter with results indicated below. (set-frame-parameter frame 'fullscreen 'maximized) ;; The outersize changed to fullscreen, the (real) workarea did not change in size, but it did ;; relocate to Left Top. In other words the result was very similar to a normal, problem, start. (set-frame-parameter frame 'fullscreen 'fullboth) ;; From the position above, this caused the outerframe to increase in size, eliminating the frame ;; border. The workarea moved, further Left Top, but did not change in size. (set-frame-parameter frame 'fullscreen 'fullheight) (set-frame-parameter frame 'fullscreen 'fullwidth) ;; I have never used these, so I do not know how they are intended to work. After these, the shape ;; changed to fullheight and fullwidth, respectively. The other dimension changed to the width and ;; height of the workarea and the whole outershape moved so that it was centered horizontally and ;; vertically respectively. The attached screenshot shows one of these configurations. (setq frame (make-frame '((tool-bar-lines . 0))) ) #<frame emacs@Thalia 0x133e2e0> (set-frame-parameter frame 'fullscreen 'maximized) nil (window--dump-frame frame) nil frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 frame text pixel: 800 x 684 cols/lines: 80 x 36 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 832 x 665 new: 0 char left: 0 top: 0 size: 83 x 35 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 646 char: 80 x 34 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 665 size: 832 x 19 new: 0 char left: 0 top: 35 size: 83 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 19 char: 80 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 (set-frame-parameter frame 'fullscreen 'fullboth) nil (window--dump-frame frame) nil frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 frame text pixel: 800 x 684 cols/lines: 80 x 36 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 832 x 665 new: 0 char left: 0 top: 0 size: 83 x 35 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 646 char: 80 x 34 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 665 size: 832 x 19 new: 0 char left: 0 top: 35 size: 83 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 19 char: 80 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 (set-frame-parameter frame 'fullscreen 'fullheight) nil frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 frame text pixel: 800 x 684 cols/lines: 80 x 36 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 832 x 665 new: 0 char left: 0 top: 0 size: 83 x 35 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 646 char: 80 x 34 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 665 size: 832 x 19 new: 0 char left: 0 top: 35 size: 83 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 19 char: 80 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 (set-frame-parameter frame 'fullscreen 'fullwidth) nil (window--dump-frame frame) nil frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 frame text pixel: 800 x 684 cols/lines: 80 x 36 tool: 0 scroll: 16/0 fringe: 16 border: 0 right: 0 bottom: 0 #<window 5 on *scratch*> parent: nil pixel left: 0 top: 0 size: 832 x 665 new: 0 char left: 0 top: 0 size: 83 x 35 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 646 char: 80 x 34 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 19 divider: 0 #<window 6 on *Minibuf-0*> parent: nil pixel left: 0 top: 665 size: 832 x 19 new: 0 char left: 0 top: 35 size: 83 x 1 new: 0 normal: 1.0 x 1.0 new: 0 body pixel: 800 x 19 char: 80 x 1 width left fringe: 8 left margin: 0 right margin: 0 width right fringe: 8 scroll-bar: 16 divider: 0 height header-line: 0 mode-line: 0 divider: 0 [-- Attachment #2: Screenshot from 2017-04-03 18-14-38.png --] [-- Type: application/octet-stream, Size: 1628102 bytes --] ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-04 0:35 ` david @ 2017-04-04 7:25 ` martin rudalics 2017-04-07 0:12 ` david 0 siblings, 1 reply; 27+ messages in thread From: martin rudalics @ 2017-04-04 7:25 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > (frame-edges frame 'outer=edges) 'outer-edges please > (599 256 1431 940) (599 256 1431 940) (599 256 1431 940)) The first value looks wrong supposedly due to the outer=edges mishap. > ;; Immediately after maximizing by clicking on the top-right +. Note that > the value of frame is > ;; different. > frame > #<frame *scratch* 0x131b0b0> That's normal. The notation is cryptic but people are fond of it. However, these values > (outer-size 2048 . > 1114) ... > (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151)) sampled from GTK clearly mismatch those of the Emacs window management routines > frame pixel: 832 x 684 cols/lines: 84 x 36 units: 10 x 19 > frame text pixel: 800 x 684 cols/lines: 80 x 36 and represent what you see on your images: A window manager window of 2048 x 1114 pixels and an embedded Emacs frame of 832 x 684 pixels. The size has not propagated properly. > ;; Just after obtaining the information above the (real, not reported) > workarea expanded to its > ;; "proper" maximized size with no intentional input from me. I ran the > checks again, and the > ;; results are different. Now > (outer-size 2048 . > 1114) ... > (0 100 2048 1151) (0 100 2048 1151) (0 100 2048 1151)) are as before but > frame pixel: 2048 x 1051 cols/lines: 205 x 55 units: 10 x 19 > frame text pixel: 2016 x 1051 cols/lines: 201 x 55 show that Emacs caught up with GTK. What happens when you click the ‘+’ button three times in a row? BTW, I suppose that this behavior shows up only in your ssh setup and you cannot repeat it without tunneling. Do you observe a similar behavior via ssh when you substantially change the frame size via ‘set-frame-size’? Also, did you try the ssh experiment with your 23.2 build? And it would be interesting if you were able to reproduce the behavior with a 25.2 Lucid or Motif build. > ;; I started a new emacs and ran (setq frame (make-frame '((tool-bar-lines > . 0))) ). Then I set the > ;; fullscreen parameter with results indicated below. > > (set-frame-parameter frame 'fullscreen 'maximized) > ;; The outersize changed to fullscreen, the (real) workarea did not change > in size, but it did > ;; relocate to Left Top. In other words the result was very similar to a > normal, problem, start. > > (set-frame-parameter frame 'fullscreen 'fullboth) > ;; From the position above, this caused the outerframe to increase in > size, eliminating the frame > ;; border. The workarea moved, further Left Top, but did not change in > size. With other words the behavior is the same regardless of whether you use `set-frame-parameter', M-F10 or the ‘+’ button on the title bar. > (set-frame-parameter frame 'fullscreen 'fullheight) > (set-frame-parameter frame 'fullscreen 'fullwidth) > ;; I have never used these, so I do not know how they are intended to > work. After these, the shape > ;; changed to fullheight and fullwidth, respectively. The other dimension > changed to the width and > ;; height of the workarea and the whole outershape moved so that it was > centered horizontally and > ;; vertically respectively. The attached screenshot shows one of these > configurations. I can't tell about these because you haven't included the ‘frame-geometry’ output but I suppose they won't tell us anything new. Thanks, martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-04 7:25 ` martin rudalics @ 2017-04-07 0:12 ` david 2017-04-07 5:56 ` martin rudalics 0 siblings, 1 reply; 27+ messages in thread From: david @ 2017-04-07 0:12 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org Hello Martin, I have started to use the 26.0.50 master and can conform that your recent modification appears to have corrected problem 1. Also problem 2 has not been observed in 26.0.50. Thank you. This observation may be a little premature, I have seen a couple of surprising effects. But I have been altering code trying to get some data for problem 3, and it is possible that this caused some unexpected excursions. Unfortunately, problem 3 is alive and well; I shall write again if and when I have data that looks useful. I shall address your most recent questions as well. If you have any ideas that you would like me to try, please let me know. David ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-07 0:12 ` david @ 2017-04-07 5:56 ` martin rudalics 2017-04-07 21:16 ` david 2017-04-07 21:19 ` david 0 siblings, 2 replies; 27+ messages in thread From: martin rudalics @ 2017-04-07 5:56 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > Unfortunately, problem 3 is alive and well; I shall write again if and > when I have data that looks useful. I shall address your most recent > questions as well. If you have any ideas that you would like me to try, > please let me know. Build 26.0.50 with any of the other toolkits (Lucid, Motif) or without toolkit support and tell me whether the problem persists. This way we can at least rule out that this is a GTK specific bug (which is always the major first step with GNU/Linux builds on graphical terminals) martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-07 5:56 ` martin rudalics @ 2017-04-07 21:16 ` david 2022-04-25 14:48 ` Lars Ingebrigtsen 2017-04-07 21:19 ` david 1 sibling, 1 reply; 27+ messages in thread From: david @ 2017-04-07 21:16 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org Hello Martin, The summary conclusion is that Problem 3 exists both with and without GTK. The results are somewhat fascinating because of the differences in performance, which, of course, you cannot see. Sometimes problem 3 is easy to see, sometimes it takes several frame creations and deletions. There is one result where running over the network improves performance! Running over the network is included because the results, and what I see, make it hard to avoid speculating that timing/race conditions are at the root of problem 3. Here is some detail. Computer Mneme and Erota run Linux Mint 18.1, computer Thalia runs Trisquel 7. I run emacs on all three, sometimes over my small network. A "No" entry for problem 3 really means "Not Yet"; but I have tried many times to generate the problem. Sometimes it is possible to see the separation of the emacs frame and the WM window. There can be a short period before the two coalesce (flashing), or the two may stay separated. Version Run Toolkit Display Problem3 25.1 Mneme GTK3 Mneme Yes GTK3 Thalia No This is a surprising result, given the above; it can be viewed as a performance improvement. Erota Yes Yes, but very rare. 25.1 Thalia No Thalia Yes Yes, but rare. Mneme Yes 26.0.50 Thalia No Thalia Yes Mneme Yes This shows both short period and permanent frame separation. 25.1 Erota No Erota Yes Mneme Yes 26.0.50 Erota GTK3 Erota No Mneme No ========================================================================== ========================================================================== Mneme runs 25.1 It was created by GNU Emacs configure 25.1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = Mneme uname -m = x86_64 uname -r = 4.4.0-53-generic uname -s = Linux uname -v = #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11" configure: exit 0 ========================================================================== ========================================================================== Thalia runs 25.1 and 26.0.50 It was created by GNU Emacs configure 25.1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --with-x-toolkit=no ## --------- ## ## Platform. ## ## --------- ## hostname = Thalia uname -m = x86_64 uname -r = 3.13.0-113-lowlatency uname -s = Linux uname -v = #160+7.0trisquel2 SMP PREEMPT Thu Mar 16 13:56:41 UTC 2017 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY ACL GNUTLS FREETYPE XFT ZLIB X11" configure: exit 0 ========================================================================== It was created by GNU Emacs configure 26.0.50, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --without-makeinfo --with-x-toolkit=no ## --------- ## ## Platform. ## ## --------- ## hostname = Thalia uname -m = x86_64 uname -r = 3.13.0-113-lowlatency uname -s = Linux uname -v = #160+7.0trisquel2 SMP PREEMPT Thu Mar 16 13:56:41 UTC 2017 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY ACL GNUTLS FREETYPE XFT ZLIB X11" configure: exit 0 ========================================================================== ========================================================================== Erota runs 25.1 and 26.0.50 It was created by GNU Emacs configure 25.1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --with-x-toolkit=no ## --------- ## ## Platform. ## ## --------- ## hostname = Erota uname -m = x86_64 uname -r = 4.4.0-53-generic uname -s = Linux uname -v = #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB X11" configure: exit 0 ========================================================================== It was created by GNU Emacs configure 26.0.50, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --without-makeinfo ## --------- ## ## Platform. ## ## --------- ## hostname = Erota uname -m = x86_64 uname -r = 4.4.0-53-generic uname -s = Linux uname -v = #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11" configure: exit 0 ========================================================================== ========================================================================== On Fri, 07 Apr 2017 07:56:28 +0200, martin rudalics <rudalics@gmx.at> wrote: >> Unfortunately, problem 3 is alive and well; I shall write again if and > > when I have data that looks useful. I shall address your most recent > > questions as well. If you have any ideas that you would like me to try, > > please let me know. > > Build 26.0.50 with any of the other toolkits (Lucid, Motif) or without > toolkit support and tell me whether the problem persists. This way we > can at least rule out that this is a GTK specific bug (which is always > the major first step with GNU/Linux builds on graphical terminals) > > martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-07 21:16 ` david @ 2022-04-25 14:48 ` Lars Ingebrigtsen 2022-05-24 12:50 ` Lars Ingebrigtsen 0 siblings, 1 reply; 27+ messages in thread From: Lars Ingebrigtsen @ 2022-04-25 14:48 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org <david@ngdr.net> writes: > The summary conclusion is that Problem 3 exists both with and without GTK. (I'm going through old bug reports that unfortunately weren't resolved at the time.) Skimming this bug reports, it seems like some of the issues were fixed, but some remained. This was five years ago, though -- are you still seeing these issues with more recent versions of Emacs or the OS? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2022-04-25 14:48 ` Lars Ingebrigtsen @ 2022-05-24 12:50 ` Lars Ingebrigtsen 0 siblings, 0 replies; 27+ messages in thread From: Lars Ingebrigtsen @ 2022-05-24 12:50 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org, martin rudalics Lars Ingebrigtsen <larsi@gnus.org> writes: > Skimming this bug reports, it seems like some of the issues were fixed, > but some remained. This was five years ago, though -- are you still > seeing these issues with more recent versions of Emacs or the OS? More information was requested, but no response was given within a month, so I'm closing this bug report. If the problem still exists, please respond to this email and we'll reopen the bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-07 5:56 ` martin rudalics 2017-04-07 21:16 ` david @ 2017-04-07 21:19 ` david 2017-04-08 9:00 ` martin rudalics 1 sibling, 1 reply; 27+ messages in thread From: david @ 2017-04-07 21:19 UTC (permalink / raw) To: martin rudalics; +Cc: 25943@debbugs.gnu.org [-- Attachment #1: Type: text/plain, Size: 99 bytes --] The attachment is a repeat of my last post. I hope this will resolve the format problems. David [-- Attachment #2: mail-7Apr17 --] [-- Type: text/plain, Size: 5161 bytes --] Hello Martin, The summary conclusion is that Problem 3 exists both with and without GTK. The results are somewhat fascinating because of the differences in performance, which, of course, you cannot see. Sometimes problem 3 is easy to see, sometimes it takes several frame creations and deletions. There is one result where running over the network improves performance! Running over the network is included because the results, and what I see, make it hard to avoid speculating that timing/race conditions are at the root of problem 3. Here is some detail. Computer Mneme and Erota run Linux Mint 18.1, computer Thalia runs Trisquel 7. I run emacs on all three, sometimes over my small network. A "No" entry for problem 3 really means "Not Yet"; but I have tried many times to generate the problem. Sometimes it is possible to see the separation of the emacs frame and the WM window. There can be a short period before the two coalesce (flashing), or the two may stay separated. Version Run Toolkit Display Problem3 25.1 Mneme GTK3 Mneme Yes GTK3 Thalia No This is a surprising result, given the above; it can be viewed as a performance improvement. Erota Yes Yes, but very rare. 25.1 Thalia No Thalia Yes Yes, but rare. Mneme Yes 26.0.50 Thalia No Thalia Yes Mneme Yes This shows both short period and permanent frame separation. 25.1 Erota No Erota Yes Mneme Yes 26.0.50 Erota GTK3 Erota No Mneme No ========================================================================== ========================================================================== Mneme runs 25.1 It was created by GNU Emacs configure 25.1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure ## --------- ## ## Platform. ## ## --------- ## hostname = Mneme uname -m = x86_64 uname -r = 4.4.0-53-generic uname -s = Linux uname -v = #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11" configure: exit 0 ========================================================================== ========================================================================== Thalia runs 25.1 and 26.0.50 It was created by GNU Emacs configure 25.1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --with-x-toolkit=no ## --------- ## ## Platform. ## ## --------- ## hostname = Thalia uname -m = x86_64 uname -r = 3.13.0-113-lowlatency uname -s = Linux uname -v = #160+7.0trisquel2 SMP PREEMPT Thu Mar 16 13:56:41 UTC 2017 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY ACL GNUTLS FREETYPE XFT ZLIB X11" configure: exit 0 ========================================================================== It was created by GNU Emacs configure 26.0.50, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --without-makeinfo --with-x-toolkit=no ## --------- ## ## Platform. ## ## --------- ## hostname = Thalia uname -m = x86_64 uname -r = 3.13.0-113-lowlatency uname -s = Linux uname -v = #160+7.0trisquel2 SMP PREEMPT Thu Mar 16 13:56:41 UTC 2017 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY ACL GNUTLS FREETYPE XFT ZLIB X11" configure: exit 0 ========================================================================== ========================================================================== Erota runs 25.1 and 26.0.50 It was created by GNU Emacs configure 25.1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --with-x-toolkit=no ## --------- ## ## Platform. ## ## --------- ## hostname = Erota uname -m = x86_64 uname -r = 4.4.0-53-generic uname -s = Linux uname -v = #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB X11" configure: exit 0 ========================================================================== It was created by GNU Emacs configure 26.0.50, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./configure --without-makeinfo ## --------- ## ## Platform. ## ## --------- ## hostname = Erota uname -m = x86_64 uname -r = 4.4.0-53-generic uname -s = Linux uname -v = #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 skip .... #define EMACS_CONFIG_FEATURES "XPM JPEG TIFF GIF PNG SOUND DBUS GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11" configure: exit 0 ========================================================================== ========================================================================== ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-04-07 21:19 ` david @ 2017-04-08 9:00 ` martin rudalics 0 siblings, 0 replies; 27+ messages in thread From: martin rudalics @ 2017-04-08 9:00 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > The results are somewhat fascinating because of the differences in > performance, which, of course, you cannot see. Sometimes problem 3 is > easy to see, sometimes it takes several frame creations and deletions. > There is one result where running over the network improves performance! > Running over the network is included because the results, and what I see, > make it hard to avoid speculating that timing/race conditions are at the > root of problem 3. If > 25.1 Mneme GTK3 Mneme Yes > 25.1 Thalia No Thalia Yes Yes, but rare. > 26.0.50 Thalia No Thalia Yes > 25.1 Erota No Erota Yes below mean that the network was not involved, then the results below don't seem to confirm that speculation. > Here is some detail. Computer Mneme and Erota run Linux Mint 18.1, > computer Thalia runs Trisquel 7. I run emacs on all three, sometimes over > my small network. > > A "No" entry for problem 3 really means "Not Yet"; but I have tried many > times to generate the problem. > > Sometimes it is possible to see the separation of the emacs frame and the > WM window. There can be a short period before the two coalesce > (flashing), or the two may stay separated. Does "stay separated" mean that the separation continues forever even after showing another buffer in the frame, splitting its root window, demaximizing and again maximizing it? > Version Run Toolkit Display Problem3 > 25.1 Mneme GTK3 Mneme Yes > GTK3 Thalia No This is a surprising result, > given the above; it can be > viewed as a performance > improvement. > Erota Yes Yes, but very rare. > > 25.1 Thalia No Thalia Yes Yes, but rare. > Mneme Yes > 26.0.50 Thalia No Thalia Yes > Mneme Yes This shows both short period > and permanent frame separation. > > 25.1 Erota No Erota Yes > Mneme Yes > 26.0.50 Erota GTK3 Erota No > Mneme No The last two lines seem to indicate that running a GTK3 build of 26.0.50.0 on Erota gives the best results. Did you try 26.0.50.0 GTK3 builds for your Thalia and Mneme machines? martin ^ permalink raw reply [flat|nested] 27+ messages in thread
* bug#25943: 21.5 Frame Display Difficulties 2017-03-23 7:59 ` martin rudalics 2017-03-28 22:43 ` david @ 2017-04-11 6:49 ` martin rudalics 1 sibling, 0 replies; 27+ messages in thread From: martin rudalics @ 2017-04-11 6:49 UTC (permalink / raw) To: david; +Cc: 25943@debbugs.gnu.org > I've pushed a fix to master now. So if you can work with master please > update your copy and set, in your init file, the variable > `x-gtk-use-window-move' to t and see whether your problem one is fixed > now. Setting `x-gtk-use-window-move' is no more necessary. The variable is now t by default. martin ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2022-05-24 12:50 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-03-03 3:51 bug#25943: 21.5 Frame Display Difficulties david
2017-03-03 8:13 ` martin rudalics
[not found] ` <af552a322a8a630796cbddf1133b6dbe@127.0.0.1>
2017-03-04 9:59 ` martin rudalics
2017-03-07 1:51 ` david
2017-03-07 9:45 ` martin rudalics
2017-03-08 22:58 ` david
2017-03-09 8:56 ` martin rudalics
2017-03-10 18:44 ` david
2017-03-11 10:21 ` martin rudalics
2017-03-23 7:59 ` martin rudalics
2017-03-28 22:43 ` david
2017-03-29 7:36 ` martin rudalics
2017-03-29 19:53 ` david
2017-03-30 7:29 ` martin rudalics
2017-04-01 4:35 ` david
2017-04-01 7:36 ` martin rudalics
[not found] ` <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1>
2017-04-02 7:55 ` martin rudalics
2017-04-04 0:35 ` david
2017-04-04 7:25 ` martin rudalics
2017-04-07 0:12 ` david
2017-04-07 5:56 ` martin rudalics
2017-04-07 21:16 ` david
2022-04-25 14:48 ` Lars Ingebrigtsen
2022-05-24 12:50 ` Lars Ingebrigtsen
2017-04-07 21:19 ` david
2017-04-08 9:00 ` martin rudalics
2017-04-11 6:49 ` martin rudalics
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).