Profile AUTOCAPS ON/OFF is ineffective

Stefan: I think this is confusion about AUTOCAPS itself. It was a bad choice to use AUTOCAPS as both a Profile option, and as a keyword within the AUTO file itself.

AUTOCAPS within the AUTO file indicates whether the colorization logic is to Uppercase the keyword as well as colour it.

AUTOCAPS in the Profile indicates whether the effect of Uppercasing done during Edit is to be saved with the file when written.

i.e. with AUTOCAPS OFF and HILITE AUTO ON

Enter "Comment1" and the AUTOCAPS entry displays it as "COMMENT1"

SAVE the file and the contents will be "Comment1".

The Profile AUTOCAPS should be renamed to AUTOSAVE or CAPSSAVE or .... ?

George

Sorry George,

Yes George, but revising all AUTO files is easy. Just do an MEDIT on *.AUTO and CHANGE ALL.

Changing all Profiles has to be done one at a time, unless you know something I don't. You say it can be automated, but how? Again, you must know something I don't. What's the means of automation to access and edit all Profiles? This is news to me.


Of course, changing either one creates (yet) another "version barrier" so that once things are changed, you can't use prior versions. On general principles, it is a bad thing to do, no matter which part you alter.

Truly, it would be better if you didn't change anything. Don't create cross-version incompatibilities. I mean, what exactly is being harmed by using AUTOCAPS for two purposes, other than a documentation issue?

Instead, I say:

1. Make the documentation better. Try this first.

2. If not (1), or if (1) isn't enough, then create an alias of AUTOCAPS in the AUTO-file syntax (call it whatever you like - such as WORDCAPS - but make it good), and then retain the AUTO-file AUTOCAPS as a deprecated name. That way, users who are wringing their hands over AUTOCAPS can use the new name ("WORDCAPS" if that's what it becomes) and the rest of us who don't care are not impacted.

R

OK, if it's a misunderstanding, then (1) - upgrade the Help - is called for.

BTW, when you mentioned, "Accessing and altering all profiles is trivial, they're all in the CFG file and a quick loop to copy the AUTOCAPS entry to the new CAPSSAVE (or whatever) entry is trivial", you mean it's trivial for YOU. For the user, not so much.

Also, the idea of avoiding a "version barrier" (where you can't use older versions because of incompatible changes) applies to Beta versions too. If a Beta changes things like the CFG behind the scenes, that creates a version barrier. So, if a user tried out a Beta and didn't properly back up what they need to, they could be "stranded" with the "new" way of doing things, even if they didn't want to.

Here is my "wish list" to you, George:

Suppose you make some change (beta or prod), that would alter the SPFLite environment in some way that was basically irreversible, I *wish* you would cause a popup to appear when you get to the part in your code where the 'migration' to the new way of doing things happens. That popup would say something like,

"Notice: A migration of SPFLite is about to occur which will render your run-time environment incompatible with prior versions. If you have not already done so, perform a backup of the <whatever resource that's going to be revised> before proceeding. [Continue] [Cancel]".

What do you think? Is this reasonable? It is to me. We don't want to turn any installation (beta or prod) into an "entrapment" where careless (or sleepy) users end up getting stuck when they didn't really want that outcome.

R

For what its worth...

I think you should not change any keywords anywhere.

But enhance the documentation for AUTOCAPS and HILITE commands, and the chapter on Autocolorisation to clearly separate the concepts an emphasise that HITLITE and AUTO colorisation/capitalisation processing ONLY affect the appearance of the data, and AUTOCAPS ON/OFF affects ONLY how the apparent capitalisation is SAVED.