Import/export command line arguments for settings #9267

Closed
opened 2026-01-31 01:50:09 +00:00 by claunia · 3 comments
Owner

Originally created by @erichiller on GitHub (Jun 25, 2020).

Description of the new feature/enhancement

note: this is not for exporting only color schemes as I understand colortool already does this, this request is for actual wt settings.

Add -import <path> and -export <path> flags to wt which will then import/export from/to the given path.

It could be a simple copy and paste of the user settings or export user defined settings and on import check the schema to see if the settings file format has updated. To tell the version of the file being imported, just put a comment at the top of the settings file when it is exported.

This would provide portability between computers and easy sharing of settings between users.

Proposed technical implementation details (optional)

Originally created by @erichiller on GitHub (Jun 25, 2020). <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement *note*: this is not for exporting only color schemes as I understand `colortool` already does this, this request is for actual **wt** settings. Add `-import <path>` and `-export <path>` flags to `wt` which will then import/export from/to the given path. It could be a simple copy and paste of the user settings or export user defined settings and on import check the schema to see if the settings file format has updated. To tell the version of the file being imported, just put a comment at the top of the settings file when it is exported. <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> This would provide portability between computers and easy sharing of settings between users. # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. -->
claunia added the Issue-FeatureArea-SettingsResolution-DuplicateProduct-Terminal labels 2026-01-31 01:50:09 +00:00
Author
Owner

@DHowett commented on GitHub (Jun 26, 2020):

Hey, thanks for the request!

@zadjii-msft likely has an opinion here, but I'm inclined to say that this is better served by #2933 ("let me move my settings, or roam it" -- once it's moved, it's in an easier place from which to share it) or perhaps something under #1564 (an [export]/[import] button pair?)

I'm going to tag this up for the backlog, but: Mike, will you be my triage-second, or close this as a dupe?

@DHowett commented on GitHub (Jun 26, 2020): Hey, thanks for the request! @zadjii-msft likely has an opinion here, but I'm inclined to say that this is better served by #2933 ("let me move my settings, or roam it" -- once it's moved, it's in an easier place from which to share it) or perhaps something under #1564 (an [export]/[import] button pair?) I'm going to tag this up for the backlog, but: Mike, will you be my triage-second, or close this as a dupe?
Author
Owner

@zadjii-msft commented on GitHub (Jun 26, 2020):

Honestly yea, in my opinion the other two would serve this use case better. IMO, let's just close this one as a /dup #2933 #1564. @erichiller if you've got a compelling reason why the two aforementioned solutions wouldn't work for you, we can continue the discussion and possibly reopen.

@zadjii-msft commented on GitHub (Jun 26, 2020): Honestly yea, in my opinion the other two would serve this use case better. IMO, let's just close this one as a /dup #2933 #1564. @erichiller if you've got a compelling reason why the two aforementioned solutions _wouldn't_ work for you, we can continue the discussion and possibly reopen.
Author
Owner

@ghost commented on GitHub (Jun 26, 2020):

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!

@ghost commented on GitHub (Jun 26, 2020): 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!
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9267