|
|
Post by Stefan on Feb 22, 2023 6:51:16 GMT -5
George,
There's a minor hiccup in 'DataInsert' primitive processing. The 'DataDelete' primitive is also affected.
Take a line like...
This section is code "and this bit is quoted text whose spacing should remain the same"
You can insert extra characters between the words 'This is code' without affecting anything within the quoted string However, if you insert characters WITHIN the quoted string, the user may expect that runs of multiple spaces to the right of the insertion point are preserved, but they are not. In the above example, enter a char between 'this' and 'bit' and the 5 spaces between 'text' and 'whose' are compressed.
I appreciate that the solution is potentially convoluted as it implies awareness of the cursor position within a quoted string so the return on investment may be limited.
While on the subject, and this is firmly in Suggestion territory, so I'm being cheeky raising it here....
Quite often, the 'Insert' or 'Delete' concept is applied to blank sections of a line in an attempt to align text in 'columns'.
To allow the 'DataInsert' and 'DataDelete' primitives to work, the user must position the cursor precisely at the beginning of the text to be realigned. Place the cursor on a blank section between two 'columns' and these primitives do nothing because there are blanks immediately to the right of the cursor.
In the above example, using 'DataDelete' within the spaces between 'text' and 'whose' results in no action.
I suggest a modification that treats blanks between the cursor position and the next non-blank character as 'normal' chars.
Given the above example (cursor between 'text' and 'whose'), pressing 'DataDelete' would reduce the spaces between the cursor and the next non-blank, effectively moving word 'whose' left but leaving the word 'spacing' where it is.
The same concept would apply to 'DataInsert' and would eliminate the need to move the cursor to within ONE space before the text to be shifted right. I reckon (DataBackspace) would also benefit from this mod.
|
|
|
|
Post by George on Feb 22, 2023 9:40:21 GMT -5
Stefan: The first item is, I'm afraid, just not going to happen. Making the cursor position sensitive to whether its inside a quoted string is simply 'a bridge too far'. It opens up just too many possibilities;
what if there's unpaired quotes, or mismatched quotes.
what if nested quotes - e.g. "Hello 'sailor', want a drink"
"Hello 'sailor', want a drink" (With the cursor between Hello and 'sailor' )
The second problem may be simpler (I hope), I've been hindered by this as well.
George
|
|
|
|
Post by George on Feb 22, 2023 9:53:37 GMT -5
OK, DataDelete and DataBackspace are done, I think what's happening is logical and correct.
I'll update the Beta.
Had a close look at the first problem. Yes, a can of worms.
George
|
|
|
|
Post by Stefan on Feb 22, 2023 10:05:57 GMT -5
George,
I expected you would veto the first aspect - as I said, it isn't that important and probably a whole lot of bother getting a machine to understand what a human takes in at a glance. Happy to leave it asis.
Look forward to the next beta.
|
|
|
|
Post by George on Feb 22, 2023 11:24:26 GMT -5
There's no problem checking attributes in a primitive, they have to do that normally to handle changes. It's the tracking of the quoted status of the cursor position and the potential of nested quote styles. And as was noted, correcting it is not a high payback item.
George
|
|
|
|
Post by George on Feb 22, 2023 12:43:36 GMT -5
If we were to hang this correction on a colorization requirement, there's no need to reserve a 'color' for quoted strings, we have that already, that's how the new C G T support works.
But basically I don't think these primitives should require colorization. This item should just be dropped.
George
|
|
|
|
Post by Stefan on Feb 23, 2023 6:41:16 GMT -5
George,
Thanks for the change to (DataDelete) and (DataBackspace).
Even after just a couple of days with beta v23053, I find these commands are much more intuitive.
Quick question...
The "treats blanks between the cursor position and the next non-blank character as 'normal' chars" suggestion is also applicable to (DataInsert).
It would eliminate the need to move the cursor to within ONE space before the text to be shifted right.
Was there a reason why you didn't include (DataInsert) in the recent change?
|
|
|
|
Post by George on Feb 23, 2023 10:03:16 GMT -5
Stefan: (DataInsert) would simply not be 'data insert' if it did that. It's supposed to avoid shifting the data if compressable blanks are available, otherwise it becomes simply (Insert) mode.
George
|
|
|
|
Post by George on Feb 23, 2023 12:25:05 GMT -5
Another solution that depends on colorization?
Sounds simple, but it's not. There's lots of other commands, primitives etc. to review and update to cope with the possibility of X'A0' being present.
e.g Primitives - WordLeft, WordRight, SentenceCase, Justify, Titlecase etc. and the PTYPE variations of the same. God knows what Primary commands may need tweaking.
A search for this kind of scattered revision and correction never goes well. Fallout from overlooked code trickles in over a long period.
Yes, NBSP would solve this particular problem, but it comes with quite a price. I think it's too high for the payback.
And frankly, the thought of scanning all the code to locate these areas would turn anyone off.
George
|
|
|
|
Post by George on Feb 23, 2023 14:25:36 GMT -5
If the colorization routine is currently the logic that detects the presence of quoted values, where else would a solution appear? It's either there or create some new parser logic specifically to find strings and deal with them. Would you like THAT solution better than this one?
I was pointing out that if a profile doesn't have AUTO ON, the 'fix' would not work for that file's data. Functions that truly have no need to concern themselves with quoted or unquoted strings, should not have to be 'tweaked'.
Can you give me a single example of a command that would fail if X'A0' were in a quoted string? In fact, can you explain how word left/right, sentence case, etc. or any of the others you cite would fail if X'A0' data were in a quoted string? Why would you 'justify' a string? Why would you title-case a string? And if you did, how could X'A0' matter? You don't title-case X'20'. How is this any different?
Why would you 'justify'? Why would you 'TitleCase? Because in the past YOU were the one requesting these functions be added. If you now think they're useless, we'll yank them out.
I did this already, but to repeat again - TF line command, Sentencecase, Titlecase, WordLeft, WordRight, Justify, TextSplit
What primary command needs tweaking? By modifying UUCASE, that aspect has already been handled. Yes, a search of many thousands of lines would be a burden, but why search at all? What are you searching for?
Scattered throughout the code are hundreds of places where commands are manipulating line fragmants (CHANGE, SPLIT, JOIN, GLUE etc) and there are a lot of TRIM$, LTRIM$, RTRIM$. You are assuming that none of those would be impacted by the TRIM not working because of NBSP characters. Slim chance of that being true.
Let us suppose blanks were to get converted to "¿" instead of X'A0'. In what way would any of the things you mention - WordLeft, WordRight, SentenceCase, Justify, Titlecase, PTYPE, primary commands - be affected because X'20' were temporarily translated into "¿" if you could explain that.
Explain?? Really? C'mon Robert. e.g. How can WordRight skip ahead through the words in a quoted string without being modified to handle X'A0 (or "¿", or whatever) Similarly those other examples. They all require spae delimited 'words'.
I believe the alarms you are raising about all this is unnecessary and just a red herring. If you tell me you don't give a **** about the issue, I would believe that. If so, you don't need to make up excuses for why you don't want to do it; just say you don't want to do it. Or, if the issue is not important, or important enough (my feeling on it) then say that.
But claiming it's some huge, monumental, staggeringly difficult ordeal beyond the realm of mortal man? It just isn't so. IMHO, you have greatly and needlessly exaggerated a relatively simple change.
If that is the case, you could dismiss all this in far few words, like "I don't want to."
Robert: I just can't believe you sometimes. "huge, monumental, staggeringly difficult ordeal beyond the realm of mortal man". Talk about exaggeration and putting words in someone's mouth.
Nobody knows the code and internals of SPFLite like I do. Your contributions over the years have always been highly spec'd out, isolated functions, easily written and tested with some small driver code. Then passed to me to integrate. You've never been involved in one of these 'scattergun' changes.
Yet you toss off my estimates of change difficulty and trivialize them. Like here, assuming some simple change to UUCASE will solve the whole problem. How incredibly naive.
My closing comment was "Yes, NBSP would solve this particular problem, but it comes with quite a price. I think it's too high for the payback."
I'm didn't say "I don't want to", I just want the requestors of this to understand what's involved.
I'm disappointed that you can't see the implications of this beyond assuming a simple UUCASE change will solve it.
George
|
|
|
|
Post by Robert on Feb 23, 2023 15:41:00 GMT -5
There is more I could say, but it would not be productive.
Please accept my apologies for remarks not received as hoped.
These have been removed.
I consider the matter closed.
/*
|
|
