While you're in the area of Profiles,...
I note that when editing a 'slave' filetype (ie. one that is USING a 'master' profile), all changes via the PROFILE command are directed at the 'master' profile.
That's fair enough, but I wonder if the command PROFILE UNLOCK should also be redirected to the 'master' profile?
It kind of defeats the purpose of deliberately LOCKing the 'master' profile to prevent accidental changes taking place.
Perhaps, in this case, PROFILE UNLOCK should display a message like "
You cannot unlock a 'master' profile from a 'slave' filetype"
I also wonder if there should also be a 'copy' option on the "Create New Profile" pop-up window displayed when SPFLite encounters an unknown filetype.
At times I just want an independent profile like another profile I already have, instead of a copy of DEFAULT or a USING relationship.
(But I do appreciate I can achieve this by allowing DEFAULT and then issuing a PROFILE COPY <profname> command)
I think the documention for the "File Profiles" section, under "Profile USING" could be clearer, when it states:
Then, in the Profile for H you issue a PROF USING C command to refer to the 'master profile' and the H Profile will inherit all the settings from the C Profile, such as the C colorization file if automatic colorization support is active. Now, only changes need to be make to the C profile, and all profiles which are USING the C profile will automatically reference the new settings in C.
When you are editing a file which is USING another 'master' profile, and the master profile is UNLOCKED, then any changes you make will be saved in the master profile, meaning they will apply in the future to all file types which use the master profile.
I believe (correct me if this is wrong!)
the first paragraph is misleading because of the word 'inherit'.
It leads the user to conclude that the 'slave' profile is a point-in-time copy of the 'master' profile.
Except for the USING field which points to the 'master' profile, all data in the 'slave' profile data is redundant and never referenced.
Once the 'slave' file is loaded, all profile enquiries and changes are satisfied by / applied to the 'master' profile.
I suggest simply replacing the word "inherit" with "reference".
I also suggest that "Now, only changes need to be make to the C profile,..." is replaced by "Now, changes need only to be make to the C profile,...".
The second paragraph can be clarified by replacing it with something like:
When you are editing a file which is USING another 'master' profile, all profile requests and changes are satisfied by / applied to the 'master' profile.
If master profile is UNLOCKED, then any changes you make will be saved in the master profile, meaning they will apply in the future to all file types which use the same master profile.
If the master profile is LOCKED, all profile changes will be temporary for the duration of the current edit session and are lost when the session is closed.
And finally....
Removing the master/slave relationship can be awkward. It isn't easy to blank out the USING field.
I wonder if it should be documented that removing the relationship should be accomplished with a PROFILE COPY <masterprof> command.
It has the additional advantage that it loads the then current 'master' attributes into a possibly somewhat decayed ex-slave profile.
