Why can't I use Shift+Alt+$ to move a window to workspace 4?

mactyr

6/16/24, 8:39 PM

On my fairly vanilla Ubuntu 22.04 desktop installation I have six workspaces set up, and I like to have easy, explicit shortcuts for switching directly to each workspace and moving a window to each workspace. So I've set up Alt+1 to switch to workspace 1, Alt+2 to switch to workspace 2, and so on. These all work great. Then I've set up Shift+Alt+! to move a window to workspace 1, Shift+Alt+@ to move a window to workspace 2, and so on. These all work great except for Shift+Alt+$ to move a window to workspace 4, which does nothing! It seems that some other function is preempting the use of Shift+Alt+$ specifically, but I have no idea what it is or how to find out.

One possible clue: I've noticed that when I press Shift+Alt+4 when the focus is on a Terminal window, the Terminal displays a message like Display all 141 possibilities? (y or n), and if I press y, it appears to dump the names of a bunch of environment variables (e.g. BASH, BASH_ALIASES, BASH_ARGC, and so on). I don't know what command this is -- and it doesn't seem to explain why the shortcut wouldn't work when a non-Terminal window has the focus -- but maybe this Terminal behavior is related to the problem somehow?

EDIT 2023-06-25: Here is a screenshot of the relevant shortcuts in Gnome settings showing that Shift+Alt+$ is bound to "Move window to workspace 4" as intended. As mentioned above, the similar shortcuts for workspaces 1-3 work fine (as well as the ones for workspaces 5-6 that I set up on the command line) but the one for workspace 4 does nothing.

EDIT 2023-07-02: First, just to confirm that the keybindings really are set up correctly, here is an excerpt from dconf dump /:

move-to-workspace-1=['<Shift><Alt>exclam']
move-to-workspace-2=['<Shift><Alt>at']
move-to-workspace-3=['<Shift><Alt>numbersign']
move-to-workspace-4=['<Shift><Alt>dollar']
move-to-workspace-5=['<Shift><Alt>5']
move-to-workspace-6=['<Shift><Alt>6']

Again, all of these work except for the fourth one.

Second, a little research led me to discover that the "Display all X possibilities" message when I press Shift+Alt+4 in the terminal is coming from tab completion. There is an interesting result if I press Shift+Alt+4 between the double quotes in this command:

echo "" | cat -A
$

I get a single "$" as output. But, I only see the "$" if I use cat -A not plain cat, and I don't see it as I'm typing between the double quotes. So, taken together the evidence suggests that Terminal sees Shift+Alt+4 as something like <invisible "$"><tab><tab>. This explains why when I respond y to the "Display all possibilities" prompt, I basically get a list of all my environment variables, since those would be the tab completion results that start with "$".

It's a nice data point, but I still don't understand why this key combination is interpreted that way in the Terminal. If I type Shift+Alt+4 in a gedit window, for example, I see no output at all. So it doesn't generally produce a literal "$".

0 + 7

shortcut-keys

workspaces

workspace-switcher

22.04

pierrely

6/19/24, 2:30 AM

in settings, keyboard, custom shortcuts, navigation you can set your keys to switch to workspace 1, 2,3 etc.

pierrely

6/19/24, 2:55 AM

in settings, keyboard, custom shortcuts, navigation you can set your keys to switch to workspace 1, 2,3,4 but not 5,6 etc.https://askubuntu.com/questions/1015544/command-run-in-terminal-not-with-shortcutsI tried that from the command line, it would switch to #2 as typed there but not to #1. I guess it might work for 2-6. $1 + 0 did not get me #1. bash -c "wmctrl -s $(wmctrl -d | grep '*' | awk '{print $1+1}')"

mactyr

6/23/24, 4:50 PM

Thanks @pierrely, as mentioned in the question, I have already successfully set up the shortcuts I want. For desktops 1-4 I used Settings > Keyboard > Keyboard shortcuts > Navigation, and for desktops 5-6 I used `gsettings`, like `/usr/bin/gsettings set "org.gnome.desktop.wm.keybindings" "switch-to-workspace-5" "['<Alt>5']"` and `/usr/bin/gsettings set "org.gnome.desktop.wm.keybindings" "move-to-workspace-5" "['<Shift><Alt>5']"`. These all work perfectly, _except_ `Shift+Alt+$` to move a window to workspace 4, which does nothing. It seems to conflict with something else, but I don't know what.

pierrely

6/24/24, 9:27 PM

then you might use *watch* to watch for reads on that bindings file? though I am not sure if watch picks up reads. https://askubuntu.com/questions/407400/how-do-you-use-the-command-watch

mactyr

6/25/24, 3:20 PM

Interesting suggestion, but I don't think the problem is that the keybindings file is changing, since the shortcut still looks the way I originally set it up in the Gnome settings panel. I think the problem is that something else is intercepting the key combination before Gnome gets a chance to act on it, but I don't know how to figure out what other process would be interfering. I'll add a screenshot to the question to make this clearer.

pierrely

7/2/24, 1:52 AM

I think the lsof command tells what is using a file. man lsof "Lsof revision 4.93.2 lists on its standard output file information about files opened by processes for the following UNIX dialects: " so lsof | grep <nameofbindingsfile> might get some help , if too complex output that to >> lsofwatch.txt, do it again without keystroke, to lasofwatch2.txt and do a diff to compare them.

mactyr

7/3/24, 3:05 AM

@pierrely, I appreciate your efforts to help, but it seems like the problem you are trying to solve is not the one that I'm having. I don't understand how it would be helpful to know what is accessing my keybindings file; what I want to know is why this one keybinding that is defined there is not working, when the rest of them are. I've found some more clues I'll add to the question.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Why can't I use Shift+Alt+$ to move a window to workspace 4?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.