From: <david@ngdr.net>
To: martin rudalics <rudalics@gmx.at>
Cc: 25943@debbugs.gnu.org
Subject: bug#25943: 21.5 Frame Display Difficulties
Date: Mon, 06 Mar 2017 18:51:21 -0700 [thread overview]
Message-ID: <49adf8e1615512ac19189d75b5e04315@127.0.0.1> (raw)
In-Reply-To: <58BA900B.6040708@gmx.at>
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
next prev parent reply other threads:[~2017-03-07 1:51 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
2017-03-07 1:51 ` david [this message]
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49adf8e1615512ac19189d75b5e04315@127.0.0.1 \
--to=david@ngdr.net \
--cc=25943@debbugs.gnu.org \
--cc=rudalics@gmx.at \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).