|
Post by Robert on Jun 13, 2023 1:59:32 GMT -5
Right now, decisions about what to do with a given file type are controlled by 3 different resources:
1. The list of types using the DEFAULT profile is in the General Options GUI
2. The list of non-Text file types is in the FM Options GUI
3. Specialized file types are defined in EFT
4. The list of actual defined profiles is at the "bottom of the totem pole" so to speak.
The file types in the Options GUI lists are awkward to edit when they get long, and there could be an issue if the same name were in two lists (unlikely but not impossible). In any case, having three different lists is undesirable.
The suggestion is to use EFT for everything (other than actual profiles). Here is the general idea:
1. Since DEFAULT is the name of an actual profile, there is no need for a separate DEFAULT list. For any entry like ABC in the current default list in the General Options GUI, it can be replaced with an EFT entry of:
ABC = DEFAULT
Thus, the current DEFAULT list could be eliminated.
2. For the non-Text list, these entries define actions to be taken for files that are not edited. Files which are not edited do not need or use profiles. Therefore, the syntax of the current EFT definition list is insufficient for that purpose.
Suppose the EFT definition syntax were enhanced. Here is a proposed format for discussion purposes. There would then be two formats:
pattern = profile ; current EFT definition
pattern @ action ; proposed EFT entry to define an "action"
What sort of "actions" are possible?
@ NONE do not edit the file (maybe SKIP could be used instead?)
@ WINDOWS option with Windows, like the current FM line command W does now
@ BINARY this would be similar to @ WINDOWS but would mean the file needs some kind of binary reader for it, like a Hex Editor the process by which a BINARY file was handled would have to be specified somewhere (that part is not considered here) this is a possible future enhancement
@ XFORM this would be for a file that had to be opened using an XFORM process I am not sure if this is even needed, and again this would be a possible future enhancement
It would have to be determined if the @ notation would be compatible with the existing logic, or if something else had to be used, perhaps like pattern [action]
or something else.
The various keywords above could be abbreviated, I suppose, but I kind of think it would be better to spell them out, for the sake of clarity and to not box us in, in case you wanted to expand on the idea at a later date.
I don't want to over-elaborate the idea. This should be enough for now. I realize this would be a bit of work to do, so there is no priority. But, it does have a few advantages:
1. Right now, you are already (I believe) checking the EFT list before deciding that a file type had a profile or not. Then you check the other lists. So, when a type is not in EFT but is in one of the Options lists, the EFT gets checked for nothing. By putting everything in EFT, there is only one list to check. That might make the lookup a little more efficient.
2. Since EFT entries can be easily edited in EFT Edit, the awkward cutting/pasting and inserting into the Options lists would be eliminated. I see that as a much more user-friendly way of defining these special types.
Well, that's the idea.
(Hey, it's 3 in the morning and I can't sleep. I had to do something with my time ...)
|
|
|
Post by George on Jun 13, 2023 8:11:12 GMT -5
Robert: After wasting a lot of time yesterday before I realized that the bug you reported was caused by the code using the wrong list, it's obvious that even the developer is confused by the existing structure.
I agree EFT should be the single place for all this stuff. I'll have a look at the various places that will have to be poked.
George
|
|
|
Post by Stefan on Jun 13, 2023 8:46:42 GMT -5
Hi Robert, I can see how maintaining long lists in OPTIONS dialogs pages is awkward and relies on the user knowing where to look for which purpose. So I easily support the concept of a single list, and EFT would seem to be a logical choice.
In addition to file-type, it would also allow the different actions to be applied at individual filenames, much more flexible than using file-type alone.
What follows is just some random thoughts about the "@ (action)" concept.
a) Thinking especially about @ XFORM, that takes cae of how to read or write the file. I agree, we may not even need it.
I note that the exitsting profiles include more than the 'physical' file attributes. They also specify what might be considered " Editor behaviour" and " User Operational Preferences". Without an actual profile entry in the CFG, these settings would, presumably, just be taken from the DEFAULT profile. This might be awkward as (a) they're probably inappropriate and (b) means that the actual 'settings' used for that file's edit session are derived from different sources. But I guess that's what happens now anyway when an unknown file-type is encountered. Maybe @ XFORM simply adds the relevat XFORM-name ON/OFF setting to the new profile.
I guess @ XFORM would need to be followed by a XFORM-macro-name, and macro could also provide/override the "Editor" and "Operational" values as required.
b) Semantically, I'd prefer IGNORE to NONE or SKIP. c) Given that @ WINDOWS uses whatever default application WINDOWS applies to the filetype in question, would @ BINARY not be more useful if it were a @ REDIRECT <program-name>? Then users could specify which utility they wish to deploy when they send an unsuitable file to SPFLite. Although, it's unlikely that users would choose a default "Always Open With SPFLITE" setting for files which are unsuitable, this "redirect" feature may be useful to folks who select files from the FM lists.
d) One tricky aspect might be how to add @ action entries to the EFT list internally, as done with the "Cancel and Exempt" or "Cancel and Mark OpenW" options, given that the sequence of the entries in EFT are important. Perhaps they could just be added at the front of the file and rely on the user to change that manually if required.
|
|
|
Post by Robert on Jun 13, 2023 10:35:30 GMT -5
Notes:
(a.1). I don't feel strongly about the XFORM and BINARY actions, but I presented them as possibilities, since an "Action EFT" allows for new ways of doing things that we can't do as easily right now.
(a.2). Your comments about overriding profile values touch on a concept I thought about this morning. I am going to call this concept "Anonymous Derived Profiles", which will appear in a separate suggestion post.
(b). NONE is consistent with other SPFLite setting that imply a NO or NULL value. Consistency is better than semantics, given a choice.
(c.1). The REDIRECT concept is interesting. Since the point of it is to specify a non-SPFLite process to open the file, I would use OPENWITH for this idea, as the Windows File Explorer uses that terminology for essentially the same purpose.
(c.2). I have a hard time understanding why "Always Open With SPFLITE" would be needed or useful, since that is exactly what specifying DEFAULT or a normal profile name does. You would need to make a case for this to convince me.
(d). I believe your observations about the GUI adding new EFT entries, and in what order, are essentially correct.
|
|
|
Post by George on Jun 13, 2023 12:57:25 GMT -5
I'd go with an EFT format like:
EFT_Mask_string = profile [, KWD value] ...
Examples.
INC = BAS TXT = DEFAULT EXE = , Don't open, skip it JPG = , OPENWITH IrfanView.EXE No Profile means a non-txt file PDF = , OPENWITH SumatraPDF.EXE MP3 = , OPENWITH WINDOWS
I see no need to handle XFORM specially, it's a Profile option, lets leave it there
Robert: If you're proposing another layered, hierarchical Profile approach, please don't.
George
|
|
|
Post by Robert on Jun 13, 2023 16:21:43 GMT -5
Comments:
1. I am having trouble wrapping my head around this syntax. Ignoring the first two lines which are same as current, I would prefer to see just the comma used for the new features. A lone comma here means that you aren't specifying a profile but something else:
EXE, SKIP ; Don't open, skip it. I find the notation of EXE =, to be too cryptic. ; Also, if the EFT list was lengthy, finding "skip" entries is a problem; what do you search for? Searching for "SKIP" is easy
JPG, OPENWITH IrfanView.EXE No Profile means a non-txt file; "no profile" is shown by absence of an = sign
PDF, OPENWITH SumatraPDF.EXE
MP3, WINDOWS ; Not "OPENWITH WINDOWS" because that makes "WINDOWS" look like a program name. WINDOWS is a keyword here
2. Inclusion of XFORM was an IDEA, that's all.
3. The other post has to do with a Derived profile, and it explains as best I can. There is no "hierarchy", but it does describe what you might call a 'layer' since there is a Base profile that is modified to form a Derived profile. And, I have a disclaimer that I am giving you an "out" to turn the idea down. I'd say, just read the explanation of it without prejudging it, then form your own opinion.
|
|
|
Post by George on Jun 14, 2023 8:19:00 GMT -5
Robert: The reason I left the = in there was simply the fact that it is used in the current format. I don't want to have to perform an EFT migration to the new format, and leave users no way to 'go back' to a previous release since their EFT file would be considered invalid.
George
|
|
|
Post by Robert on Jun 14, 2023 8:43:50 GMT -5
If you want to retain the existing format, how about a compromise? Adopt the existing SPFLite convention that when a 'name' doesn't refer to anything, we use NONE. Everyone knows this rule. That would give:
MP3 = NONE, OPENWITH WINDOWS
Of course, if anyone used these new features and then went back to an old release, none of them would work and the EFT would still be considered invalid. I am not sure that a format like MP3 = , OPENWITH WINDOWS will solve the problem.
Here is something that would: You could adopt a 'new' syntax for EFT lines, where an in-line comment that starts with ;; means an 'extension' to the line. Lines with ;; extensions wouldn't be allowed to have regular comments too. I doubt that will inconvenience anyone.
Then, prior versions won't even see the extensions. They will just like comments that start with ;; which will be no different than the old ; comments. No harm, no foul, no invalid EFT.
That would make the 'new' syntax like
MP3 = NONE;; OPENWITH WINDOWS
If you really disliked NONE, you could use one of the reserved Windows names like NUL or AUX. They cannot be real extensions. That would give,
MP3 = NUL;; OPENWITH WINDOWS
Thoughts?
|
|
|
Post by George on Jun 14, 2023 8:53:49 GMT -5
Robert: Sure, the ;; looks like the best approach.
George
|
|
|
Post by Robert on Jun 14, 2023 12:11:21 GMT -5
OK George, here is the "better way" to modify a profile, that doesn't involve "deriving" anything, or anything else weird.
If we allowed something like
L:**.txt = TXT,EOL LF
what it would be doing [in the OLD way that I documented but then withdrew] is modifying the profile so that you could edit something with 'slightly different' profile settings. BUT, the way I envisioned in the other suggestion is just too hard.
Here's the easier way. We ALREADY have a way of 'tweaking' an edit session. It's called IMACRO.
Now, suppose we could include an IMACRO name in the EFT line. Like this:
L:**.txt = TXT;; IMACRO EOL_LF
Here, there would be an IMACRO called EOL_LF.MACRO that would contain a primary command call, and would look like this:
' EOL_LF.MACRO SPF_CMD("EOL LF") HALT()
Then, when you see an IMACRO parameter on the EFT line, you would 'insert' the name into the process used when opening a file.
NOW, one thing I am not clear on is whether you'd have to override any existing IMACRO, or whether you could run them both.
So, yes, you would have to parse the new IMACRO keyword on the EFT line and grab the name, but that's ALL the parsing you'd need to do.
This also explains why you need both the = sign and the ;; as separate parsable items on the EFT line.
Thoughts?
|
|
|
Post by George on Jun 14, 2023 15:13:26 GMT -5
Robert: Sorry, won't work. IMACRO is run AFTER the file is successfully loaded, so that the IMACRO can play with the actual data.
Trying to adjust EOL LF after the file is loaded, or any other Profile variables needed to load the file is just not possible. The Profile must be adjusted right after the base profile is loaded and before it is used to read the data file.
Hmm, I can see it coming, we need a PMACRO, to be run right at that point. Not even sure if the rest of the Tab data areas are suitable at that point.
George
|
|
|
Post by Stefan on Jun 15, 2023 1:36:39 GMT -5
George, I can see that IMACRO isn't the practical option, but what about XFORM or better still, some new profile 'feature' akin to XFORM. As it stands, XFORM does the actual I/O so it must be involved in the wider file loading process and hence it 'occurs' at the approriate time - before SPFLite actually loads the file. The profile override value(s) specified in the EFT could be passed to this new XFORM-like profile 'feature'. Could such a 'feature' be used to EITHER... - Load the profile and modify it BEFORE SPFLite loads the file OR... - Modify the profile AFTER SPFLite has loaded it, but BEFORE SPFLite loads the file?
I guess that's what you're thinking about with the PMACRO idea.
|
|
|
Post by George on Jun 15, 2023 9:15:28 GMT -5
Stefan: XForm is triggered right in the actual physical read routine, just substituting XFORM's data for the built in read,
If we add the Profile commands to the EFT entry, then what is needed is to store them somewhere, and when the Normal Profile read is finished, it would simply pass the commands 1 by 1 to the command processor, and fiddle the LOCK state as Robert suggested to support a DERIVED state.
Probably some accommodation elsewhere because of the DERIVED status, but they should be minor tweaks.
George
|
|
|
Post by Robert on Jun 15, 2023 12:33:52 GMT -5
Hi George, sorry for the late reply, I had a bad night with stomach problems, just starting to recover. (Sigh)
My rationale for the IMACRO approach was to avoid requiring you to parse a list of primary commands on the EFT line. I didn't want all this to be any more complicated than it had to be.
I see what you mean about EOL. You'd already need to have a correct EOL setting before you loaded the data. Otherwise it would get stored incorrectly. But, I took to heart your request that you didn't want any "hierarchy" of profiles.
Having said that, I am re-reading your comments:
"If we add the Profile commands to the EFT entry, then what is needed is to store them somewhere, and when the Normal Profile read is finished, it would simply pass the commands 1 by 1 to the command processor, and fiddle the LOCK state as Robert suggested to support a DERIVED state."
If you could pull this off, this sounds like it might be possible. Perhaps what you need is a "mini-parser", capable of parsing ONLY the Profile-affecting commands that could be useful in an EFT entry, but nothing else. Any extra IMACRO-like work would remain in a real IMACRO and not here. This "mini-parser" would have to deal with only a handful of commands, and need not be anywhere near as complex as the full-blown primary command process.
===> More information
Looking over the comments in the current-beta section, if you limited the kinds of commands on the EFT line to the ones that you now allow on the new DCB command, then the answer points to itself:
; EFT Entry:
L:**.txt = TXT;; DCB EOL LF
Then, your job (should you choose to accept it) is to get this DCB command passed to the command parser somehow.
|
|
|
Post by Robert on Jun 15, 2023 12:42:58 GMT -5
Note changes I made to the prior post.
|
|