[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25943: 21.5 Frame Display Difficulties
From: |
martin rudalics |
Subject: |
bug#25943: 21.5 Frame Display Difficulties |
Date: |
Sat, 04 Mar 2017 10:59:39 +0100 |
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, 2017/03/02
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/03
- Message not available
- bug#25943: 21.5 Frame Display Difficulties,
martin rudalics <=
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/06
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/07
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/08
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/09
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/10
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/11
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/23
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/28
- bug#25943: 21.5 Frame Display Difficulties, martin rudalics, 2017/03/29
- bug#25943: 21.5 Frame Display Difficulties, david, 2017/03/29