bug#25943: 21.5 Frame Display Difficulties

[martin rudalics <rudalics@gmx.at>]

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