|
|
Post by George on Mar 27, 2021 10:16:14 GMT -5
Robert: First, lets get rid of any notion that FM will EVER support M / A / B move commands. Never, ever going to happen, you know how complicated it makes Edit line command processing.
I think something might be done if we can come up with an easy to type character (wouldn't want to have to Shift/Alt etc), maybe as simple as a comma.
Then we could use the Name* sort which already does physical sequencing by manipulating the physical sequence key. However, any tagging and re-ordering would be lost on any true data refresh. Don't even think of asking for it to be able to survive a refresh.
Best I can offer.
George
|
|
|
|
Post by George on Mar 27, 2021 13:36:18 GMT -5
Robert:
OK, we pick a line command char, easy to type.
User tags whatever FM lines, they want. Press Enter
The command will 'fiddle' the current Physical Sequence field. Right now that's just a simple counter that starts @ 1 and bumps for every line item added. I'll simply start the default numbering at 1,000,000 (or some other large value). The fiddle will basically go as follows:
* Scan the current list and find the highest PSeq # under the 1,000,000 value.
* Process each tagged line and replace the original PSeq # with the new value (+1) from the previous step.
* Repeat for each tagged line, incrementing by +1.
* Resort and redisplay via the current Name* sort procedure.
* All the tagged lines will float to the top
If you want the lines in a particular specific order, you would a) Tag b) Press Enter c) Tag another d) Press Enter, etc. etc.
Any change to cause a refresh of the data would wipe out the tagged sequence as new PSeq #,s get assigned during the load.
George
|
|
|
|
Post by George on Mar 28, 2021 9:31:52 GMT -5
Robert: I think this whole ting has to be scrapped. Remember years ago, when FM first came along, we had the problem that the FM display didn't get updated as files were edited, created, deleted, whatever. You suggested FM should be refreshed after basically any action that might change something.
I countered that it would be time consuming and costly. You convinced me that wasn't a concern and that 99% of the time it would still be a 'blink'. So that's what we did. FM does not "monitor" what it displayed (like FileWatch does). It just gets tapped on the shoulder from here, there and everywhere to do the refresh/reload.
And that would destroy this PSeq scheme totally.
George
|
|
|
|
Post by George on Mar 29, 2021 10:34:46 GMT -5
Robert: I've tweaked things a bit more to make this work together a bit better. - FLISTS will now support either quoted or un-quoted names for Paths/Filenames
- Corrected FM CUT, it wasn't always handling single C line commands properly
- The RECALL command will accept (like some other commands) a single * to mean the Clipboard
- The RUN command will now support an optional 1st operand of .Extn, to specify the extension to be used for the RUN. It can also override the normal extension of the file being edited. RUN of a CLIP session will default this operand to .BAT.
So now you can, in FM, use CUT and select a bunch of lines, then issue RC * and the selected lines will be displayed as an unsaved FLIST.
To save it if desired, just use MakeList.
Look for the 21088 version.
George
|
|
|
|
Post by George on Mar 29, 2021 13:06:40 GMT -5
RC * will open the clipboard just as if it was an FLIST file. Everything else is the same except it is not saved (unless you use MAKELIST)
And it doesn't save the CB data either. If you do the above, switch to some other FM Mode, do an edit, or in any other way possibly change the CB, then going back to FM and using (FMBack) etc. will not get you the original CB based display, you will get the CURRENT CB contents.
It is truly a temporary FLIST.
George
|
|
|
|
Post by George on Mar 29, 2021 14:40:42 GMT -5
Robert: My note said to wait for 21088. It's not there yet.
George
===> Oops, my bad, I can only blame advanced senility :-)) R |
|
|
|
Post by Stefan on Mar 30, 2021 5:54:29 GMT -5
George, I've just started running with STATE ON, so I have no experience of how this worked with versions prior to v2.4. So this may be be a '2.4 thing' or not. It may not even be 'a thing' because I'm being daft, but... This has occurred several times whilst working on a 3000-line file with many line labels and excluded blocks of lines, etc. Sometimes I issue SAVE <ENTER> followed by RELOAD <ENTER> (don't ask why, best I don't embarrass myself) Just occasionally the RELOAD completes and shows the right data, but the command remains on the Command line, accompanied by an error message stating that the Hash value did not match but reload would be attempted anyway. (I paraphrase because I don't have the actual message to hand and have failed trying to provoke it)
I read the bit in the HELP document... "An invalid STATE condition can happen if you restore or copy a file from another location, such as a backup, or download a copy from a web site. When SPFLite detects this, it will not use any saved STATE information."
... but that isn't the case here. The file is ONLY open in SPFLITE edit, has just been SAVEd and then RELOADed.
Is there perhaps timing issue between the "data" SAVE, the "State" update write and the Reload?
It must be kind of expected behaviour, else you wouldn't have a message for it, but could you explain what is happening and why, please? Thanks. |
|
|
|
Post by George on Mar 30, 2021 9:16:07 GMT -5
Stefan: STATE checks several ways for integrity.
First, a simple line count checking.
Next is a hash of the whole file (sounds like that's the one you failed on).
Next for each 'section' (Labels, Tags, X'd, Hilights etc.) the # of STATE data records is validated.
Lastly, as each section is processed, where a line is to be altered, the individual hash for that line is validated.
As to what happened, it almost seems as though the RELOAD was not reading the newly written STATE data, but a prior version. Any chance these were network located and your NAS is feeding older cached data back? I'm grasping here.
George
|
|
|
|
Post by George on Mar 30, 2021 9:29:09 GMT -5
Robert: Stefan:
An early version of STATE actually did a "wander nearby and search for a line match when line hash fails". It rarely worked, and had numerous cases it just couldn't cope with.
Then we started adding more and more items to the STATE data. It became impossible to track the logical line pointer so I yanked it, my brain just couldn't cope.
Come up with some workable scheme and I'll try it, but you'll have to bone up on how data is stored internally first, no "pseudo code" or "this is conceptual" stuff.
George
|
|
|
|
Post by George on Mar 30, 2021 11:35:26 GMT -5
Robert: STATE hash is always done on the LOADED file, not the disk based file. So stuff like BOM, CRLF and LF differences have no effect.
Trailing blanks DO have an effect, the STATE logic has to honor the PRESERVE setting to make sure that any stripping done by SAVE is taken into account. i.e. it does it's own temporary PRESERVE function before doing Hash accumulation.
Maybe the next time someone gets a STATE failure they could just call a quick halt, CANCEL out of the Edit session and send me the Edit file and the failing STATE file and I can do a walk-through and determine the failure cause. Mind you, if it just comes up and says the overall file hash doesn't match, we have a mystery and still no clue.
George
|
|
|
|
Post by Stefan on Mar 30, 2021 12:06:07 GMT -5
I'm really not concerned enough for anyone to spend a whole lot of time chasing this down. As far as I can see, there are no adverse effects to the data, just the minor inconvenience that a command is left in command field which messes up a subsequent UP or DOWN scroll. As I said, over 90% of the time there's no issue at all. I only mentioned it because it was unusual and unexpected, but if George isn't worried, I say we blame 'cosmic rays' and move on.
{PS: Apologies - I thought I had targeted this STATE question into the v2.4beta discussion.
Turns out I missed by a mile and it ended up in Suggestions for "FM Unordered lists".
Sorry Robert, I didn't mean to hijack your thread. }
|
|
