bug#25943: 21.5 Frame Display Difficulties

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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 --]

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > \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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

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

bug#25943: 21.5 Frame Display Difficulties

[david]

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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 >> 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

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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))) ))

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[david]

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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

[-- 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 --]

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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))

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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))

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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 --]

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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 --]

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 >   (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

bug#25943: 21.5 Frame Display Difficulties

[david]

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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[david]

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

bug#25943: 21.5 Frame Display Difficulties

[david]

[-- 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

==========================================================================
==========================================================================

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[martin rudalics]

 > 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

bug#25943: 21.5 Frame Display Difficulties

[Lars Ingebrigtsen]

<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

bug#25943: 21.5 Frame Display Difficulties

[Lars Ingebrigtsen]

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