|
|
Post by Robert on Sept 4, 2023 11:46:53 GMT -5
FM supports a CUT primary command, but its function is to copy full path names to the clipboard, and as it says in Help, it is NOT to copy the contents of a file.
Only thing is, I often DO need to copy a file to the clipboard, when I want to examine it, or extract some part of it to make a file with some derived data.
Right now, the only way to do this is to open the file, do a CUT ALL, then CANCEL the edit, and issue a CLIP command.
I wish FM had a way to do a "data cut" function, where I could do what I describe above in one step.
There are several ways this could be done. One might be to define a new FM line command to define a file name for "data cutting" instead of "file-name cutting".
Or, a macro might be made to do this. There might need to be two macros, one to just "cut" and one to do a "cut append".
I am afraid my macro skills are getting rusty, so I hesitate to try this myself.
If macros like this were made, I don't see them as needing to be overly complicated or "feature-rich", certainly not at first.
R
|
|
|
|
Post by Stefan on Sept 4, 2023 12:22:07 GMT -5
Robert,
I'll have a go at a macro - give me a couple of days, plse.
|
|
|
|
Post by Robert on Sept 4, 2023 13:19:16 GMT -5
I look forward to that. I am sure that a skilled macro writer could pull this off. Truth is, ever since the macro feature was added, a number of years ago, I've had only limited uses for it. So, I have forgotten a lot what is needed to write one, and so much has been added, I hardly even know what macros can do any more, especially with all the FM support.
Here are some suggested names:
FCLIP = copy contents of file to clipboard [deleting any prior contents of clipboard]
FCLIPA = copy and append contents of file to clipboard
It's possible that maybe only one macro is needed. Suppose there was an FCLIP.MACRO that copies a file into the named clipboard of FCLIP.CLIP. Then, if a user wanted to "append" to the 'plain' clipboard, they could be in a clip edit and just PASTE FCLIP as needed.
That would mean you'd have to do this stuff one file at a time, rather than clipping a several of them at once.
Just a thought.
R
|
|
|
|
Post by Robert on Sept 4, 2023 20:41:45 GMT -5
I created a hack-job version of FCLIP.MACRO as a proof of concept. Comments invited.
R
===> The macro seems to crash if the file is Unicode and is large. Right now, "large" seems to be about 800-1000 lines. Doesn't really make any sense.
===> Well, it's not the size. I did an FCLIP on a text file over 50,000 lines long, and it worked. Something is wrong with how I am handling Unicode. The idea in the macro was to avoid creating these dummy bytes at the beginning when the BOM gets converted. I want to get rid of them, but my code must be doing it wrong.
|
|
|
|
Post by Stefan on Sept 5, 2023 5:16:29 GMT -5
Robert,
With FCLIP you're loading the file into a string variable. This raises the questions... What's the thinbasic limit in terms of size for those? What effect do x'00' nulls in the file data have on a 'normal' thinBasic variable-length string variable?
I was going along similar lines but slightly different approach.
1) Make a new FM PRIMARY command (e.g. CUTFILE or CUTDATA) which accepts all the usual FM CUT arguments 2) Loop through the lines in the FM display looking for line selection criteria - e.g. a CD (cut-data) line command - blocks like CDD..CDD allowed
- For each one we capture...
- Load the file - I hadn't considered this for v1, but I see you need to fiddle the UTF bits - Write or append to an existing/new clipboard (as specified by the primary command options, although default is probably NEW REPLACE first one, and APPEND thereafter) - Clear the FM line command field 3) When no more selections finish the macro with a POST-DO "clip" command
|
|
|
|
Post by Stefan on Sept 5, 2023 5:30:41 GMT -5
Robert,
On second thoughts - Lets forget the fancy macro concept.
This whole thing is easier if we let SPFLITE do the heavy lifting (UTF etc) for us.
Step (1) - on FM screen, select the relevant files with 'M' to create a MEDIT session Step (2) - in the MEDIT session, execute a macro or DO file (name of your choice) which issues
Macro: SPF_Post_Do("!UP MAX(Enter)(FirstLineCmd)(Down)[C/](Home)[CUT](Enter)[CANCEL](Enter)[CLIP](Enter)")
Basically... - Scroll to top of MEDIT session - Position to first actual line, avoiding 'Top of Data'
- Type C/ line command (select all lines)
- Position to Primary command field - Type CUT and press <ENTER> (put all lines on clipboard)
- Type CANCEL and press <ENTER> (close the MEDIT session) - Type CLIP and press <ENTER> (open the CLIP session
|
|
|
|
Post by Robert on Sept 5, 2023 10:35:40 GMT -5
That's interesting, I wouldn't have thought of using MEDIT. I think I would simplify the DO part, though:
Your macro:
SPF_Post_Do("!UP MAX(Enter)(FirstLineCmd)(Down)[C/](Home)[CUT](Enter)[CANCEL](Enter)[CLIP](Enter)")
I would rewrite as:
SPF_Post_Do("(Home)[CUT ALL](Enter)(Home)[CANCEL](Enter)(Home)[CLIP](Enter)")
Notes:
1. You can issue CUT ALL from any position in the file, since ALL means ALL; it's not position dependent.
2. I put an extra (Home) before CLIP just to be careful.
3. The macro could easily be changed into a simple key mapping, which is how I think I would do it.
I haven't tried this yet, but I will as soon as I get myself a (late) breakfast.
The only issue I have with MEDIT, which has been one since it was made, is that there is no easy way to move the order of files around in FM. I wish we could do something like M/A does in Edit, but that feature doesn't exist, and I am guessing George wouldn't be too keen on adding it. Even within the MEDIT session, there is no real way to reorder the file sections.
R
|
|
|
|
Post by George on Sept 5, 2023 10:56:54 GMT -5
If you have a common 'set' of files that you Medit regularly and want in a particular order, make an FLIST of them in order, open the FLIST, sort on Name* and do an ALL M.
You're right, supporting the re-ordering of files in MEdit would be pretty tough.
George
|
|
|
|
Post by Robert on Sept 5, 2023 11:33:42 GMT -5
I often thought that you could maybe use M and A/B on the =FILE> lines. You already allow for D on =FILE> lines to 'dismiss' or 'detach' a file from an MEDIT. So, you are already making a distinction when line commands appear on those lines.
Conceptually, it's not THAT hard to figure out, but the hard part would be rearranging all the underlying data structures to reflect the new ordering. Since the whole point of MEDIT is to treat all of the associated files as if they were ONE file, to apply changes to all the files at the same time, any change to the data structures would be risky if not done real carefully.
R
|
|
|
|
Post by George on Sept 5, 2023 11:52:02 GMT -5
Robert: Logically that would work, I'm just not 'up' on the MEdit internals, there is extra stuff to manipulate internally. I'll have a look, but it will have to wait till after this release makes it out the door.
|
|
|
|
Post by Robert on Sept 5, 2023 12:50:22 GMT -5
If I had to choose how to do this, I wish I could rearrange the list of file names in an FM list. If I could do that, then MEDIT itself would not have to be changed.
Currently, the only way to do something like this is to create an FLIST, then physically edit the FLIST, and do an MEDIT on that. That's a lot of prep work, and lacks the 'spontaneity' of much of SPFLite's features that make it so nice to use. I think the prep work would discourage most people from trying it unless they were really motivated. I personally would have to look up even how to make an FLIST, I am afraid to admit how much I am forgetting.
R
|
|
|
|
Post by Robert on Sept 5, 2023 14:01:14 GMT -5
I am not sure if I ever said this before, but a *fairly* easy way to change the order of an FM list would be if there was an FM field called SEQ, and then somehow it would get populated by a sequence number. You would then click on the SEQ field heading to order the list by that number.
For short lists, setting up the field could be done manually. For bigger ones, some kind of sequencing command would be needed, almost like the Enumerate functions in Edit. Maybe an FM macro could do it. I think for a regular list, the kind displayed from a file path and mask, the SEQ field would be temporary, whereas for FLISTs, it would be an actual field that you could edit.
I believe I tried to do this once when we had NOTE fields available, but for some reason it was kind of awkward and didn't work out. To be practical, it would have be easy to use.
R
===> Of course, the deciding factor in all this is if anybody (besides me, that is) even wanted or cared about the idea. That's where the ease of use comes in. If it were too hard to use, nobody would, and all the work to make it would be for nothing.
|
|
|
|
Post by George on Sept 5, 2023 15:07:25 GMT -5
Robert: But that's what the Name* sort field is, a sequential number based on the source of the list (FLIST, FilePath etc.)
I particularly do not want to get back into having 'other' fields on the FM list becoming INPUT fields (like the old NOTE field). That was incredibly awkward internally.
George
|
|
|
|
Post by Robert on Sept 5, 2023 17:56:24 GMT -5
Yes, and the problem about NOTE fields is they only apply to actual FLIST entries, not regular FM path lists.
I believe the way that would work the best is to allow some way to move FM file-name lines around just like you would in an edit session, by Move and Before/After line commands of some kind. Once someone did that, the FM "sort order" would sort of be an "unsorted order".
Think of the "Cmd Dir Name" part of the display. The Name part can appear as Name+ Name- Name* or Name. I believe.
When you display a directory in its "native" order, the notation is "Name*". All of the sort orders are based on something in the directory itself, either the file name, the extension, the path, date/time, etc. If a user could move things around any way they wanted, it would comprise a "user order". This would require some new notation, like maybe Name# or something. Once an FM list were in User Order, its order would be temporary. As long as the FM screen were active, the current ordering would be remembered, but once you did a close/restart, the order would revert to some default like Dir+ Name+ because there wouldn't be any 'data' laying around to remember how you ordered things. (There wouldn't be any 'fields' that you could sort on to restore the User Order.) Otherwise, it would be like having a "state" or something for an FM display, which would be weird and hard to implement.
Just a bunch of random thoughts here.
R
|
|
|
|
Post by Stefan on Sept 6, 2023 2:27:06 GMT -5
Robert, I would rewrite as:
SPF_Post_Do("(Home)[CUT ALL](Enter)(Home)[CANCEL](Enter)(Home)[CLIP](Enter)")So many tricks in SPFLite, I didn't think about 'CUT ALL' !
Note that my clumsier version started with "!UP MAX" where '!' effectively replaces (Home)(EraseEOL).
Hence to be certain, you might prefer
SPF_Post_Do("!CUT ALL(Enter)(Home)[CANCEL](Enter)(Home)[CLIP](Enter)")
|
|
