Conflict with eyebrowse package

[dchrzanowski]

If there is only one eyebrowse workspace the point blinks and has this nice smooth-fading transition. If there is more than one workspace in eyebrowse then the beacon still appears but does not have a transition it just instantly disappears after beacon-blink-durationruns out.

EDIT:
It seems that sometimes a few workspaces need to exist for the issues to be properly replicated.

[vlthr]

I am also having this issue. Seems to occur for me almost every time I have multiple workspaces.

[Malabarba]

How odd. Beacon has nothing to do with any other packages. It uses a timer for the fade animation.

One theory is that eyebrowse workspaces somehow reduce render performance for emacs, which causes it to be render fewer frames.

[dchrzanowski]

I thought it is quite a peculiar issue. Perhaps I should open an issue with Eyebrowse then...

[vlthr]

I spent some time debugging this issue and may be able to offer some leads towards a solution.

The issue seems to be caused by the fact that beacon uses the before-change-functions hook to run beacon--vanish. Eyebrowse uses format-spec to create its modeline, which (according to the creator of eyebrowse, see here) uses a temp buffer to make changes. This modeline update runs very frequently, including on each movement operation. Each change to the temp buffer triggers the before-change-functions hook and causes beacon--vanish to run.

Removing the before-changes-function hook in beacon fixes the issue, but there are a few things that I haven't quite managed to figure out yet:

• beacon--vanish does check if the name of the buffer being changed is *temp-buffer*, but in my emacs the temp buffer is actually named *temp*. I thought I could fix the issue by just adding *temp* to the list of ignored buffer names, but this actually caused some error messages from eyebrowse.
• For some reason running beacon--vanish a bunch of times very quickly after focus changes (as happens due to the before-change-functions hook) does not actually remove the overlay. It just clears beacon--ovs. Is there some race condition here, or something else I am missing?

I imagine the ideal way to fix this would be by checking that the buffer that is being changed actually contains a beacon, and to only remove that beacon, rather than all beacons. Is there a good way to do that?

[azzamsa]

I read the issue in eyebrowse side. Before I don't have this problem. But it's occurred after upgrading all packages and emacs to 26.1 this morning.

Any updates on how to solve this problem ?

[Malabarba]

I've commited a potential fix that ignores the *temp* buffer. I'm not at my PC right now (in fact, I wrote the fix in Github's editor), so please let me know if it works once it's up on Melpa.

[dchrzanowski]

Good stuff, thank you! Ill get it asap

[dakra]

@Malabarba That last commit broke my Emacs config.
I don't have the exact message/backtrace anymore since I reverted the commit but it was a few different ones like match data clobbered by buffer modification hooks or args out of range ... killed buffer and killed <temp buffer` or something along those lines.
Using latest Emacs from git.

[Malabarba]

Strange. I've pushed another commit which doesn't rely on regexps at all. Let me know if it works.

[dakra]

@Malabarba yes, it was fixed with the new commit 9 days ago. Thanks.