Feature suggestion: allow multiple ini files on i= CLI

[evanscott]

allow multiple ini files on the i= command line option. They would be applied left to right, with options in right-most ini files overriding those to the left. It is assumed that only the left-most ini file would be subject to editing by the TC options editor.

The advantage is that it would not be necessary to edit multiple customized ini files so that they all reflected changes that one wants in all TC configurations.

The disadvantage of this arrangement might be that the user would have to edit the override ini files manually. This disadvantage would be somewhat mitigated by the fact that the desired modification could be made with the editor and then cut and pasted to the override ini.

Another advantage is that the addition of the feature does not affect the long standing behavior of the i= command line option which will continue to operate unchanged in the absence of additional ini file paths.

[Hacker]

evanscott,
Is this not solved by using RedirectSection?

Roman

[evanscott]

With some serious planning and a bunch of editing yes. However, I am a fairly lazy fellow and planning is for my "real job". Inserting redirects for every section that I might be interested in overriding seems a little too much like work. Also it creates a unique ini file which is one of the things I was hoping to avoid with the multiple inis on the CL arrangement... that is, in my dreams there is a very small (possibly one) set of inis that are used as the left-most ini and a possibly large number of overide ini's that can be applied at a moment's notice to modify the behavior of TC.

In fact, as I think about it, the multiple inis on the cl makes it possible to setup some fairly interesting batch file solutions to TC configurations, e.g., context sensitive arrangements. That would be much harder to achieve with the redirect approach, i.e., require more planning, be more static and require more work.

I can see use cases for the redirect machinery but they don't fit my particular lazy, experimental approach to things.

regards,
Evan

[Balderstrom]

Here you go. Just for your lazy ass.

These are left in wincmd.ini
[Configuration], [Buttonbar], [Packer], [Colors], [AllResolutions], [DriveHints]
These are redirected ::

Code: Select all

[CompareCustomField]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_CustomFields.ini
[CustomFields]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_CustomFields.ini
[HintsCustomField]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_CustomFields.ini
[OverwriteCustomField]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_CustomFields.ini
[DirMenu]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_DirMenu.ini
[Lister]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Lister.ini
[Command line history]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History.ini
[MkDirHistory]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History.ini
[LeftHistory]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-LR.ini
[RightHistory]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-LR.ini
[RenameSearchFind]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-RenameSearch.ini
[RenameSearchReplace]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-RenameSearch.ini
[SearchIn]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-RenameSearch.ini
[SearchName]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-RenameSearch.ini
[SearchText]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-RenameSearch.ini
[Selection]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_History-Selection.ini
[Associations]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_InternalAssoc.ini
[Extensions]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_InternalAssoc.ini
[rename]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_MRT.ini
[left]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_OpenTabs.ini
[right]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_OpenTabs.ini
[lefttabs]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_OpenTabs.ini
[righttabs]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_OpenTabs.ini
[ContentPlugins]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Plugins-Content.ini
[DisabledPlugins]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Plugins-Disabled.ini
[FileSystemPlugins]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Plugins-FileSys.ini
[ListerPlugins]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Plugins-Lister.ini
[PackerPlugins]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Plugins-Packer.ini
[user]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_StartMenu.ini
[RenameTemplates]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Templates-Rename.ini
[searches]
RedirectSection=%$APPDATA%\GHISLER\wincmd\_Templates-Searches.ini

These are left in wincmd.ini ::
[attrplugin], [Alias], [Shortcuts], [ShortcutsWin], [ListerPlugins64], [FileSystemPlugins64], [PackerPlugins64], [PrintDir]

[Lefteous]

I have suggested something similar a few years ago. Saving the other ini file locations in an file extra would be my preferred solution.
http://ghisler.ch/wiki/index.php/New_approach_for_INI_file_location

[ghisler(Author)]

Sorry but this would be a nightmare to use and support. Why? There could be conflicting options in these various files, and the user looks only in one of them.

[Balderstrom]

I have suggested something similar a few years ago. Saving the other ini file locations in an file extra would be my preferred solution.
http://ghisler.ch/wiki/index.php/New_approach_for_INI_file_location

I could see having something like:

wincmd.ini -- everything that isn't within the Redirect.ini

Code: Select all

RedirectedINI=.\wincmd_Redirects.ini

wincmd_Redirects.ini

Code: Select all

RedirectRoot=%$APPDATA%\GHISLER\wincmd\  #Optional

CompareCustomField=_CustomFields.ini
CustomFields=_CustomFields.ini

A wincmd_Redirects.ini could be distributed with the TC installer, have all the sections pre-assigned, and all you would have to do is:
1) Enable RedirectINI in wincmd.ini
2) Comment out any unwanted Redirects in wincmd_Redirects.ini.
3) Optionally consolidate some sections into the same file (see examples in previous post)
4) Optionally change the RedirectRoot.

Though it still accomplishes the same thing, just easier to maintain and provides for a cleaner wincmd.ini.

[ts4242]

2Balderstrom

There is already AlternateUserIni which redirects all sections to specified file except
[Configuration]
[Layout]
[Packer]
[Confirmation]
[Extensions]
[Associations]
[Shortcuts]
[ShortcutsWin]
[PackerPlugins]
[FileSystemPlugins]
[ListerPlugins]
[ContentPlugins]
[PackerPlugins64]
[FileSystemPlugins64]
[ListerPlugins64]
[ContentPlugins64]

[evanscott]

Ok, ok... I am going to see how hard it will be to setup the context sensitive operation using the tools provided. After reading everyone's posts I am forced to conclude that even if it is a good idea it is definitely not a popular one. Also, it occurred to me that I might be able to use junctions and symbolic links to handle some of the work. If that is the case then I can have multiple configurations which use a common base set of options that can be amended on the fly without changing anything in an existing (read static) set of ini files... and you guys don't have to do a thing. Sorry to cause such a furor.

Evan

[MVV]

The only thing you can't do with redirection is to have different parameters in same sections between configuration files. However you can use some tools that will transfer settings from generic INI to your working ones. That way will allow you to apply any sequence of pre-configuration files...

[ts4242]

it occurred to me that I might be able to use junctions and symbolic links to handle some of the work. If that is the case then I can have multiple configurations which use a common base set of options that can be amended on the fly without changing anything in an existing (read static) set of ini files...

You can redirect sections you want, configure their base settings and then set the redirected file's Read Only attribute.