How to store configuration

[DRSDavidSoft]

We need to come up with a standardized way to store Cmder configuration here.

I'm working on a branch to customize the prompt color and handle character (currently λ) from the /config directory, and similarly, a lot of init.bat (e.g. @daxgames's recursive path enhancing) could benefit from a stored configuration file.

@cmderdev/trusted-contributors - What would you vote as a suitable container for the Cmder configuration?

• XML
• YML
• JSON
• TXT/INI
• BAT/SH
• (other)

Keep in mind that it needs to be:

• easy to edit for user
• accessible from both batch and bash environments
• uniform across all vendored platforms

[daxgames]

Why store another config file? The entire config folder is stored config files. You can use bat/cmd, sh, and ps1 files. Init.bat will soon be able to take command line args and these are stored in the users conemu.xml in the config folder.

What config is there to store that is not already storable in the config folder?

I think we need to have user lua scripts and that is an easy 5-8 line mod to %cmder_root%\vendor\clink.lua that's have already written band was going to propose after my current PRs are merged.

[DRSDavidSoft]

@daxgames No need for another config files, instead I'm asking for a unified format to store existing configuration. (Please note that i'm talking about the way configuring Cmder is or going to be designed - not how the procedure of the scripts currently work - which I'm well aware of.)

To make an example, it would make much more sense to have a unified console.lua which controls how the prompt is displayed across cmd, PowerShell and Git/Cygwin shells. Currently, each platform seems to have their own script file, which makes customizing the prompt harder by going through each, and modifying them.

I consider having one .lua script to set-up each platform in its oen way to be less frustrating for the user, however, this approach requires an installed lua binary to be used for both bash and cmd.

Also, in /vendor, by design files are overwritten in each update, which is suboptimal, and further complicates the upgrading process and not loosing the user edits. Hence this issue.
Even if those files were not overwritten, as a user I'd be much comfortable having an independent dedicated profile script(s) in /config which ensures that no matter which update of cmder is installed, my customizations are always read and applied. I believe others would also appreciate something like this.

In any event, I made this issue to ask for your and the other devs' opinion to come up with a solution to a problem I thought of, but if this doesn't seem to be an issue, well, there's no need for a solution :)
Which comes down to considering whether a user-configurable customization is desired to be implemented in the /config directory, or not.

What do you think?

[daxgames]

@DRSDavidSoft. That's my point, the capability to have user stored config that is persistent across cmder updates is already there and it is in the config folder as you propose. The only thing missing is loading user lua from config folder and I have already written that just not PRd it. Lua as far as cmder used as a part of clink and is primarily for cmd.exe customization I believe it has limited support for PowerShell but I don't think it supports bash at all.

That is why I asked what config do you want to store? Also what are you doing that is not persisted across upgrades? A unified config repo seems unlikely since all the shells are very different and proprietary.

[DRSDavidSoft]

@daxgames That's good (and looking forward to your PR) – though by not unified, I mean that each shell is currently loading its custom script. e.g. for changing the prompt color from green to cyan, I have to modify these 3 files:

• git-prompt.sh
• clink.lua
• profile.ps1

It would be better to have a single console.lua file in /config, which then would be parsed by each of those files using Lua executable. Additional platform-specific scripts then would be separated to .sh, .bat, .ps1 and .lua scripts in the /config directory.

So, a newbie user could easily edit that console.lua file to achieve customizing the prompt, essentially instructing the /vendor-based scripts on how to set the prompt. If further modification is required, (besides other unified files such as git.lua, path-enhancing.lua, etc...) then he/she can write a custom script to run on start-up.

I see many parallels between platforms that Cmder supports, besides customizing prompt. That's what I meant, for example, to set the path depth limit from /config. Also, that's why I suggested container formats like XML, YML, and JSON. Because they're specifically made to hold data, rather than execute code. (I'm fine with .lua, though, as it's already easy to edit.)

There are methods for bash to parse .yml, or better we can include a lua.exe binary (<50KB) in the /vendor directory to parse console.lua and adjust color and the λ handle accordingly.

I imagine on the first initial start-up, a copy of console.lua should be generated into /config, and user is instructed to edit that file for any customization. Then clink.lua would include it, and substitute portions of prompt with the defined values. For bash, it would do the same, except bash is responsible to load the console.lua script and substitute the portions the bash way (it still sets the λ as handle, but it's read from console.lua rather than hardcoded directly in git-prompt.sh or cmder_exinit.)

So, with that said,
1- does it make sense?
2- do you agree/disagree?

[daxgames]

@DRSDavidSoft. Don't get me wrong, I like the idea in principle. I just question the effort vs the reward, how much will it get used. I sometimes wonder how much current configuration features available to cmder users are actually used beyond the most advanced users, Ex: contributors to the project. Many users don't use all three shells, I bet many use only the default cmd.exe based shell.

I don't think Lua is the right thing to use. Lua is a programming language and while that may be great you and me a normal user not so much.

As far as modifying 3 files to change prompt color every time you uodate, the flaw is in editing files in the vendor folder. You should be able to copy the sh and write a ps1 into %cmder_root\config\profile.d config them the way you want and those settings will survive cmder updates. That may be an overkill way of doing it for PowerShell because profile.ps1 has some ability for user prompt customization built in, I think, but that's a very quick idea of how to do it without looking at the code. The clink.lua edit would require the future PR I have mentioned to enable user lua load to allow lua changes to persist.

The thing is the majority of cmder users do not need or want to do this kind of config. I almost think documentation of how to do these advanced configs has a better ROI.

I know how it is though, If you have to do this though just make sure everything you do is backwards compatible for those that may not need the functionality.

Just my $.02

[DRSDavidSoft]

Thanks for your considerations, I believe you are right. For now I'll hold this until you finish your PR - to make sure it's implemented right. (Please mention this issue on your PR when you make it.) Any edits I make, I'll also make sure it's fully backwards compatible.

I might make this as a separate package, like a plug-in to Cmder. (As long as it's calling executables from /config, it should be fine.)

I believe if this makes modification to prompt easier for power users (and contributers), it deserves to be done. Though I think if users will be able to easily use this, it would even be used more, since some issues and forks regarding changing the prompt has already been made.

Thanks!

[Stanzilla]

I'm with @daxgames here, after the Lua loader is done, we are pretty good when it comes to storing user data.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contribution.

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. It will be closed in a week if no further activity occurs. Thank you for your contribution(s).