Child frame not resizing to fit candidates #2

Koekelas · 2018-07-10T13:54:28Z

When the child frame is shown, it fits the initial candidates. When you interact with the child frame (e.g. type or scroll), it doesn't resize, resulting in cut off candidates. Look at the two cut off autoload candidates.

This also happens on a clean Emacs.

Koekelas · 2018-07-15T10:14:45Z

I'm trying to debug this, but so far no luck.

Some additional observations:

I can reproduce this on my primary machine (Linux 4.17.5, GNOME 3.28.2, Emacs 26.1) but not on my secondary machine (Windows 8, Emacs 26.1)
When current loses/regains focus (by executing eval-expression), the child window resizes.

tumashu · 2018-07-15T10:27:24Z

Switch anothet WM, and try again, maybe gnome problem

Koekelas · 2018-07-16T19:14:22Z

I tried your suggestion inside a VM. I can't reproduce this on KDE Neon (KDE/KWin). I also tried Fedora Workstation (GNOME/Mutter), both the Wayland and the X.Org session. I can reproduce it on Fedora. So, something GNOME specific.

0x3UH4224D · 2018-08-11T05:37:15Z

Same here on GNOME 3.28.2, Emacs 26.1.

andreyorst · 2019-06-03T05:50:41Z

Seems like I'm experiencing the same issue:

nicber · 2019-09-30T14:25:50Z

Related bug: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1733

dgutov · 2019-12-14T20:04:09Z

I'm also seeing this problem.

@tumashu GNOME is the most popular Linux DE. Shouldn't we do something?

If it's the problem in how child frame is implemented, could you file an Emacs bug report with a reproduction scenario that our windowing subsystem devs can understand?

dgutov · 2020-01-18T12:21:14Z

Some questions to help debug this problem with Emacs developers:

Is everybody seeing this problem using GNOME?
Is everybody using Mutter as the WM, or somebody with Metacity as well?
Does anyone with this problem have a non-HiDPI (i.e. normal resolution) monitor?

andreyorst · 2020-01-18T12:46:03Z

1,2: This is Gnome only Mutter problem, the bug was reported several month ago, see: https://gitlab.gnome.org/GNOME/mutter/issues/840 3: happens for me both on non-HiDPI and on HiDPI

dgutov · 2020-01-18T13:09:15Z

Thanks. Martin asked whether this happens on GNOME + Metacity as well.

Koekelas · 2020-01-18T14:11:00Z

GNOME with Mutter on a non HiDPI display.

andreyorst · 2020-01-18T19:48:37Z

I'm not sure if Gnome + Metacity even exist as of today. The closest thing is Mate, a fork of Gnome2, which is using Metacity fork of theirs and it didn't had this problem when I've tested.

…

Thanks. Martin asked whether this happens on GNOME + Metacity as well. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2?email_source=notifications&email_token=AEUROTYOMJFGXQT5E2VPYQTQ6L5PXA5CNFSM4FJFZ6BKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJJX4DY#issuecomment-575897103>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEUROTZ7DYP6HYVP7O4ULCDQ6L5PXANCNFSM4FJFZ6BA> .

dgutov · 2020-01-20T13:04:19Z

Here's a workaround for y'all to try:

--- posframe.el	2019-12-16 00:37:59.392804886 +0300
+++ posframe.el	2020-01-20 15:59:50.981671559 +0300
@@ -627,13 +627,19 @@
   (if (and width height)
       (unless (equal posframe--last-posframe-size
                      (list height min-height width min-width))
-        (fit-frame-to-buffer
+        (posframe--fit-to-buffer
          posframe height min-height width min-width)
         (setq-local posframe--last-posframe-size
                     (list height min-height width min-width)))
-    (fit-frame-to-buffer
+    (posframe--fit-to-buffer
      posframe height min-height width min-width)))
 
+(defun posframe--fit-to-buffer (frame height min-height width min-width)
+  ;; GNOME Mutter workaround
+  (make-frame-invisible frame)
+  (fit-frame-to-buffer frame height min-height width min-width)
+  (make-frame-visible frame))
+
 (defun posframe--set-frame-position (posframe position
                                               parent-frame-width
                                               parent-frame-height)

I still get hellish flickering (particularly noticeable if you lean on M-n), but now much faster, and with correct resizing.

dgutov · 2020-01-20T13:34:19Z

BTW, if there's someone here who can build and debug Mutter, please speak up.

dgutov · 2020-01-20T22:12:39Z

And here's a better workaround: just build Emacs with a different toolkit.

./configure --with-x-toolkit=lucid gives me posframe that's much faster, resizes correctly even without the visibility hack above, and where flickering is basically non-existent (at least in company-posframe; ivy-posframe still has some).

dgutov · 2020-01-20T22:13:40Z

And if you have tool-bar-mode turned off, you'll likely see no practical difference.

tumashu · 2020-01-21T01:43:55Z

I have tested lucid, frame show and hide or frame move seem to very slow.

dgutov · 2020-01-21T02:44:10Z

Compared to... GTK?

andreyorst · 2020-01-21T08:58:17Z

can confirm that it is quite slow, but it certainly works with lucid. Except if slideshow experience can be described as works

dgutov · 2020-01-21T11:52:45Z

That's surprising. The Lucid build is really very fast here (GNOME 3.32.1, GTK 3.24.8). You can also try Motif, I'm seeing similar experience.

As for the GTK build, @andreyorst have you tried the workaround I posted above?

andreyorst · 2020-01-21T12:48:17Z

As for the GTK build, @andreyorst have you tried the workaround I posted above?

No, sorry for that! I'm not using company-posframe, I'm here from the https://github.com/casouri/eldoc-box package, which has the same issue with resizing child frames but doesn't use posframe inside.

dgutov · 2020-01-21T12:58:47Z

Then you can try the same approach by toggling visibility before and after the set-frame-size call in eldoc-box--update-childframe-geometry. It might actually work okay, if the eldoc box isn't shown persistently.

dgutov · 2020-01-21T13:10:03Z

Speaking of performance under Lucid, etc, it would be helpful if you and/or others posted some measuremenets.

There is an example here: https://lists.gnu.org/archive/html/emacs-devel/2020-01/msg00343.html

If you add (benchmark 10 '(resize-test test-frame)) at the bottom, what's the result?

tumashu · 2020-01-22T07:45:57Z

@dgutov

Today, I test lucid again, and find the slow may posn-at-point

(benchmark 1000 '(posn-at-point (point)))

"Elapsed time: 0.684959s"

this let posframe slow when first show posframe

         (parent-window-height (window-pixel-height parent-window))
         (position-info
          (if (integerp position)
              (posn-at-point position parent-window)
            position))
         (parent-frame (window-frame parent-window))

dgutov · 2020-01-22T10:47:16Z

@tumashu Why do you consider that slow? Do you call post-at-point more than once per action?

The same form returns 0.72s for me using a GTK build anyway.

tumashu · 2020-01-22T11:10:24Z

@dgutov I use pyim (an input method) to test posframe, and find that posn-at-point let posframe ~half second lag

andreyorst · 2020-03-13T16:23:46Z

What if you also set x-wait-for-event-timeout to 0 like the message suggests?

I've missed that part. It's much faster, but still noticeable, although I can live with it.

dgutov · 2020-03-13T16:31:31Z

So, to sum up:

the patch is an improvement (with no noticeable regressions)
emacs-27 behaves better than master
setting x-wait-for-event-timeout to 0 eliminates a visual delay

Is that right?

If you still can make a video of the lag, that would be also great.

andreyorst · 2020-03-13T16:33:01Z

I'll try to record it in two hours or tomorrow. Everything else you've listed seems correct by me

AlexLewandowski · 2020-03-14T01:21:41Z

@dgutov I just tried the patch on emacs 27.0.90 and gtk3, it seems to work very well!

andreyorst · 2020-03-16T10:38:16Z

@dgutov After several days of using this patch I think that everything is very good. No issues so far. The lag also gone for some reason.

dgutov · 2020-04-06T17:55:26Z

Good news everyone!

Emacs 27 will include a new variable called x-gtk-resize-child-frames: https://git.savannah.gnu.org/cgit/emacs.git/commit/?h=emacs-27&id=c49d379f17bcb0ce82604def2eaa04bda00bd5ec

It's sort of a stopgap, but apparently GNOME requires special handling that is not compatible with some other DEs/WMs.

So GNOME users with GTK3 builds should set this new variable to either resize-mode and restart (better behavior but not future-compatible) or hide (which is more future-proof but will blink the child frame every time it's resized).

In other news, the Lucid build should be at least as fast now (or faster) WRT to child frames. So using basically any other build than GTK3 is also a good workaround.

dgutov · 2020-04-06T17:56:01Z

@tumashu Will you add that info to README? Here, and/or in the main posframe repo.

andreyorst · 2020-04-06T18:18:32Z

This is great news! I think @casouri will be interested in adding this info to README as well

IIUC @dgutov patch was merged and available on master right now?

dgutov · 2020-04-06T18:24:26Z

It's in the release branch now. Should be merged to master in a few days or so.

casouri · 2020-04-06T18:42:07Z

Good, I'll add it to eldoc-box's readme.

tumashu/company-posframe#2

tumashu · 2020-04-07T01:47:12Z

@dgutov Info has been added, thanks very very very much for your and Martin Rudalics hard word, if no your long disscuss and coding, this problem can not be resolved.

dgutov · 2020-04-07T13:42:22Z

@tumashu IIUC, Mate users don't need to do this. Otherwise, the instructions look good, thanks.

dgutov · 2020-04-07T13:43:32Z

By the way, we could try to automate this.

@andreyorst Could you check the output of echo $XDG_CURRENT_DESKTOP when inside a Mate session? Does it also say GNOME?

andreyorst · 2020-04-07T14:38:41Z

By the way, we could try to automate this.

@andreyorst Could you check the output of echo $XDG_CURRENT_DESKTOP when inside a Mate session? Does it also say GNOME?

Unlikely. Unfortunately I don't use Mate, I'm on GNOME. I'll ask colleague to check, but IDK when he'll respond.

tumashu · 2020-04-07T23:38:27Z

@dgutov I have not test it by myself, but MATE is gnome2，its wm may very similar with gnome3's vm, so it may have similar problem too.

dgutov · 2020-04-07T23:50:15Z

According to @andreyorst it's using Metacity, a different window manager, and it doesn't have this problem: #2 (comment)

tumashu · 2020-04-08T00:28:09Z

OK, I will remove MATE info

tumashu · 2020-04-08T00:41:09Z

@dgutov After x-gtk-resize-child-frames set, we must restart emacs ?

dgutov · 2020-04-08T00:57:24Z

You actually need to just create a new child frame (the resize-mode value only affects new child frames).

Anyway, please wait a little for my PR. I think we really can automate this, to make it easier for a lot of users.

tumashu · 2020-04-08T01:00:13Z

ok

Allows us to bind x-gtk-resize-child-frames to an appropriate value requiring no user intervention. Discussion at tumashu/company-posframe#2. Fixes tumashu#51.

dgutov · 2020-04-08T10:44:46Z

@andreyorst

If possible, please also ask a colleague to try this:

(let ((id (x-window-property "_NET_SUPPORTING_WM_CHECK" nil "WINDOW" 0 nil t)))
  (x-window-property "_NET_WM_NAME" nil "UTF8_STRING" id nil))

Which is a method we might choose to switch to in the future.

andreyorst · 2020-04-08T11:11:12Z

@andreyorst

If possible, please also ask a colleague to try this:
(let ((id (x-window-property "_NET_SUPPORTING_WM_CHECK" nil "WINDOW" 0 nil t)))
  (x-window-property "_NET_WM_NAME" nil "UTF8_STRING" id nil))
Which is a method we might choose to switch to in the future.

unfortunately he's working from home right now using his Mac, so he can't access mate right now. He's not Emacs user, so I can't help with that test much.

dgutov · 2020-04-08T11:19:12Z

That's ok, thanks.

andreyorst · 2020-04-09T18:55:28Z

it prints MATE вт, 7 апр. 2020 г., 16:43 Dmitry Gutov <notifications@github.com>:

…

By the way, we could try to automate this. @andreyorst <https://github.com/andreyorst> Could you check the output of echo $XDG_CURRENT_DESKTOP when inside a Mate session? Does it also say GNOME? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEUROT7OWIHSXAGNTU3LQ7DRLMUZJANCNFSM4FJFZ6BA> .

dgutov · 2020-04-09T19:12:29Z

Thank you. Then the current solution in posframe should work all right.

andreyorst · 2020-04-16T14:40:35Z

It seems that changes finally hit the master branch and I no longer need to patch my build! Gonna say that everything works great on GNOME now.

hedning mentioned this issue Dec 5, 2018

company-posframe-show: pass exact height and width (should improve performance) #4

Merged

andreyorst mentioned this issue Jun 5, 2019

Utilize the posframe package casouri/eldoc-box#11

Open

dgutov mentioned this issue Dec 18, 2019

Performance problems #17

Closed

tumashu mentioned this issue Jan 22, 2020

Posframe is slow if emacs is built using athena/lucid toolkit tumashu/posframe#45

Closed

DogLooksGood mentioned this issue Mar 15, 2020

使用posframe做候选框，有时候显示候选词不全 DogLooksGood/emacs-rime#14

Closed

tumashu added a commit to tumashu/posframe that referenced this issue Apr 7, 2020

Add information about x-get-resize-child-frames

9cf47ff

tumashu/company-posframe#2

akermu mentioned this issue Nov 16, 2020

Massive scroll bar sebastiencs/company-box#44

Open

Child frame not resizing to fit candidates #2

Child frame not resizing to fit candidates #2

Comments

Koekelas commented Jul 10, 2018 • edited Loading

Koekelas commented Jul 15, 2018 • edited Loading

tumashu commented Jul 15, 2018

Koekelas commented Jul 16, 2018

0x3UH4224D commented Aug 11, 2018

andreyorst commented Jun 3, 2019

nicber commented Sep 30, 2019

dgutov commented Dec 14, 2019

dgutov commented Jan 18, 2020

andreyorst commented Jan 18, 2020 via email • edited Loading

dgutov commented Jan 18, 2020

Koekelas commented Jan 18, 2020

andreyorst commented Jan 18, 2020 via email • edited Loading

dgutov commented Jan 20, 2020

dgutov commented Jan 20, 2020

dgutov commented Jan 20, 2020 • edited Loading

dgutov commented Jan 20, 2020

tumashu commented Jan 21, 2020 • edited Loading

dgutov commented Jan 21, 2020

andreyorst commented Jan 21, 2020

dgutov commented Jan 21, 2020

andreyorst commented Jan 21, 2020

dgutov commented Jan 21, 2020

dgutov commented Jan 21, 2020

tumashu commented Jan 22, 2020 • edited Loading

dgutov commented Jan 22, 2020 • edited Loading

tumashu commented Jan 22, 2020

andreyorst commented Mar 13, 2020

dgutov commented Mar 13, 2020

andreyorst commented Mar 13, 2020

AlexLewandowski commented Mar 14, 2020

andreyorst commented Mar 16, 2020

dgutov commented Apr 6, 2020

dgutov commented Apr 6, 2020

andreyorst commented Apr 6, 2020

dgutov commented Apr 6, 2020

casouri commented Apr 6, 2020

tumashu commented Apr 7, 2020

dgutov commented Apr 7, 2020

dgutov commented Apr 7, 2020

andreyorst commented Apr 7, 2020

tumashu commented Apr 7, 2020

dgutov commented Apr 7, 2020

tumashu commented Apr 8, 2020

tumashu commented Apr 8, 2020

dgutov commented Apr 8, 2020

tumashu commented Apr 8, 2020

dgutov commented Apr 8, 2020 • edited Loading

andreyorst commented Apr 8, 2020

dgutov commented Apr 8, 2020

andreyorst commented Apr 9, 2020 via email

dgutov commented Apr 9, 2020

andreyorst commented Apr 16, 2020

Koekelas commented Jul 10, 2018 •

edited

Loading

Koekelas commented Jul 15, 2018 •

edited

Loading

andreyorst commented Jan 18, 2020 via email •

edited

Loading

andreyorst commented Jan 18, 2020 via email •

edited

Loading

dgutov commented Jan 20, 2020 •

edited

Loading

tumashu commented Jan 21, 2020 •

edited

Loading

tumashu commented Jan 22, 2020 •

edited

Loading

dgutov commented Jan 22, 2020 •

edited

Loading

dgutov commented Apr 8, 2020 •

edited

Loading