|
Post by George on Sept 6, 2023 8:57:02 GMT -5
Robert: A user sort order just creates more problems and basically wouldn't work. Why? The FM display gets refreshed so frequently. If a user order was created by moving entries around, the next refresh would destroy it. Just swapping to an Edit session and back would be enough to do that.
George
|
|
|
Post by Robert on Sept 6, 2023 10:04:26 GMT -5
Let me kick an idea around. It's JUST an IDEA.
Suppose there was a "user sort order" represented by Name# on the "Cmd Dir Name" heading.
Suppose further that when a "user sort order" was in effect, SPFLite created a "hidden FLIST" within the folder being displayed. In order to "hide" this FLIST, you could either use a Windows "Hidden" attribute, or just use some reserved extension or reserved name, like "__HIDDEN.FLIST". Any name you wanted; and then you just wouldn't show it in an FM display.
Then, whenever the FM display was in user sort order, you would read the hidden FLIST and interpret it to refresh the screen. The hidden FLIST would thus serve as the "state" of the FM list.
If there wasn't any hidden FLIST available, you would treat the order as the last 'real' order, such as Name+. The FM order would stay displayed as Name+ until you moved lines around, which would cause the hidden FLIST to get instantiated.
I believe these hidden FLIST files would have names that were time-stamped with the time when the current SPFLite was started up. That way, in the next startup, they would get deleted, and recreated if User Sort Order were requested again. So, the user order would last as long as a given SPFLite instance, but not across instances. The whole multiple-instance issue would clearly be a pain, and I don't know enough about it anyway to comment much on it.
I am not going to overly elaborate this idea, because again, it's just an idea. But, something like this might work (if there were any demand for it).
R
|
|
|
Post by George on Sept 6, 2023 11:57:27 GMT -5
Robert: A lot more thinking needed here. Your assumption is that the display is pointing at a FilePath, what about the other forms (Recent, A specific FLIST, Open, etc.) Do we keep a 'Hidden User FLIST' for each of them? Where? Or do we disallow moving entries for some of them. What about new files created since the hidden list was created, they wouldn't show.
I can see lots of wrinkles in this.
George
|
|
|
Post by Robert on Sept 6, 2023 15:42:45 GMT -5
I did consider some of these issues, but as I noted in the last post, I didn't want to over-elaborate the idea. Since you asked, I will give you some of that elaboration.
1. Part of the solution involves deciding what kind of features a 'user sort order' would support. If a given sort order were permanent (one that would survive a shutdown/restart) it would need to be a file, otherwise the information could be kept as data structures that would disappear at shutdown.
2. If you consider how Windows handles this idea, it stores all known folder display attributes as registry entries. So if you open one Windows folder and change anything about it, like GUI size, position on the desktop screen, specific columns displayed and which column(s) are the ones sorted, those attributes are stored in the registry. When you reopen that same folder, it gets redisplayed the same way it was the last time you looked at it. That Windows feature clearly takes a LOT of logic to support; it was no trivial effort on Microsoft's part. I would never suggest something that elaborate.
3. I wasn't actually assuming the starting point was always a file path. That was the easiest way to try to explain the concept. Ideally, it ought to be possible to change the display order of any FM list, even though structurally they would differ from each other in one or more ways. To me, the most straight-forward way to achieve that would be to abstract each type of FM display as an object, and then maintaining them would require access to each list type using object methods. Any other approach would be far too difficult to implement, and nearly impossible to maintain the code for it. The use of objects is how you would 'hide' the 'wrinkles'.
4. The object implementation is how you would 'hide' all the details about the kinds of questions you asked, like where user order lists were stored, whether moving and reordering FM entries was or wasn't allowed, and so on.
5. I believe if new files were added to a user-ordered list, they would be added to the end of the list, and then the 'hidden flist' would be revised to reflect the new contents. That is, if adding and reordering the particular list were allowed in the first place.
Yes, lots of wrinkles. And, if I need to use 5 bullet points just to answer them in the briefest way, that is probably nature's way of saying this is too hard for the payback. Compare this to the EFT project. It was very hard to get that working, and it is still impacting the code, but there was a big payoff to it. Does "user sort order" have the same payback? No, not really. And if doing it 'properly' is very hard (which is likely) and you don't get much back, I would be hard-pressed to push for it.
Unless you can think of some approach that was like *really* simple, I think this little thought exercise has probably gone as far as it can.
R
|
|
|
Post by George on Sept 7, 2023 11:26:36 GMT -5
Robert: I do have some thoughts brewing. I'm looking at:
1. It will be temporary, if someone really wants permanency: * create an FLIST using MakeList, edit it and put it in the right order. * Make it a Quicklaunch entry by starting the name with _ * Set the sort order for that item to Name* 2. Instead of M / A type line commands, create a MVU / MVD (MoveUp / MoveDown) line commands which could be assigned, say, to Alt-UpArrow and Alt-DownArrow. I seriously doubt the size of a file list would be too large for this to be impractical. 3. Any use of MVU / MVD would: * renumber the current Seq. Key to match the current sorted list order (first time used only) * switch the sort order to Name#. In Name#, the sort will be on Seq. Key and all non-forced refreshes would be suspended. * i.e. to get out of Name#, a REFRESH command would be needed.
Preliminary thoughts only
As to objects etc. The FM data storage is already a list of Objects, there's not much more can be done here.
George
|
|
|
Post by Robert on Sept 7, 2023 12:40:20 GMT -5
1. I like the idea of Move Up, Move Down and that you would maintain a SEQ field that got automatically 'resequenced' during up/down moves.
2. Note that in the Help Appendix describing keyboard functions, we are already recommending Alt + arrow-key for the various (Scroll*) functions. As a possible alternative, the keypad arrow keys might be used instead.
3. I believe if you clicked on any other FM heading keyword, that would exist from Name# mode. In fact, you should exist from Name# if you clicked on Name. In addition, I believe performing a (MvUp) or (MvDn) would implicitly enable SEQ mode. Don't think an actual REFRESH is needed. Or else, maybe REFRESH would do something else, like making sure any new files in a folder (or in an FLIST?) got incorporated into the user sort order.
4. Idea: Suppose you had an FLIST actively being used. Then, use of (MvUp) or (MvDn) would not only enable SEQ mode (that is, Name#) but it would populate the FLIST with file names and their associated sequence numbers.
5. Tricky part of using an actual FLIST for anything is that "symbolic" FLIST's with wild-cards would somehow have to be changed into FLIST's that specifically named each file.
The way that could be done is to have the FLIST have a "hybrid" structure where it had both literal file names and file patterns. The way you'd have to handle them is to make two filename lists. One list would have all literal names, along with their associated SEQ numbers, and one list would be an expansion of the wild-card patterns. Then, those two lists would be merged, so that any names appearing in both the literal list and the 'expanded' file-name pattern list (that is, every name that matched the pattern) would only be displayed once, in the literal list.
That would be a tricky little piece of code, but it's a straight-forward hunk of match/merge logic.
R
|
|
|
Post by George on Sept 7, 2023 12:55:10 GMT -5
Robert: The Alt-arrow stuff was an example, I would not pre-define anything and leave it to the user to choose what mapping to use.
As to what will "exit" Name# mode, I'm easy, REFRESH, click on the sort order, whatever - TBD.
No way I'm going to try and 'adjust' FLISTS to 'match' or 'sync' with the Name# arrangement. Let alone redefine what the contents of an FLIST look like.
George
|
|
|
Post by Robert on Sept 7, 2023 16:13:52 GMT -5
I had a thought about this. Suppose there was some kind of command or keyboard primitive that would do something similar to 'highlighting' an FM line. Then, the (MvUp) and (MvDn) would move all of those highlighted lines as a group. Some kind of RESET would deactivate that highlighting.
Doing that would make it easier to blocks of file lines, even if present in scattered locations, as a unit.
R
|
|
|
Post by George on Sept 8, 2023 8:17:03 GMT -5
Robert: MvUp and MvDown are FM Line commands, so MvUpp and MvDownn blocks would be there.
But on further thought, I'm less keen on this approach. Our basic problem is in MEdit, and the inability to move whole files around. I think any effort here should be to address that directly. MvUp/MvDown effort is likely to be very little used.
There is a current workaround (I use it myself) of creating an FLIST in the right order and using Name* sort. I will tackle that after this current release makes it out.
George
|
|
|
Post by Robert on Sept 8, 2023 13:50:09 GMT -5
If you wanted everything done in MEDIT, think of an MEDIT session, then issue an X ALL. That will exclude all the data lines, but leave the =FILE> lines showing. Now, suppose you could use M and A or B on the =FILE> lines. That would allow you to reorder without making or altering an FLIST.
Problem with that approach is you can't repeat the process without manually reordering =FILE> sections over and over again. At least with a real FLIST you can issue an M on the FLIST line (right?) and if it's already in the right order, you're good.
Still, I wish I could just say FCUT on an FM line and copy that file into the clipboard, or FCLIP to copy the file to the CB and jump into Clip Edit. The macro I did *sort of* works, but to do it right, it needs to know about a file's profile, to distinguish things like UTF-8 and UTF-16 as well as EBCDIC.
R
|
|
|
Post by George on Sept 8, 2023 13:58:19 GMT -5
Robert: Unless you edit the clipboard first, what's wrong with the COPY command? It copies the data and honors the file's Profile properly. Just say COPY, put the A line command where it goes, and hit enter. The file selection prompt will start in the same folder as the file being edited.
George
|
|
|
Post by Robert on Sept 8, 2023 14:46:51 GMT -5
I made a better FCLIP.MACRO that does use COPY like you suggested.
R
|
|
|
Post by George on Sept 17, 2023 11:03:25 GMT -5
Robert: The latest Beta has support for moving =FILE> (whole files) inside a MEdit session. It uses only M and A/B, no block mode or repeat supported.
George
|
|
|
Post by Robert on Sept 17, 2023 14:01:13 GMT -5
I look forward to trying this out. I am already imagining some macro utilizing this feature to inspect the data within =FILE> blocks and performing some kind of sorting operation by using M and A/B.
This is going to be interesting. Thanks for adding this.
R
|
|
|
Post by Robert on Sept 17, 2023 17:44:21 GMT -5
George, I have tried the beta version support of M A/B for =FILE> entries. I found it to be a little unexpected. It *seems* like what you are allowing is not the moving of files, but moving of =FILE> lines. It was quite easy to scramble the contents of an MEDIT, and each time I tried it, I felt compelled to issue a CANCEL.
What I thought you were going to do is treat each =FILE> line AS IF it represented the ENTIRE file underneath it, and not just the file-heading line alone.
My tests consisted of starting an MEDIT, then issuing X ALL to leave only the =FILE> lines.
When I tried putting A or B on an =FILE> line, I get the message, "Destination for ==FILE> move is illegals" (with typo of plural "s" here)
That wasn't the response I expected. I thought it was going to move the whole file headed by a =FILE> line before or after another =FILE> section.
I wish this action was limited to moving whole files around. Otherwise, I feel it's too easy to mangle the MEDIT session this way. It doesn't give me the sense of being "safe".
R
|
|