You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For some Linux users (especially those who use tiling WMs like i3), it's not unusual for multiple instances of the same terminal emulator to be open in one workspace, meaning that searching for a window by WM_CLASS alone might not be specific enough to target the intended window with SendCode. For example, a typical and fairly reasonable workspace for, say, a mixed-codebase research project might have a Sublime window, a terminal running ipython for heavy-duty processing, and another terminal running radian or julia for statistical analysis of the same project, with the user frequently bouncing between the two REPLs. (Whether or not those two REPLs would be better off inside one tmux instance is another question, of course...)
If those ipython and radian REPLs are running in separate instances of the same terminal emulator (say, both use kitty), they share WM_CLASS, but not WM_NAME. #113 from a few years ago has a similar discussion about targetting particular tmux sessions, and @randy3k seems to support the concept, but points out that hardcoding such information in a setting is not very flexible (presumably since these session names can change frequently). WM_NAME is similarly mutable; however, many popular terminal emulators (such as kitty, alacritty, terminator, etc.) support forcing a stable WM_NAME at runtime for the life of the window, and users of tiling WMs often take advantage of this feature when pre-defining the default layouts of their workspaces. I was wondering if there is any reason against adding a setting that references WM_NAME so that the windows could be disambiguated in this scenario, or if this was already dismissed as too niche of a situation to support. (Of course, the setting may be confusing to users who don't explicitly force a stable WM_NAME when opening a terminal emulator, but the instability of WM_NAME unless forced could be mentioned in the documentation for the setting.)
Assuming there's no philosophical opposition (or alternative proposal), I've submitted pull request #164 for adding an optional window_name key (or something like that) in the per-language SendCode settings blocks that may be passed to the xdotool call.
The text was updated successfully, but these errors were encountered:
On a related note, although I usually don't have multiple terminal instances on a single workspace I have multiple terminals running most of the time. In leftwm xdotool often finds the first instance on a different workspace so I made a modification
For some Linux users (especially those who use tiling WMs like i3), it's not unusual for multiple instances of the same terminal emulator to be open in one workspace, meaning that searching for a window by
WM_CLASS
alone might not be specific enough to target the intended window with SendCode. For example, a typical and fairly reasonable workspace for, say, a mixed-codebase research project might have a Sublime window, a terminal running ipython for heavy-duty processing, and another terminal running radian or julia for statistical analysis of the same project, with the user frequently bouncing between the two REPLs. (Whether or not those two REPLs would be better off inside one tmux instance is another question, of course...)If those ipython and radian REPLs are running in separate instances of the same terminal emulator (say, both use
kitty
), they shareWM_CLASS
, but notWM_NAME
. #113 from a few years ago has a similar discussion about targetting particular tmux sessions, and @randy3k seems to support the concept, but points out that hardcoding such information in a setting is not very flexible (presumably since these session names can change frequently).WM_NAME
is similarly mutable; however, many popular terminal emulators (such as kitty, alacritty, terminator, etc.) support forcing a stableWM_NAME
at runtime for the life of the window, and users of tiling WMs often take advantage of this feature when pre-defining the default layouts of their workspaces. I was wondering if there is any reason against adding a setting that referencesWM_NAME
so that the windows could be disambiguated in this scenario, or if this was already dismissed as too niche of a situation to support. (Of course, the setting may be confusing to users who don't explicitly force a stableWM_NAME
when opening a terminal emulator, but the instability ofWM_NAME
unless forced could be mentioned in the documentation for the setting.)Assuming there's no philosophical opposition (or alternative proposal), I've submitted pull request #164 for adding an optional
window_name
key (or something like that) in the per-language SendCode settings blocks that may be passed to thexdotool
call.The text was updated successfully, but these errors were encountered: