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

support -e command line flag as an alternative to start #2782

Closed
ExpandingMan opened this issue Nov 22, 2022 · 10 comments
Closed

support -e command line flag as an alternative to start #2782

ExpandingMan opened this issue Nov 22, 2022 · 10 comments
Labels
enhancement New feature or request fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.

Comments

@ExpandingMan
Copy link

Admittedly wezterm's CLI wezterm start -- args is undoubtedly better than using a flag like -e, however tons of linux stuff assumes that any terminal will have the -e flag. Examples include rofi, rifle and whatever the hell happens when you run *.desktop files (which is not a behavior that's exclusive to desktop environments as other programs can try to run these).

It would therefore be really nice if in addition to the current behavior, wezterm supported a -e flag as it would greatly simplify the usage of wezterm as a default terminal.

@ExpandingMan ExpandingMan added the enhancement New feature or request label Nov 22, 2022
@vimpostor
Copy link
Contributor

vimpostor commented Nov 25, 2022

Have you seen #2670? Support for -e is already implemented, i.e. you can use wezterm start -e bash.

Note that right now you still have to specify the start in wezterm start, i.e. wezterm -e bash does not work. Given that wezterm defaults to wezterm start it might make sense to accept just wezterm -e command as well.
Is this what you want or is #2670 enough for you?

Also see #2622

@ExpandingMan
Copy link
Author

Thanks, I was not aware of that. Indeed, I don't feel that really solves the problem, even wezterm start -e will require special handling in many contexts. It would make things far simpler to accept wezterm -e.

@vimpostor
Copy link
Contributor

vimpostor commented Nov 26, 2022 via email

@ExpandingMan
Copy link
Author

Yes, wezterm start -e does mostly fix this issue, but, at least for me personally, it's still kind of annoying. If, for example, you expect to just set the terminal in some environment variable, wezterm now needs special handling compared to every other terminal. This is because, though simply setting wezterm start works fine to directly launch terminal applications, for wezterm (and only for wezterm) the command for starting a terminal application is different than starting the terminal itself.

@wez
Copy link
Owner

wez commented Dec 2, 2022

@vimpostor if you can find a way to treat -e as an alias for start in clap, that feels conceptually clean.
I have my doubts that it will be that clean and simple though!

@Abdiramen
Copy link
Contributor

@wez if alias is an acceptable solution to this problem is there any issue with just slapping #[command(alias = "-e")] above:

pub struct StartCommand {

@wez
Copy link
Owner

wez commented Dec 24, 2022

I don't know; I haven't tried it, and it's not high on my list of things to try. If it works, then that would be good. I have my doubts about it, as argument parsing typically uses - to indicate an argument rather than a subcommand.

@Abdiramen
Copy link
Contributor

I can try it out! If it works I'll send out a PR.

wez added a commit that referenced this issue Dec 25, 2022
yue4u added a commit to yue4u/zf that referenced this issue Dec 29, 2022
8b05fdba8 ci: apparently GH_TOKEN is what it really should be
f2632c32f Fix typo
040fa0793 Tweak labels in the menubar/command palette
a31ba8738 ssh: respect AddressFamily for environments with broken ipv6
ff2caf4f6 cargo update
c39bbbb45 docs: changelog for wez/wezterm#2782
e8886752e Add the hidden alias `-e` for the `start` subcommand. (#2889)
378853f5a palette: add icons for a number of entries
b2e694032 box model: improve max width constraint for more complex elements
b52ccfe36 palette: adjust group prefix when menubar is empty
b1c3103a0 macos: update menubar when the config reloads
1fad25e92 include key assignments in palette and menubar
85afd9b59 tidy up macos menubar key assignment
1cdf74d19 menubar: re-categorize attach/detach
b12506ea3 command palette: tweak for empty doc case
3a9513e19 improve width constraints in box_model, center command palette
b789ec447 synthesize commands from domains, workspaces
ab8a4f129 command palette: first pass
295e0c444 ci: potentially fixup flakey pages build
6479df63b removed deprecated Copy, Paste, PastePrimarySelection actions

git-subtree-dir: crates/wezterm
git-subtree-split: 8b05fdba84d84ba15cead3e71abe507b66a78d67
@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Feb 7, 2023
@wez wez closed this as completed Feb 7, 2023
@ExpandingMan
Copy link
Author

Thanks all!

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 10, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants