|
|
Post by Robert on Mar 26, 2023 12:08:59 GMT -5
Now that the Purge command is going to be removed from FM and we'll only have Delete, I want to call "dibs" on a new U line command.
Currently, the L line command counts up the lines in a file and adds or updates that information to the State. That's great, and I use it a lot.
Only thing is, most of my files already have line counts from prior editing, or from prior execution of an L line command.
So, if I have a folder where most of the files contain line counts but not all of them, I can either selectively apply L to each one that needs it (which may take a while to find them all), or do an L/ on top and re-count everything. But, if most of the line counts are (or, probably are) correct, that could be a LOT of re-counting in cases where most of the time it's not needed. That could add up to a lot of time-consuming counting overhead for (often) not that much in return.
The idea of the U line command for FM is that you would be requesting a "manual re-count" only in cases where you really need it. The pseudo-code for this is real simple:
FUNCTION FM_U_line_command (line_num AS LONG) AS LONG IS
IF ISFALSE (fm_line_count_present (line_num)) THEN
FUNCTION = FM_L_line_command (line_num)
ELSE
'/ DO NOTHING
END IF
END FUNCTION
This way, I can issue a U/ line command and it will Update all of the file line counts that are blank, but ignore files where a count already exists.
|
|
|
|
Post by George on Mar 26, 2023 12:53:25 GMT -5
Robert: Why not just redefine the L command to skip updating if there is a count already. I hardly think anyone would issue an L command for a file that has counts.
George
|
|
|
|
Post by mueh on Mar 27, 2023 1:29:00 GMT -5
George Robert : What do you think about L/ U cmd ? (L2 U) (LL U)
U for Uncond as LCmdOps(2) to always update lines count . ( in case modified out of SPFlite and you want to validate line count ) .
P.S. I miss PURGE cmd since i use it for deletion of "temporary files" i don't want to show up in Recyle Bin .
I see no reason to remove a nice Function for using of Statistics Update .
Thanks
|
|
|
|
Post by George on Mar 27, 2023 8:27:29 GMT -5
MUEH: How about DU and LU for the unconditional versions?
George
Thought - maybe your suggestion of a U as a 2nd operand is simpler.
G.
Third thought - It was so trivial, we now have the D and L Line commands with an optional
[U] operand
for Unconditional.
George
|
|
|
|
Post by Robert on Mar 27, 2023 12:03:46 GMT -5
Quite of bit of activity here. That's interesting. A few remarks:
1. Why not just make L conditional? If that were done, and if for some reason the count were inaccurate, there is no way to force a recount, other than opening the file for edit and saving it. While that would work, it would also 'touch' the file, changing its time stamp. That would not always be desirable.
2. I understand the concept of an unconditional L command, but it seems like it is taking the idea and applying it backwards. It means that you have to (a) change the current "unconditional" L command, so that its definition becomes"conditional", and then (b) add a new command LU to "get back" the original "unconditional" behavior.
That seems like an awful lot of (confusing) contortions to go through.
I would like to suggest an alternative that would open up a new feature for future commands.
Suppose that any FM line command that had some kind 'optional' feature to it (one that was 'extra' in some way, like doing extra work or taking extra time, etc.) were 'marked' with a # sign. The # could be thought of as "force". As in, "force the command to do more work, act on more files, be in effort for more situations", etc.
That would make the new commands discussed above look like this:
L Line count is calculated for files where the count is missing
L# Line count calculation is forced for all files, even if count already exists
D Files are 'deleted' by moving them to recycle bin
D# Files are forcibly deleted permanently
By modifying the FM line command parser a little, this opens up # for general use for other existing and new commands.
|
|
|
|
Post by George on Mar 27, 2023 12:56:13 GMT -5
1. Why not just make L conditional? If that were done, and if for some reason the count were inaccurate, there is no way to force a recount, other than opening the file for edit and saving it. While that would work, it would also 'touch' the file, changing its time stamp. That would not always be desirable.
?? L by itself IS now conditional. L U makes it unconditional. And LINES does not alter the the last write time, just the last acces, which we all know is not reliable anyway.
2. I understand the concept of an unconditional L command, but it seems like it is taking the idea and applying it backwards. It means that you have to (a) change the current "unconditional" L command, so that its definition becomes"conditional", and then (b) add a new command LU to "get back" the original "unconditional" behavior.
That seems like an awful lot of (confusing) contortions to go through.
You have it backward - L is conditional; L U is Unconditional.
I would like to suggest an alternative that would open up a new feature for future commands.
Suppose that any FM line command that had some kind 'optional' feature to it (one that was 'extra' in some way, like doing extra work or taking extra time, etc.) were 'marked' with a # sign. The # could be thought of as "force". As in, "force the command to do more work, act on more files, be in effort for more situations", etc.
That would make the new commands discussed above look like this:
L Line count is calculated for files where the count is missing
L# Line count calculation is forced for all files, even if count already exists
D Files are 'deleted' by moving them to recycle bin
D# Files are forcibly deleted permanently
By modifying the FM line command parser a little, this opens up # for general use for other existing and new commands.
Modify the parser? Why? Commands can already be doubled (DD/DD); can have a count (D4) or have a / or \ added. Now you want to throw in a #. Opening up all the questions like "is it D4# or D#4; D#/ or D/# etc. Let alone the 2 character commands and how they're doubled.
Without modifying anything in the parser, adding an optional U for unconditional was trivial. And it can be added to any other line command just as easily. We don't need to open up the parser (no matter how 'little' you think the change is). U as as optional parameter works fine and is easy to remember. U = Unconditional.
George
|
|
|
|
Post by Robert on Mar 27, 2023 12:57:34 GMT -5
If you're not keen on the # notation, maybe you could use "F" to mean "force", giving DF and LF.
The DU and LU names seem like they'd be hard to remember. Remind me again, what do DU and LU mean?
|
|
|
|
Post by George on Mar 27, 2023 12:59:15 GMT -5
They are D U and L U - not DU and LU. Thats so yopu can say D/ U and LL U - LL etc.
George
|
|
|
|
Post by Robert on Mar 27, 2023 13:00:39 GMT -5
You answered right about the time I posted. I guess my thoughts are usually focused on the future, and yours are on the present. That's just the way it is.
I can't agree with U being 'easy to remember'. It's just not.
But, this debate is already past its "sell by date". If you insist on DU and LU, I will just make macros to hide these disagreeable names.
|
|
|
|
Post by Robert on Mar 27, 2023 13:02:26 GMT -5
Oh, wow, not only are you using DU and LU, but I have to put a space between them too?
I better hone up on my macro writing skills. I'll never use these commands as you named them.
|
|
|
|
Post by George on Mar 27, 2023 13:17:52 GMT -5
Robert: I'm not insisting on DU and LU, there are NO NEW commands, just new optional operands, why is that not clear?
Making new FM Line commands is WAY more involved that simply adding an operand. Creating DU and LU would just create problems. We'd have 2 character commands, I guess they would then double to DUU / DUU, and LUU / LUU. And then it precludes DELETE and DEL and LINES, or do we have to create DELETEU, DELU and LINESU as well? It starts to get ridiculous.
Once more, the commands are NOT DU and LU.
George
|
|
|
|
Post by George on Mar 27, 2023 13:20:08 GMT -5
Robert: Really! Complaining because you have to put a space between a command and an operand?
Criminy!
Yes, get your macro writing going if this is just too overwhelming for you.
This is starting to smack of extreme nimbyism.
George
|
|
