search

microsoft / terminal

The new Windows Terminal and the original Windows console host, all in the same place!
MIT License
95.26k stars 8.27k forks source link

Command line argument to start up using a specified configuration file #6687

Open rwv37 opened 4 years ago

rwv37 commented 4 years ago

Description of the new feature/enhancement

It would be nice to have a command line argument to start up Windows Terminal using a specified configuration file; for example:

wt -c D:\MyStuff\WindowsTerminal\SomeAwesomeConfigFile.json

This would be useful in at least a couple of ways:

(1) You could easily use different config files for different purposes; for example you could easily have a taskbar icon to start up a window that you normally use for local command line stuff, and a different one to start up a different window that you normally use for ssh into some other box, and those two windows may be very different than each other.

I know that you can do something like this by having different profiles within the single config file and then having your taskbar icons set up with stuff like wt new-tab -p Local ; split-pane -p Local in one and wt new-tab -p Server ; split-pane -H -p Server in another, but that can get really out of hand really quick as you want the windows to have more and more complex default startup behavior. Seems like it would be much simpler and cleaner (for this sort of purpose) to maintain just by having two different config files.

(2) I want to keep my configuration in source control. Obviously I can do that now, but it seems like a total pain - every time I edit the file, in order to submit it to source control, I have to cd to some wacky AppData directory that I probably won't remember and that may not even be the same on different machines. Seems like it would be much, much easier and nicer to just use config files in some location that I decide upon, based upon how I actually use my computer.

If there is already a way to do this, then first of all, I apologize; I couldn't find anything like it in the docs, on the web, or via "wt -h". And second of all... how, please? Thanks.

Proposed technical implementation details (optional)

zadjii-msft commented 4 years ago

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #5465 for more discussion.

/dup #5465

ghost commented 4 years ago

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

DHowett commented 4 years ago

You may also want to follow #2933 😄

rwv37 commented 4 years ago

I might be misunderstanding something here, but it doesn't seem to me like #5465 is what I'm asking for.

That looks like it's asking for a better way to specify startup commands (like split-pane and such). I think that's a good idea too, but it's not what I'm asking for.

What I'm asking for is a way to specify, on the command line, the location of the startup configuration file -- i.e. the file where you define things like the profiles and the key bindings.

The issue that DHowett linked to, #2933, looks to me like it's more similar to what I'm asking for, and it too seems like a good idea to me, but it doesn't seem to be exactly what I'm asking for either. I don't want a way to use Roaming, which I'm totally uninterested in. And I also don't want a way (like a symlink) to trick the single hardcoded location of the settings.json file into being a different file. I want a way to get rid of the assumption that there is a single hardcoded location of the settings.json file in the first place.

It seems to me like a command line parameter would be a great way to do this. Just a simple "-c MySettings.json". If the option is not specified, default to what is currently the single hardcoded location of the settings.json file. That seems to me like it would be clean, flexible, usable, and maintainable.

And to be clear, I don't mean to imply that this should be done instead of the other suggestions. I think it should be done in addition to them.

zadjii-msft commented 4 years ago

Okay that's what I get for reading issues before coffee. That's a great explanation, and I'm gonna toss this on the backlog. Thanks for following up!

DHowett commented 4 years ago

This is subject to the same problems outlined in https://github.com/microsoft/terminal/issues/4566#issuecomment-613102437 -- except with a -c instead of an environment variable. Until we have good answers to those questions, this feature cannot make forward progress.

In addition to the list in there, I have to add:

rwv37 commented 4 years ago

I don't understand the issues being referred to, so I have no comment on them. However, I do want to say that this proposal is not (in effect) the same as supporting an environment variable, as a command line option would allow you to easily have different profiles for different purposes -- which you may even want to use simultaneously -- without the need to keep reconfiguring things. For example, you can make one shortcut with "wt -c MyHomeSettings.json" and another shortcut with "wt -c MyWorkSettings.json".

To be clear, I don't mean to imply that you were claiming that; I just wanted to be explicit about this difference.

DHowett commented 4 years ago

No, I understand. I'm trying to figure out how this works with other features we have planned:

We had another request for setting the config file path with an environment variable. The same questions need to be answered regardless of where the config file path comes from.

rwv37 commented 4 years ago

I obviously don't have a good grasp on the overall plans, so take this with a grain of salt, but for what it's worth, here are some suggestions:

(1) For starting wt from an instance of wt, I don't see why it wouldn't just obey the command you type, exactly as it would if you had instead typed it via a Run prompt, via cmd, or whatever. So, like, if I started up with wt -c x, and in that window I type wt, it should start the new one up with the default. If I type wt -c x, it should start the new one with x. And if I type wt -c y, it should start the new one up with y. How I started the one that I'm typing in doesn't really seem to me like it should be involved at all.

(2) For the jump list/shell extension stuff, when right-clicking, I guess you're saying something like this menu would pop open:

Maybe instead:

And "Config files" flies out to a submenu, which is initially:

After you add a couple config files, that submenu would now be:

Each of the items in that submenu would fly out to a list of profiles from that particular config file.

And if you change that submenu so that something other than "(Default)" is checked...

... then the top menu changes to list the profiles in that particular config file instead of those in the default config file:

DHowett commented 4 years ago

How I started the one that I'm typing in doesn't really seem to me like it should be involved at all.

A significant portion of our userbase would beg to differ :smile:

A lot of folks want wt new-tab or wt split-pane to open a new tab or split a new pane in the same window they're currently using. That's a totally valid use case that we'll need to address if we want to offer a -c option.

DHowett commented 4 years ago

Just so it's clear: i'm not asking you to answer these questions and justify your feature. They're just things that we'll need to have an answer for to go ahead with it. This is, as always, an open forum for the community!

Gram-1 commented 4 years ago

Hello, the ability do use different 'settings.json' is absolutely necessary for me too ! We need to be able to list different profile entries or different default initial rows/cols for different usages. I fully support a new command line parameter as well as the ability to change the default json file location/name. Rgds

Guiorgy commented 4 years ago

An interesting proposal, but what happens in those cases:

would you be able to have different settings for individual tabs/panes?

Gram-1 commented 4 years ago

Hello, thanks for your interest in my proposal ! My idea was initially just to be able to start two (or more) different instances of wt.exe with different settings. Regarding the behavior of wt with multiple tabs/panes, we could either use a lazy approach using the provided settings as they come, only the last being active in the end, like it's the case when you modify the settings file while the terminal runs, causing the new version to be dynamically reloaded and used for all panes. A less lazy approach would be to allow different settings for tabs/panes but it would suppose a much larger development effort I guess, and it's not really compatible with the current behavior where you chose a new tab from a list defined in the settings file itself ! I thank you again and stays open for any help I can provide Regards Olivier

Guiorgy commented 4 years ago

it's not really compatible with the current behavior where you chose a new tab from a list defined in the settings file itself

This is basically my concern too. So in the end either all -c argument would have to be ignored except for one, or -c should only be allowed after wt and not after the ;?

Gram-1 commented 4 years ago

Yes, that's what I was thinking of, only allowed after wt would suffice. Olivier

red55 commented 4 years ago

Hi everyone, My 5 cents on this issue. I have about 20 PCs and VMs where I'm using Windows Terminal. For me it's a headache to synchronize the things like font face, font size and so on. Giving me a -c option will solve my problem. More over if I could synchronize settings.json via Microsoft's or Company account like it happens with Edge's settings or VS code settings, it would be really great

jmlucjav commented 3 years ago

I have now realized there is an ever bigger reason for me to need a custom settings.json when I am going to use wt just to host neovim, as I have C-v etc for normal terminal usage, that combination is handled by wt instead of neovim, where it would be the visual block mode (which I was wondering why it was not working). This makes using wt to host neovim quite a big issue.

DanielLaberge commented 2 years ago

Please consider making this issue higher priority.

I suspect a lot of users are suffering from this pain point: they work on multiple machines and currently have no means of loading profiles from one shared location like OneDrive or Dropbox, etc. Having to manually copy and paste profiles across all our machines, everything something is added or changed is frustrating and shouldn't be required in this day and age.

The amount of comments and duplicated issues in this and #2933 should be a good indication of the interest.

Gram-1 commented 2 years ago

Hello All, I must admit this file duplication is indeed in place in our systems, but this does not address all issues. This feature should be quick to implement and is really useful. Thanks