[KDE] wezterm cannot be configured as default terminal because it doesn't support "-e CMD" #2622
Comments
|
I also just manually tested that using So I think implementing |
|
I think the KDE behavior is problematic and there should probably at least be an issue raised against KDE to discuss it. I'm not opposed to making small changes to wezterm make things easier in the mean time, but it's still problematic; I'm not sure how to instruct the clap crate to handle https://github.com/wez/wezterm/blob/main/assets/open-wezterm-here was added for dolphin. Maybe that concept can be extended to make that script accept and ignore Then wezterm's .desktop file can point to that script instead? |
There exists trailing_var_arg in clap exactly for this purpose
That would be a possibility but I don't think we would need to go that complicated. Also I don't really understand why the I can open an issue against KDE, but I think it is unlikely they will want to drop the |
|
The upstream KDE bug is tracked at: https://bugs.kde.org/show_bug.cgi?id=460387 Let's first wait what KDE says about this, I expect they don't want to drop the If it is indeed not fixable on the KDE side, I can look at this myself in wezterm and make a PR for you (implementing |
|
I think the opinion of KDE devs is stated in https://bugs.kde.org/show_bug.cgi?id=459616#c4. If I understand it correctly, they want to propose a change in the FreeDesktop spec, which sounds like it may take quite some time. |
Right now wezterm already allows to pass a cmdline to execute (instead of the shell) by calling "wezterm start" with trailing arguments, e.g. wezterm start -- bash However, most other terminals implement this via a "-e" option. This seems to be adopted widely in the wild, such that some third-party frameworks just blindly expect the user's terminal to use the "-e" option for this. One such notable framework is kio from KDE Plasma, that calls the user's terminal in that way when launching a desktop file that uses Terminal=true. [1] To solve this problem, we add a compatibility layer by adding a dummy "-e" option. This will then consume the "-e" leaving the remaining arguments as trailing arguments, which will later be consumed by our existing implementation in the "prog" option. Given that clap does not really support multiple arguments writing to the same destination [2], this seems like the most sane implementation, even if it is a hack. It seems to work reliable, even for edge cases where we pass wezterm options as trailing arguments, e.g. the following will just work and do the expected outcome (and will **not** parse "--position" as a wezterm argument): wezterm start -e echo --position 10,10 Fixes wez#2622 [1] https://bugs.kde.org/show_bug.cgi?id=459616 [2] clap-rs/clap#3146
In a56904e the desktop file was patched to use "wezterm start" instead of "wezterm". As an unneeded addendum that patch also included the unnecessary addition of ending command-line parsing by passing the "--" option at the end. As it turns out, some consumers of wezterm's desktop file want wezterm to parse command line flags. For example KDE's kio passes the whole cmdline via the "-e" flag, because it is widely used for most terminal emulators as the primary mean of passing the cmdline. To solve this we remove the unneeded "--" again, because we now also support the "-e" option. After all, all trailing arguments will automatically be parsed by wezterm as the cmdline of the program to run. The only sideeffect of this change is that we now cannot longer start programs that share a name with a "wezterm start" option, for example if the user has installed an executable at /usr/bin/--always-new-process then this edge case will not work anymore. Given that this would be an extremely unlikely scenario, it makes more sense to improve compatibility by supporting the usecase of passing the cmdline with the "-e" flag. refs: wez#2622 refs: wez#2271 refs: https://bugs.kde.org/show_bug.cgi?id=459616
Right now wezterm already allows to pass a cmdline to execute (instead of the shell) by calling "wezterm start" with trailing arguments, e.g. wezterm start -- bash However, most other terminals implement this via a "-e" option. This seems to be adopted widely in the wild, such that some third-party frameworks just blindly expect the user's terminal to use the "-e" option for this. One such notable framework is kio from KDE Plasma, that calls the user's terminal in that way when launching a desktop file that uses Terminal=true. [1] To solve this problem, we add a compatibility layer by adding a dummy "-e" option. This will then consume the "-e" leaving the remaining arguments as trailing arguments, which will later be consumed by our existing implementation in the "prog" option. Given that clap does not really support multiple arguments writing to the same destination [2], this seems like the most sane implementation, even if it is a hack. It seems to work reliable, even for edge cases where we pass wezterm options as trailing arguments, e.g. the following will just work and do the expected outcome (and will **not** parse "--position" as a wezterm argument): wezterm start -e echo --position 10,10 Fixes wez#2622 [1] https://bugs.kde.org/show_bug.cgi?id=459616 [2] clap-rs/clap#3146
In a56904e the desktop file was patched to use "wezterm start" instead of "wezterm". As an unneeded addendum that patch also included the unnecessary addition of ending command-line parsing by passing the "--" option at the end. As it turns out, some consumers of wezterm's desktop file want wezterm to parse command line flags. For example KDE's kio passes the whole cmdline via the "-e" flag, because it is widely used for most terminal emulators as the primary mean of passing the cmdline. To solve this we remove the unneeded "--" again, because we now also support the "-e" option. After all, all trailing arguments will automatically be parsed by wezterm as the cmdline of the program to run. The only sideeffect of this change is that we now cannot longer start programs that share a name with a "wezterm start" option, for example if the user has installed an executable at /usr/bin/--always-new-process then this edge case will not work anymore. Given that this would be an extremely unlikely scenario, it makes more sense to improve compatibility by supporting the usecase of passing the cmdline with the "-e" flag. refs: wez#2622 refs: wez#2271 refs: https://bugs.kde.org/show_bug.cgi?id=459616
In a56904e the desktop file was patched to use "wezterm start" instead of "wezterm". As an unneeded addendum that patch also included the unnecessary addition of ending command-line parsing by passing the "--" option at the end. As it turns out, some consumers of wezterm's desktop file want wezterm to parse command line flags. For example KDE's kio passes the whole cmdline via the "-e" flag, because it is widely used for most terminal emulators as the primary mean of passing the cmdline. To solve this we remove the unneeded "--" again, because we now also support the "-e" option. After all, all trailing arguments will automatically be parsed by wezterm as the cmdline of the program to run. The only sideeffect of this change is that we now cannot longer start programs that share a name with a "wezterm start" option, for example if the user has installed an executable at /usr/bin/--always-new-process then this edge case will not work anymore. Given that this would be an extremely unlikely scenario, it makes more sense to improve compatibility by supporting the usecase of passing the cmdline with the "-e" flag. refs: #2622 refs: #2271 refs: https://bugs.kde.org/show_bug.cgi?id=459616
|
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
What Operating System(s) are you seeing this problem on?
Linux X11
Which Wayland compositor or X11 Window manager(s) are you using?
KDE 5.25
WezTerm version
wezterm 20220905-102802-7d4b8249
Describe the bug
I have configured wezterm as the default terminal emulator in KDE and am using mutt as my default mail client.
When I run
xdg-open 'mailto:test@test.com', wezterm fails to start mutt with the following error message:This is because KDE assumes that terminal applications use a
-e CMDparameter to start a given command, which is the case for most terminal emulators, e.g. for konsole, gnome-terminal and alacritty.On a low level KDE calls wezterm with the following cmdline for the above
xdg-open:It would be good if wezterm supported the
-e CMDparameter as well, right now wezterm tries to start an executable with name-e.I know that the
-e CMDbehaviour is not the official XDG spec, but it is how this is unofficially working for almost all other terminal emulators so it would be great if wezterm supported this as well.Here is the current Exec line of
wezterm.desktop:And here is
mutt.desktop:The relevant part how KDE parses the desktop file when we call
xdg-opencan be found here: https://github.com/KDE/kio/blob/ad27f0e299e7a7a1f4059431f882f9a4ebba71fd/src/core/desktopexecparser.cpp#L532As you can see, KDE always prepends an
-eas that has worked for most terminal emulators.In summary we might get better compatibility, if we implement
-e CMDand do the following diff on our desktop file:What is your opinion on this? Do you think this change makes sense, or would you rather want KDE to change its behaviour as it is "non-standard"?
The text was updated successfully, but these errors were encountered: