Feature Request:ItemizeSquared - or is that too lazy?

[Bruce]

@MarkGoldberg

What is made difficult by use of ITEMIZE,PRE(I ) ?
The only thing I can think of is you were searching for the values associated with one of the equates.

Your lack of imagination is, alas, no help to my problems

I first encountered an issue back in the day with a Duplicate Identifier warning. The compiler complained, and KSS (or whatever) could not find the root declaration. I ended up resorting to tricks (like injecting a 3rd declaration really early.)

As others have mentioned it’s often useful to see the declaration in-place, for various reasons. I use search to navigate my code a lot, so “breaking search” breaks my typical work-flow. And using prefix breaks search…

@MarkGoldberg

You search again for PlusOne - easy peasy - same process when search for anything in clarion that might have a prefix (Files, Groups, Queues )

As long as the label is unique (plus one) this approach is fine. It’s much less fine when the label is not unique. consider an Itemize that contained the labeled CODE and DATA and you’ll get the idea.

Your debugging approach of writing a whole class just to enumerate the equates seems like a lot of work, and as you know I’m allergic to hard work. Not writing the PRE seems like a lot less work to me

Frankly I don’t really use ITEMIZE at all (with or without PRE) - I prefer EQUATE, but that’s just a style thing.

[BoxSoft]

I agree that PRE on ITEMIZE isn’t good. The code should have included that I: on each line.

[MarkGoldberg]

@Bruce

As long as the label is unique (plus one) this approach is fine. It’s much less fine when the label is not unique. consider an Itemize that contained the labeled CODE and DATA and you’ll get the idea.

So for grins, I created

Test  ITEMIZE,PRE(Search)
Code   EQUATE
Data   EQUATE 
      END

And then used KSS to search for CODE, within my code base.
Simple search gave me over 20K hits, then I clicked the “Delete Matches found in code” and it was down to 1K or so - still too many.
Rather than do a find and delete with a RegEx, I chose to start the search over checking “Match Pattern at Start of Line” which resulted in 10 hits - one of which was CodePage from StringTheory.

I was surprised to see that I source where 6 hits where CODE keyword was in fact starting in column 1. I was not aware that this was legal - even though I had written it.

I did a similar search with Data at the start of the line and found roughly 450 hits. So I did a Find and Delete, searching for Equate, delete when rows do not match - now down to 25. Most are DataType: from equates.clw, press ALT-Delete on one of those rows - and all hits from equates.clw are removed, leaving 3 hits - one of which is Data_Blob from WinCrypt.

Point being… even with common words like CODE or DATA you can fairly quickly find what you were looking for using a tool like KSS

[jslarve]

I search for “(yourPre)”.

[FedericoNavarro]

Clarion IDE has the option of Wildcard searches, in this example it would be CODE*EQUATE
or CODE *EQUATE more restrictively with a space, or if using RegEx there would be an equivalent to that

[BoxSoft]

Yes, you can narrow search results down fairly quickly with KSS, but how much time is spent compared to a search that finds the desired match on the first pass?

Also, more than once I’ve scratched my head wondering why I’m not finding something. Could it be that I’m searching in the wrong place, etc? I’ve often wasted time, not immediately realizing that I have to do some weeding of the results.

That’s why I always include any prefix directly on the itemized equates, rather than using PRE. I’m sorry my quick example stirred up the bees nest.