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

[REQUEST] Checking wezterm.exe folder for wezterm.toml #73

Closed
God-damnit-all opened this issue Dec 8, 2019 · 6 comments
Closed

[REQUEST] Checking wezterm.exe folder for wezterm.toml #73

God-damnit-all opened this issue Dec 8, 2019 · 6 comments

Comments

@God-damnit-all
Copy link

Wow, I've been looking for something like this for quite some time. I'd really like to use this on a thumbstick so I can use it instead of command prompt, only problem is, I'd have to put a config file on the computer I'm working on.

Could you make wezterm check its own directory for its toml file before it checks the $HOME locations? (After all, on the off-chance that someone else is using it as well, I'd want my own configuration to take priority.)

wez added a commit that referenced this issue Dec 8, 2019
This is to support the portable-tools use case for roaming admins.

Refs: #73
@wez
Copy link
Owner

wez commented Dec 8, 2019

Thanks for the suggestion!

I've pushed a commit that implements this behavior; a build should show up in the artifacts download section of this GH action run when it completes: https://github.com/wez/wezterm/runs/338534011, and it will show up in the nightly build when that next kicks off.

@God-damnit-all
Copy link
Author

It works great! Thanks so much!

@God-damnit-all
Copy link
Author

@wez Hm, actually a thought just occurred to me, and I hesitate to ask because it's not really a big deal and this change on its own is all I really needed.

Could it be allowed to load fonts stored in the portable config directory? Again, it's somewhat trivial since I doubt anyone would care if I installed my font of choice to their machine, but it would be convenient. The check could be reserved for when it's loaded from a portable config, and it would make sense for the "portable font" to take precedence since fonts do get updated with more frequency these days.

@wez
Copy link
Owner

wez commented Dec 8, 2019

@ImportTaste I like that idea too; would you mind opening a separate issue for it? It's a bit more involved to make that change because font loading has a different implementation on each platform and it might need to get done after some other work I'm considering for the font subsystem. That said, the loader on Windows is the easiest to change, so I may be able to squeak that without too much fuss.

wez added a commit that referenced this issue Dec 9, 2019
This is another option to help with the portable wezterm on a flash
drive use case.

When the font system is set to FontKitAndFreeType, the set of
directories specified by the `font_dirs` configuration option will
be scanned for fonts and used as a source for fonts.

In addition, any relative paths in the the `font_dirs` list will
be expanded relative to the configuration file path.

That allows deploying the following set of files to the root of
a flash drive:

* wezterm.exe
* wezterm.toml
* fonts/myfont.ttf

and with this config snippet:

```
font_system = "FontKitAndFreeType"
font_dir = ["fonts"]
```

wezterm will now consider myfont.ttf when loading fonts.

Refs: #73
@God-damnit-all
Copy link
Author

God-damnit-all commented Dec 9, 2019

@wez Just got home from work, I would've opened an issue but it looks like you already implemented it if I'm reading correctly. Appreciate it! 👍

EDIT: Ah, I need to be more considerate of other platforms. I'll make that issue.

@github-actions
Copy link
Contributor

github-actions bot commented Feb 4, 2023

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 Feb 4, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants