From: martin rudalics <rudalics@gmx.at>
To: david@ngdr.net
Cc: 25943@debbugs.gnu.org
Subject: bug#25943: 21.5 Frame Display Difficulties
Date: Sat, 04 Mar 2017 10:59:39 +0100 [thread overview]
Message-ID: <58BA900B.6040708@gmx.at> (raw)
In-Reply-To: <af552a322a8a630796cbddf1133b6dbe@127.0.0.1>
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
next prev parent reply other threads:[~2017-03-04 9:59 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 3:51 bug#25943: 21.5 Frame Display Difficulties david
2017-03-03 8:13 ` martin rudalics
[not found] ` <af552a322a8a630796cbddf1133b6dbe@127.0.0.1>
2017-03-04 9:59 ` martin rudalics [this message]
2017-03-07 1:51 ` david
2017-03-07 9:45 ` martin rudalics
2017-03-08 22:58 ` david
2017-03-09 8:56 ` martin rudalics
2017-03-10 18:44 ` david
2017-03-11 10:21 ` martin rudalics
2017-03-23 7:59 ` martin rudalics
2017-03-28 22:43 ` david
2017-03-29 7:36 ` martin rudalics
2017-03-29 19:53 ` david
2017-03-30 7:29 ` martin rudalics
2017-04-01 4:35 ` david
2017-04-01 7:36 ` martin rudalics
[not found] ` <7ee8200b866d8067514fb8b0bb9e814b@127.0.0.1>
2017-04-02 7:55 ` martin rudalics
2017-04-04 0:35 ` david
2017-04-04 7:25 ` martin rudalics
2017-04-07 0:12 ` david
2017-04-07 5:56 ` martin rudalics
2017-04-07 21:16 ` david
2022-04-25 14:48 ` Lars Ingebrigtsen
2022-05-24 12:50 ` Lars Ingebrigtsen
2017-04-07 21:19 ` david
2017-04-08 9:00 ` martin rudalics
2017-04-11 6:49 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58BA900B.6040708@gmx.at \
--to=rudalics@gmx.at \
--cc=25943@debbugs.gnu.org \
--cc=david@ngdr.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.