Conflict with helm-M-x

[artemkovalyov]

With the latest Helm and centaur-tabs I had an issue that invoking helm-M-x led to the latter not showing the list of initial candidates. I found it by disabling and re-enabling centaur-tabs which proved to be causing an issue. It seems like a visual effect because the helm buffer shows content from a frame below it, but not the initial candidates list. When I start typing it works again.

I created this Stack Overflow issue with screenshots before finding out the issue by myself. I disabled almost everything except tabs and helm https://stackoverflow.com/questions/62658123/helm-m-x-doesnt-show-initial-list-of-candidates

Seems like some visualization bug to me. It should be easy to reproduce. I tested on Emacs 27.x and 28.0.50

[ema2159]

Hello! I'm not a Helm user but I'll try to give it a check in order to solve this. Currently I'm dealing with implementing a tabs per window functionality so it may take some time.

[artemkovalyov]

@ema2159, I think you're doing a great job and I enjoyed using Centraur Tabs for quite some time. It's not a blocker for me at the moment. But I spent some time debugging and found the conflicting libs were helm and centaur tabs. Somehow all the Helm buffers including Helm-M-x don't show the initial suggestions list, but the buffer which it overlaps. For most of the Helm users, it will be a breaking issue.

[ema2159]

@artemkovalyov could you show me a screenshot to see exactly what you mean? By the way, thanks for the kind words! I've been working on this for a year and a couple of months or so and it has been really nice. I've learned a lot along the way.

[artemkovalyov]

@ema2159, I have a couple of screenshots on the Stack Overflow question. I wanted to record you a GIF but after cloning the latest version of Centaur Tabs via straight.el it's back to normal again. This means you can close this. I'll keep using your extension to see if this hits me again. I also missed my key bindings and flexibility you provided. Good luck with future development, Man!

[ema2159]

Awesome! Most likely it was because Helm uses the header-line if I'm not wrong. Centaur-tabs now uses the tab-line instead for Emacs 27<.
Thanks man! Enjoy the package.

[hamzadis]

I can confirm this is still an issue in 27. Here's a screenshot of 27 next to 26 showing how it's affecting 27. The helm window isn't drawn properly and you can see the contents of the scratch buffer that was there before the window popped up. Typing anything in the minibuffer updates helm and fixes the problem. I can confirm that running (helm-update) in the background also fixes the issue.

Now, after a bunch of digging, I managed to narrow the bug down to this peculiar list of conditions:

• Affects Emacs 27
• Scroll bars must be disabled
• Centaur tabs must be enabled

Here is a minimal init.el that reproduces the bug for me:

; part one of the bug
(scroll-bar-mode -1)

; add melpa so we can install helm and centaur-tabs
(require 'package)
(add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/") t)

(package-initialize)
(unless package-archive-contents
  (package-refresh-contents))

; install both packages
(dolist (package '(helm centaur-tabs))
  (unless (package-installed-p package)
    (package-install package)))

; part two of the bug
(helm-mode t)
(centaur-tabs-mode t)

; convenience
(global-set-key (kbd "M-x") 'helm-M-x)

Run emacs 27 with that, press M-x and you should be able to reproduce, unless there's even more conditions for the bug to happen.

[ema2159]

I'll have to check again. Thanks for the minimal init.el! that helps a lot. I'll try to create one myself to narrow issues down.

[hamzadis]

I assume the actual bug is probably in emacs itself, and this combination of parameters just triggers it. I don't believe any plugin should be able to cause a window to stop rendering in the way that it does here.

[ema2159]

@hamzadis that's a possibility. Also because Helm is quite heavy, these types of errors tend to occur from time to time.

[nettoyoussef]

I can reproduce the same error as @hamzadis in the setup below.

Emacs version: 27.1
Operating System: Arch Linux linux 5.8.9.arch2-1
Evil version: 1.14.0
centaur-tabs: 20200821.335
Helm: 20200910.1036
Graphical/Terminal: X window

[fernplus]

I also have the same issue with Emacs 27.1 on Win10.
Centaur-tabs version 20200821.335 and Helm 20201019.715

[SerialVelocity]

It happens on my setup without having to disable scroll-bar-mode:

Emacs version: 27.1
Operating System: macOS Catalina 10.15.7

[MoSheikh]

Same issue on my end as well on latest builds.

OS: macOS Bug Sur 11.5.1
Emacs: Version: 27.2
Helm: 20210729.1510
Centaur-tab: 20210507.1633

[indradhanush]

I have the same issue but I had scroll bar mode disabled. I have enabled it back to work around this bug. Thank you for maintaining this project so far!

OS: Linux
Emacs: GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.33, cairo version 1.17.4) of 2022-03-11

[br0xpl]

Hmm I think I found a workaround.... It seems we need to force redisplay in helm-core.el:

--- /a/helm-core.el    2023-08-31 12:33:19.793585492 +0200
+++ /b/helm-core.el        2023-08-31 12:33:37.009644643 +0200
@@ -4918,6 +4918,7 @@
            (setq val (progn ,@body))
            ;; See comments in `while-no-input' about resetting
            ;; quit-flag.
+           (redisplay)
            (cond ((eq quit-flag throw-on-input)
                   (setq quit-flag nil))
                  (quit-flag nil)

Can you please verify in your setups if the bug is over - I tested it only few hours and seems working okay.

If so we can try to file an issue at helm maybe? or maybe you have some other ideas on how to force redisplay in that moment in helm without modifying helm-core?