Increase portability [meta-issue]

[robrecord]

Hi, would it be possible to separate the config that makes this work from the other config so that we can more easily incorporate into our own installations? Such as making the base config files includeable from our own larger config. Many thanks for your hard work on this.

[luccahuguet]

nice one, thank you for the idea

how is yazelix working for you?

thanks for your hard work on this

You're welcome!

we'll create a portability strategy here and improve on that..

[luccahuguet]

I should note that both yazi's and zellij's configs wont touch your default configs

because they stay in a non-standard place for the configs

so that's a plus for safety and out-of-the-boxness

but it won't integrate into your personal config like you mention

[luccahuguet]

we should

• understand what we want to do here in a general level: do yazi or zellij support importing configs?
• how to get there
• implement it

[robrecord]

Hi @luccahuguet, thank you.

I'll take a look at some possible strategies...

Zellij uses KDL, and I searched the KDL spec and couldn't see a way to include another file.

The only way it seems is to bypass the file with another:

zellij --config [FILE]

Yazi uses TOML and this appears to have the same constraints.

So, we'd need to generate a patched config for each.

How I'd suggest it could work:

1. For each program, provide a base config file that is the minimal changed config for the Yazelix functionality to work. Sort of like an override that could be applied to an out of the box configuration - including only the lines that would be changed from the default. Even this on its own would be beneficial to those starting out.

2. Provide a way to produce a full config file that is the result of a base config (default or user-provided) with the extra yazelix config patched on top of it. Presumably we'd need a way to parse the TOML and KDL files to manage any duplicate entries / overrides.

3. Then rename/move the initial config into a safe, backed-up state, replacing with our new, augmented config.

4. This could be achieved by a command line tool that runs through the process, and could be called on to reverse or undo in the event that the user requires this.

This is just one possible way to manage it. I'd be interested to create a CLI script, though my time is limited.

Would it be possible to achieve point number 1 in the first instance? Then I can properly give Yazelix a try.

[luccahuguet]

Interesting, sounds like a good plan

yazelix is opinionated by nature, but if portability is increased, that would be a plus.

if we follow this approach, it would be probably be a nushell script.
One that generates the default config file for each program (zellij, nushell etc) then appends / overrides the yazelix stuff

I think we should split this issue into multiple ones, one for each program, because we might have to deal with this in a case-by-case scenario

yazi for instance has this: https://yazi-rs.github.io/docs/flavors/overview

so we'll turn this into a meta issue and split it up.

[luccahuguet]

• Increase portability of yazi's config #29
• Increase portability of zellij's config #28
• Increase portability of nushell's config #27

[robrecord]

Thanks for your thinking through this.

It's great that yazelix is opinionated, so should it be! :)

I feel I should reiterate the point that there is currently an intrinsic burden on any users that have a pre-existing configs for these apps of any decent complexity. Therefore the user has to pick through the (sometimes long) config supplied here, figure out what's being configured (the hard part) then apply to to their existing config by hand.

I'm looking forward to being able to test yazelix when I have the head space to try this process with my own config. If I manage to do this ahead of any pared-down configs becoming available, I'll post the resulting short configs into each meta issue.

[luccahuguet]

thank you Rob!

[luccahuguet]

I agree with you, what we want is something like what we have here in my nushell config files

https://github.com/luccahuguet/nu-files

at the end of the default config.nu and env.nu, I just append an import to my actual configs (called my_env.nu and my_config.nu)

too bad the nushell config is not really needed for yazelix haha

but it's a nice example of what we are looking for