Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Won't move Emacs windows (?) #28

Open
inducer opened this issue Jan 4, 2021 · 2 comments
Open

Won't move Emacs windows (?) #28

inducer opened this issue Jan 4, 2021 · 2 comments

Comments

@inducer
Copy link

inducer commented Jan 4, 2021

As of some version of Gnome Shell 3.38 (3.38.1 maybe? Not sure. I'm now on 3.38.2 with X11, and this is still there.), some parts of Slinger (see below for which) don't seem to properly move my Emacs window any more. The following currently works for me to reproduce the issue:

  • Have a desktop with (just) Firefox and Emacs open
  • Distribute
  • Move Emacs out of position a bit (e.g. using slinger-move-left)
  • Distribute again
  • Emacs Window does not move

Curiously, slinger-move-right et al appear to work reliably, but Distribute and the Super+A-Menu tend to fail. A freshly-started Emacs doesn't seem to suffer from this (but one "Distribute" appears enough to break it).

I'm not sure other apps are affected or what's different/specific about Emacs. Other apps that are on the same desktop as Emacs may also misbehave. There's nothing in the Shell logs. I'm on 2b867b9.

I'm sorry about the fuzzy bug report. This has been annoying me for a while, but the circumstances under which it happens have remained a bit of a mystery.

@timbertson
Copy link
Owner

Guess it's time to switch to vim :trollface:

Hmm, that's very bizarre, not something I've seen or understand. A couple of clarifications:

When you say super+a tends to fail, does that mean the menu doesn't show up after this? Or that it shows up, but manipulating the emacs window via the menu doesn't work?

On the second distribute, it still leaves space for this emacs window, right? i.e. if you opened a third window (say gedit), does it place firefox+gedit side by side taking up the whole screen, or does it leave an area for emacs, but not actually move emacs into this area.

You mentioned x11 so I'm assuming there's no wayland involved, but maybe it's that emacs uses something other than gtk / qt so maybe there's some strange behaviour there.

@inducer
Copy link
Author

inducer commented Jan 6, 2021

Guess it's time to switch to vim

:) Turns out I'm mostly a Vim person already, however https://notmuchmail.org/ and https://orgmode.org/ are pretty nifty, and https://github.com/emacs-evil/evil makes the whole lot bearable.

Hmm, that's very bizarre, not something I've seen or understand.

Yeah, it's super weird and also hard to describe. I've recorded a video to clarify:

slinger-emacs.mp4

Here's what's happening in the video:

  • Up until 0:06, I fumble to focus the Emacs window.
  • Then I shrink (using Super+-) and move the Emacs window out of place (using slinger-move-*).
  • At 0:11, I use Super+a to try to move the Emacs window back where it came from.
  • In response, the size of the window changes, but it doesn't move.
  • At 0:15, in general disorientation, I guess I muscle-memory-triggered the shell overview, only to leave it again.
  • At 0:16, I use slinger-move-* to move the window back where it belongs.

no wayland involved

Yep. I'm not sure whether the same phenomenon occurs with Gnome Shell under Wayland.

On the second distribute, it still leaves space for this emacs window, right?

Yeah. It just doesn't move the window.

I currently have the following extensions enabled:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants