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