There seems to be no way to match windows using an exact match

[nerdo]

Steps to reproduce:

1. Launch Firefox Developer Edition
2. Use jumpapp to try and start regular Firefox with the command jumpapp -c Navigator.firefox firefox

Expected behavior:

• Regular Firefox should get run and take focus

Actual behavior:

• Firefox Developer Edition takes focus

It seems that even though I've tried to specify using the WM_CLASS for matching windows, there doesn't seem to be any way to do an exact match. The WM_CLASS for Firefox and Firefox Developer Edition are Navigator.firefox and Navigator.firefoxdeveloperedition respectively and querying jumpapp with the WM_CLASS Navigator.firefox seems to match Navigator.firefoxdeveloperedition.

Possible solution:

• Provide an argument to make the window comparison do an exact match

[mkropat]

Thanks for the detailed report. Your use case seems like something that would be reasonable to expect jumpapp to support.

It looks like there are a couple things going on here:

1. The class match is based on only the last part of the class name: https://github.com/mkropat/jumpapp/blob/944723f50c21a5771c59a2ae8e091704c1bc57c1/jumpapp#L366-L371 The key part is the ${wm_class##*.} expression. I don't remember why it was done this way.

   So you probably want to run jumpapp -c firefox … and jumpapp -c firefoxdeveloperedition … respectively. Except that …

2. The class match is an OR search along with trying for a PID match: https://github.com/mkropat/jumpapp/blob/944723f50c21a5771c59a2ae8e091704c1bc57c1/jumpapp#L150-L163 So in your example I don't think the class is matching at all, and it's finding firefox by a PID match instead. I don't remember why it was done this way, but my guess is that the intention of -c CLASS was to find the window as a backup when a PID match doesn't work.

So maybe the easiest path forward is to add an option suppressing PID matching? Or maybe a -C option that's a "must match CLASS" flag?

[nerdo]

I didn't realize the class match is meant as a backup to a PID match. It makes sense why it does what it does in that context.

Having an option to bypass that would be helpful.

[erwin]

I would also really like to suppress PID matches and ONLY match on class.

For my use case, I have different instances of kitty launched under different classes, and then different shortcuts to toggle between those classes of terminals. Unfortunately the WM_CLASS seems to be ignored if the process name matches.

Users can work around this though by launching their terminal with a wrapper script, so that the command name will never match (just use exec kitty in the wrapper script so you don't leave an extra process floating around).

For example:

jumpapp -c kittyCustomClassName ~/bin/kittyClassNameLauncher

And then kittyClassNameLauncher

#!/bin/bash

exec kitty --class kittyCustomClassName.kittyCustomClassName

[qadzek]

@erwin Thanks a ton for sharing your workaround! I tried a lot of ways to fix this issue, but your solution is just perfect.

My use case is similar: I have two terminals (Alacritty) open, one as a regular terminal to execute commands, one to read and write documentation (Vimwiki) inside Neovim. I prefer separate key bindings for these two terminals.

.xbindkeysrc: Key bindings

"jumpapp -c terminal ~/bin/terminal.sh" ...
"jumpapp -c wiki ~/bin/wiki.sh" ...

terminal.sh: Regular terminal

#!/usr/bin/env bash

exec alacritty --class terminal.terminal

wiki.sh: Terminal containing my documentation (it's even possible to directly open a particular file)

#!/usr/bin/env bash

exec alacritty --class wiki.wiki --command nvim ~/wiki/index.md