|
Post by Stefan on Jan 13, 2023 4:33:07 GMT -5
I think the word "SCHEME" was coined for "colorisation version 1".
When colorisation was enhanced, the SCHEME numbers became really just COLOR numbers/codes. It is up to the user to make these into a SCHEME per se, by ensuring their AUTO files stick to their chosen concept.
Originally, AUTO files explain the Scheme in comment lines. Even now, mine still state which colour is used for which purpose to create a scheme.
Not sure that a description on the OPTIONS page adds anything
|
|
|
Post by George on Jan 13, 2023 13:33:58 GMT -5
I could see some simple 'keyword' being useful, and if it could be used as an alternative to the simple scheme # in the AUTO file it would be useful.
George
|
|
|
Post by Stefan on Jan 13, 2023 14:07:26 GMT -5
Fine if the 'keyword' is user-selectable. Less so, if the 'keyword' is prescribed by SPFLite or if there's a list of 'valid keywords' from which the users has to select.
|
|
|
Post by George on Jan 13, 2023 14:22:30 GMT -5
I was meaning a User selected keyword. i.e. Overtype the Opt => Scheme sample text with your own keyword.
George
The original # method would still be available.
|
|
|
Post by George on Jan 15, 2023 14:21:22 GMT -5
Stefan: Had a look, this really has to wait until some serious cleanup of all the color handling stuff is done. Between the colors handled by SCREEN, HILITE and SCHEME it's a real zoo. Too much expedient bolt-ing on of new features. Quick and dirty come back to haunt.
George
|
|
|
Post by George on Jan 15, 2023 15:36:17 GMT -5
Robert: The Hilites and Colorization assignments are already separate. I believe right now the Hilite is given precedence in the display routine.
But there are no 'names' for colorize schemes, only for Hilites. And if we allow users to assign their own names to colorize schemes, then how in heck are color search operands ever supposed to work. If we keep Hilite and Colorize assignments separate, so removing Hilites restores the colorize values, and colorize 'names' are user assigned, how on earth do we design some search syntax that is even possible?
What if a user assigns 'Red' to a Scheme name. What does FIND XXX RED mean? RED as a hilite, or RED as a Scheme name? Do we have to filter assigned Scheme names against Hilite names to prevent duplicates? Does the search routine have to do multiple color tests to see if the color name is a Hilite or a Scheme? Or test both? How is command Parse supposed to distinguish?
This is an ungodly problem, how to analyze and find a path out of this mess is simply beyond me.
George
|
|
|
Post by Stefan on Jan 15, 2023 17:09:50 GMT -5
FWIW
It took me a while to understand the differences between Scheme and Hilite colours. But now I do, I find it quite simple and useful. Scheme is applied by AUTO-colorisation and is thus dynamic as you type. Used for display-only, the colours are not recorded/saved in/with the file.
Hilite colours are like a highlite pen on paper, i.e. reverse video, but users can change the background & foreground colours at will. Applied via commands like FIND or CHANGE, the colours are recorded in the file but only saved if STATE ON is in effect.
I see no compelling reason why the two concepts should be combined. (If I were to request an enhancement, it would be for user-customisable Hilite colour names so we're not stuck with fixed names which no longer reflect the colour the user has chosen, but it's not important enough to change the command parser.)
With some imagination, the separation of the Scheme and Hilite options effectively extends/enhances AUTO-colorisation. The former is applied by the AUTO file. The latter can be used in an IMACRO to further "fine tune" the effect. Especially useful when using SPFLite to viewing specialised text files.
|
|
|
Post by George on Jan 16, 2023 9:58:21 GMT -5
I also feel that Hilites and Schemes should remain separate, I've not heard anything to tell me how combining 'buys' anything.
I think Schemes should have user modifyable names, the default would be AUTO1 ATO2 etc.
Just like HiLite names, these names would be allowed as color operands, without the + option. i.e. only AUTO1 or -AUTO1 style. With the same meanings. This provides a consistent command format which doesn't add any new syntax style.
But first, color management code needs serious revision to add some additional capability internally. Big problem is maintaining upward compatibility. I have thoughts on how to do this, but it's certainly non-trivial. A lot of work with no immediate visible payback.
Then we could tackle the enhanced search criteria.
George
|
|
|
Post by George on Jan 16, 2023 10:58:33 GMT -5
Robert: FIND XXX COMMENT works fine my way, the user just has to assign COMMENT as an ALIAS for SCHEME#x. Works the same for FIND XXX -QUOTED, if QUOTED was assigned as an ALIAS.
The AUTO1, AUTO2 etc. were just initial defaults for these ALIAS names on the initial version run. Prefer TOM, DICK, HARRY etc. as defaults? Or something else, makes no difference.
It all works fine without 'merging' HILITEs and SCHEMEs.
As for my 'change', I'm still here. I'm still doing stuff. I'm not moving to a rocker. I'm just not going to be spending the ridiculous hours I do currently any more. The conveyor belt is slowing down, not stopping.
George
|
|
|
Post by George on Jan 21, 2023 11:52:23 GMT -5
Stefan: Although a re-do of all the colorization is still in limbo, it wasn't much to add the Alias names for the SCHEMEs. They can be used as simple comments on the Options => SCHEMEs dialog, or they can optionally be used in the AUTO file to replace hard coded SCHEME numbers if desired. Only simple one word names are allowed. George
|
|
|
Post by Stefan on Jan 24, 2023 6:19:52 GMT -5
George,
It's "horse for courses", I reckon each user will have their approach. As long as there is no requirement/compulsion to use the 'Alias' string in the AUTO files instead of the scheme number, I think that's fine.
FWIW... I think that assigning names to colours is perhaps restrictive in some case, given the myriad of file types supported by SPFLite aside from 'language' syntax. For instance, I use SPFLite to 'view' some report files from other applications which are much easier to 'absorb' when presented in colour. Hence I prefer to articulate the colour scheme via comments in each AUTO file.
As I said, Horses for Courses.
I'm a little confused by your discussion with Robert about FIND xxx COMMENT Wouldn't that syntax would apply to HILITES rather than SCHEME colours?
With reference to such command use and with one eye on the SCOPE suggestion we discussed, I worry that colour is inappropriate as a selection/Scope criteria.
- The label 'Comment' is an alias for a single colour. - It could be assigned to any type (DELIMNS QUOTED, AUTOxxxx, WORD) of entry in an AUTO file, even to different types in different AUTO files. - I also use comments of different colours (e.g. RED for a procedural header description, GREY for inline comment).
So as far as my SCOPE suggestion goes, selection by colour is not reliable in practice and would only work within severe limitations, which renders the SCOPE concept kind of irrelevant.
|
|
|
Post by George on Jan 24, 2023 9:08:41 GMT -5
Stefan: One reason I went into AttrScan and tried to make quotes and comments more reliable.
Then, somewhere, I proposed a simple set of new Kwds Q/NQ and C/NC for the scope aspect. The expectation is that only one SCHEME would be used for each, but it could be extended to handle multiple comment Schemes. There were no comments received on that.
George
|
|
|
Post by Stefan on Jan 24, 2023 10:24:21 GMT -5
George, Sorry I must have missed that somehow and now I can't find it. I 'm perfectly happy with keywords of the sort you propose, as long as they 'expand' to the right search criteria.
In my mind, the search criteria would be obtained from the related AUTO file QUOTED and COMMENTn statements. They would EITHER - Scan each line for the the 'begin/end' trigger-strings specified in the AUTO file OR - Capture the colour scheme(s) associated with the QUOTED and COMMENTn statement(s) and look for any of those when deciding SCOPE. Obviously the second option implies that the colours the user selected for the COMMENTn and QUOTED lines cannot be used for any other purpose
|
|
|
Post by George on Jan 24, 2023 11:26:24 GMT -5
Stefan: My thought was that:
a) Q/NQ and C/NC only allowed if colorization is active.
b) They would use the Schemes selected for QUOTED and COMMENTx to make the determination, so basically no extra scanning overhead, simply a variation of the existing selection by HILITE color.
So it is important that the colorization scan be as clean as it can be made before going this way.
George
|
|