|
Post by Robert on Jan 18, 2023 11:59:12 GMT -5
I would recommend looking up the topic of Schemes in the SPFLite help. If that doesn't answer it, post your questions here and someone can help you.
From an edit session, enter HELP OPTIONS SCHEMES as a primary command, then within the popup window that appears, click on the line that says, Customization: OPTIONS - SCHEMES
|
|
|
Post by Robert on Jan 17, 2023 15:45:47 GMT -5
What did you find? Maybe nothing. Never tried that before. Run a macro and grab the find-string result and display it. I am guessing that the error actually caused the find to fail, and you didn't find anything.
If you need to run this macro, my advice would be to detect HIDE mode, then temporarily disable it, then turn it back on when you're done.
|
|
|
Post by Robert on Jan 17, 2023 13:50:21 GMT -5
You have downloaded a very old version of SPFLite, one which doesn't support schemes. If you did that because you are running Windows XP, it's as good as it's going to get.
If you have a modern Windows version, go to the SPFLite main web page at spflite.com
and follow the instructions to download SPFLite 2.7.22344 which is the current production release.
|
|
|
Post by Robert on Jan 17, 2023 13:03:56 GMT -5
This was exhaustively thought out when the feature was added. HIDE mode and DX/MX prevents a FIND from showing a progression of find locations. If HIDE was off, the cursor could show progressive FIND's on one line by showing a cursor move, bit by bit, until the --- x --- line was passed. With HIDE on, that's not possible, and there would be utterly no user feedback. People would be scratching their heads and going, what the heck just happened here. It would be impossible to explain or document.
Bottom line: The user interface/user experience would be too difficult. It would be asking too much of people.
George wouldn't be the only one getting a headache; everyone would.
So why is it OK when ALL is included? Because ALL causes every search string to be found or changed without requiring a progression of find locations to be incrementally shown. It just does all of them, all at once, and then it's done. That makes showing the 'difficult' HIDE progression unnecessary.
That's why.
|
|
|
Post by Robert on Jan 16, 2023 17:35:57 GMT -5
post deleted
|
|
|
Post by Robert on Jan 16, 2023 14:46:38 GMT -5
post deleted
|
|
|
Post by Robert on Jan 15, 2023 16:53:35 GMT -5
Maybe it's time to remove Suggestions. We both know I am the worst offender thereof. Pipe dreams are for the young. 80 generally doesn't describe that.
Or, if you don't want to outright remove it, maybe Suggestion items could have a 'poll' attached to them. Then, you'd only look at something that enough users voted on.
Here's a shock: I will bet real money that most users won't vote for ANYTHING, EVER. That should tell you where their priorities lie.
As for someone taking over and involving themselves in the future of SPFLite, need I remind you that I tried getting the attention of users about this (a year ago?) or so. All I got was crickets, and the 'future of SPFLite' item got yanked on account of zero replies.
I don't think there are users that know SFPLite as good as me, but there are users that know the code better. Unfortunately it's hard to do one without the other.
And, between my depression and my chronic illnesses, I won't live long enough to take this on, and I'd be pretty useless if I tried. Sorry.
I believe you are your own worst enemy here. You tried "backing off" before, and it lasted a whole month or so before you were back in the thick of things.
Maybe you could try this as a two-pronged approach. Concentrate on bug fixes, and any other changes should be limited to macro enhancements, so that users can solve their own problems. Between those two, bug fixes would have priority.
Anything else should have polls attached to them. If users won't stand up and vote for what they want, why the heck should YOU do anything about it?
The reality is, when you stop coding, that will be the "PB 10 moment" for SPFLite. From then on, it will just "coast", warts and all, and that will be it.
All good things come to an end eventually. Sigh.
|
|
|
Post by Robert on Jan 14, 2023 19:30:50 GMT -5
This logic is contained in a function called ClrLoad, which I extensively rewrote some time back. However, when I was done, the errors you cite above were not present. The most likely cause of this is that somehow strings are being found first.
There is some (relatively) new logic in this code which adds default quotes of " and ' unless you explicitly ask for your own quote types. For Basic, the QUOTED directive in the AUTO file gives the Scheme Number and then optional quote delimiters, which BAS must specify as " only. That should be enough to prevent ' from being used as a string. In addition, if there is any overlap between comments and strings, an error is reported. So you can't use ' as a comment and as a quote too, it rejects that.
The validation code in ClrLoad *already* "compels" users to define these delimiters correctly.
|
|
|
Post by Robert on Jan 9, 2023 15:34:38 GMT -5
BTW, not that it matters, but you are kind of arguing my own point for me by mentioning about HELP AUTO and QUOTED. My original post was about using auto coloring to parse user data to accurately determine quoted strings, so they could be found easier for the data shift issue. You rejected that idea, so then why go back and mention AUTO and QUOTED when they are part of the very suggestion I made that you didn't want to do? That doesn't really make sense.
But again, this is a moot point. Just saying.
|
|
|
Post by Robert on Jan 9, 2023 11:20:59 GMT -5
The code fix should be sufficient, I have no further objections.
|
|
|
Post by Robert on Jan 8, 2023 19:56:05 GMT -5
post deleted
|
|
|
Post by Robert on Jan 8, 2023 17:07:16 GMT -5
The idea is that the attributes would not dramatically change. When you colorize a line, it assigns a color attribute to each of the symbols you deem important. This is not superimposing anything. You describe the syntax of a string, and any color that is associated with is always going to use color code S, which will have some fixed scheme number. Suppose we steal schemes 13 for String and 14 for Comment. There won't be any "jamming", but there would be "stealing" so to speak. We would have to live with 12 general purpose colors, and two colors dedicated for this special purpose. As I see it, there would be *no* new attribute bits. You would use the same ones in the same way. It's just that some of those scheme numbers would have an implied special meaning. You said, "We can't just reduce the number of Schemes, and re-use the freed values for STRING" but I believe that is exactly what you would do. Perhaps you could explain why that would not be possible. The String property would be identically the same as a color; it would be an "overriding attribute" but a simple color code. The only part that makes it different is when you would doing Change and Shift commands, and then you'd look at the color codes for "guidance" to help you decide how to handle spans of spaces. You mentioned, "What about normal text files, table files etc.?" Well, what about them? Do you want SPFLite to "guess" what is "string" is in raw data - data that the user *never* described in terms of having string tokens (much less, tokens of any kind)? My feeling is that if users fail to define any syntax or structure whatsoever for their raw data, they have no reasonable expectation that SPFLite should treat their spaces of spaces in some magical way. Why would it? No other editor does that, that I know of. Even Notepad++ won't do that unless you declare a language type and associate it with a file extension. Yes. ISPF didn't do all this, but then there's lots that ISPF didn't do. --- There is another way to do this that is less elegant but simpler. For any given file type, there would some kind of process that would scan a file for spans of blanks. Whatever needs to be protected from being compressed would be turned into Non Breaking Space. You might have to adjust some of your find/change logic to make Space and Non-Breaking Space be treated as equivalent. Whenever the file is saved, the NBS chars would be converted back to real spaces. It is common in many editors to get around editing limitations by doing temporary conversions between SP and NBSP. Not a perfect solution, but it is a solution. And, it leaves open the possibility of protecting different kinds of files in different ways. (The NBSP is just an idea. Any alternative code would be OK as long as it wasn't present in user data, like X'01' or something.) --- Just so know that all of the above is not just pie-in-the-sky, take a look at the ANSI chart for > X'80'. There are 'curved' quotes like ‘ ’ ‚ “ ” „ as well as what are called "guillemet" quotes like ‹ › « » used for things like French. It is quite likely that a user typing in French might want THEIR spaces protected too. Are you really going to hard-code tests for ALL of these quoted string types? Or is this concept only intended for legacy programming source-code text? Merely checking for ASCII quotation and apostrophe isn't all there is too it. There are also exotic string constants, such as in modern releases of C++, that are truly weird. If your processing isn't based on the profile and colorization tokenizing, such users will have no way to define and protect their space data in the way you are making available to plain-ASCII users. --- Is any of this trivial? No. It might help, or it might not. Or, go with your 4-line code change. That would be my vote. Don't waste your remaining days listening to me. You've already wasted too much time doing that. ---
Whatever you do, it's important to allow users to disable this new feature if they don't want spans of spaces treated specially. Don't break backward compatibility. Anything else is up to you.
|
|
|
Post by Robert on Jan 8, 2023 16:48:38 GMT -5
It is quite likely a sane replacement for SI(I) could be implemented as a macro, should anyone care.
I would not ban S on non-excluded lines, especially if the [n] option is dropped. I often type S on normal lines by mistake, and I am grateful it does not complain all the time. I see no need for Sn but plain S should be allowed anywhere.
|
|
|
Post by Robert on Jan 8, 2023 13:40:06 GMT -5
The problem comes from the definition of a string. The simple fix undoubtedly makes assumptions about what a string is. Those assumption might work sometimes but not always. For instance, C strings with escaped quotes, or PL/1 or modern COBOL allows doubled quotes as literal quotes. That could confuse the quote-skipping logic. There's also the issue of strings within comments and vice versa. Not impossible to overcome, but the process is vulnerable to bugs.
SPFLite already has a mechanism to recognize strings. It's called auto colorization. The more robust way to address this would be to use the colorization parser to detect spans of strings. That way, each language can define its own strings consistent with their own language rules.
To make that possible, you would have to create a new class of colorization. Instead of Red or Green, there would be a new color called "String", with its own highlight color-code. For laughs, you could call it code S. Then, any time you were scanning a line and potentially compressing a blank, if its color were S, then it doesn't get compressed.
Comments could also have blanks that you might want protected, so similar remarks apply to them. Perhaps you can see why having this action depend on the language, and thus the profile, is important. I would give comments a color code of C.
To enable these new color codes, two existing colors would have to be retired. S is not currently used, but C is (CYAN), so that would be an impact on existing users. You could still use C and S as real colors, but they would be reserved internally for space-protection purposes. That way, any subsequent scanning code would only have to look at the color attribute line to see if a blank should be protected or not.
To maintain backward compatibility, these actions should be conditional. A global option checkbox for each would do the job, like this: [x] Protect blanks within strings from being compressed [x] Protect blanks within comments from being compressed
I am sure this more than you wanted.
|
|
|
Post by Robert on Jan 8, 2023 12:46:47 GMT -5
I would have done this particular thing differently, but, oh well.
|
|