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