|
Post by Robert on Jun 27, 2023 11:39:17 GMT -5
I am ok with the EFT LOCKED terminology.
Treating "EFT LOCKED" as a special "kind" of locked profile is what I had in mind in the "old days" (two weeks ago) when I proposed "derived profiles". By locking (that is, not saving) a profile modified by EFT parameters, you have 'derived' one, perhaps without intentionally trying to. Your choice to NOT save changes under these conditions is the correct one.
Basically, you turned right by making 3 left turns, but you ended up in the same place.
BTW, I am wondering if you can see something: If we define a set of EFT entries for every file type we need, and if they all contained overrides to handle the specific underlying file types in question, AND if the type that got overridden was the SAME ONE (let's say, DEFAULT), do you know what that could mean?
The end of profiles as we know them.
I'll let you get back to it. You are doing well.
R
|
|
|
Post by George on Jun 27, 2023 12:46:50 GMT -5
Here's the quick summary of the new EFT support. Comments etc. are more than welcome.
George
* The EFT (Extended File Type) support is being extended, and will take over handling other file type related choices. ** File extensions which should share the DEFAULT profile ** File extensions which should be treated as non-text files ** File extensions which should be Opened by the Windows default app for that extension This means the DEFAULT extension list specified in Options => General will be removed, as well as the no-text list in Options => FM.
To handle this, the entries in the EFT list have new options. The syntax is now: eft-mask = { prof-name | NULL } [ OPENWITH { WINDOWS | full-file-path } [ profile-setting-command ] ... where: eft-mask - Same as the current EFT support, no change.
prof-name - The name of the profile to use when a filename matches eft-mask.
NULL - The selected file is a non-text file.
OPENWITH operand - If OPENWITH WINDOWS is specified, File Manager will open the file with the default windows application for that filetype.
OPENWITH full-file-path - If a full-file-path is specified, File Manager will open the file using the specified application.
profile-setting-command - You may specify one or more commands here which will be used to 'override' the normal values contained in prof-name. e.g. EOL LF SOURCE EBCDIC ... etc. multiple commands may be entered separated by commas
Some examples: .TXT = DEFAULT - Use the DEFAULT profile for .TXT .EBC = DEFAULT,SOURCE EBCDIC - EBC files use the DEFAULT Profile, with the SOURCE overridden with EBCDIC .EXE = NULL,OPENWITH WINDOWS - EXE files are non-text files and are to be opened by Windows .DLL = NULL - DLL files are non-text files. File Manager will ignore them in Find-In-File searches and will ignore them if clicked on. .PDF = NULL,OPENWITH "C:\Windows\. . .\SumatraPDF\SumatraPDF.exe" - Will open the file using the specified file-path **/Linux/.TXT= DEFAULT,EOL LF,STATE OFF - Will open all TXT files from the Linux folder using the DEFAULT Profile and overriding the EOL and STATE settings.
Conversion: SPFLite will automatically convert your existing DEFAULT shr settings, and FM non-text file settings to the new EFT format on the first execution, you need to do nothing.
|
|
|
Post by Robert on Jun 27, 2023 15:29:30 GMT -5
George, my comments follow. They are intended as sincere and constructive. (I can hope.)
Went out for dinner and came back, realized a couple things needed to be fixed. (Don't be mad.)
I feel some of your design could be problematic.
For instance, you are using NULL to avoid naming a profile, because you are insisting that a profile name follow the = sign. By doing that, it means (I think) that the following is syntactically legal but not reasonable:
eft-mask = NULL, profile-setting-command ...
That is, if the profile is NULL (a profile won't be used) the profile settings aren't needed, but you are still allowing them?
FYI, to me, saying eft-mask = NULL looks like it's saying the mask is "nothing". It just kind of rubs me the wrong way.
Part of my confusion comes from the fact that your syntax doesn't show the commas you said you were going to require, and there is a missing ] close bracket in the description. Perhaps your syntax is right but you didn't type it correctly.
In any case, I would like to recommend a change to this syntax. Instead of using NULL to mean that there's no profile, I wouldn't over-stress about insisting that a profile-name follow the = sign. I wouldn't go in that direction.
Instead, I believe you should do this to make it easier. The idea is to only use = to mean the EFT is associated with a profile, and use a : colon for everything else. (I am using the usual syntax notation of A ::= B to mean, "A is defined as B" here.)
eft-line-syntax ::= { eft-profile | eft-run | eft-windows | eft-ignore }
eft-profile ::= eft-mask = prof-name [ , profile-setting-command ] ...
eft-run ::= eft-mask : RUN full-file-path [ cmd-line-argument-list ]
eft-windows ::= eft-mask : WINDOWS
eft-ignore ::= eft-mask : IGNORE
For any values on an EFT line that might cause 'problems', they should be quoted.
That would give you, for instance,
.INC = BAS .EXE : WINDOWS .BIN : IGNORE .MYPROG : RUN "D:\MYAPP\myprogram.exe"
Notes.
1. Your OPENWITH is explaining what is going to be used to open the file instead of SPFLite. However, each time I actually see the keyword OPENWITH, I find it so hard to read it hurts my eyes. And yes, I probably told you spell it this way. I fully accept all blame.
2. The colon notation for RUN, WINDOWS and IGNORE removes the need to quote 'reserved' profile names if they were actual profile names. It also makes it easier to add new features using new keywords in the future, if needed, without breaking the current syntax.
Since you made a full release recently, that is the circumvention for this new syntax being incompatible with older versions. The only restriction is that users can't employ the
profile : keyword ...
syntax going backward. They would just have to comment-out such things temporarily.
3. I believe that IGNORE is better than NULL, because it follows the description you yourself give as to what "NULL" is supposed to mean.
This way, you wouldn't say (the equivalent of) .EXE = NULL, OPENWITH WINDOWS
because you're not actually 'ignoring' an EXE file, you're using it differently by letting Windows open it. So, what I am recommending here in my shorter notation becomes, .EXE : WINDOWS
4. Allowing command line arguments on a RUN program line could certainly be a later addition, but it seems likely someone will ask for it eventually.
5. For the RUN option, assuming that we would want the fully-qualified name to be used somewhere, either you'd have to assume it's the first thing after the application name, or else you'd some kind of place-holder. If we used 'BAT notation' it could take the form of %1 or something, or we could make something up that would never appear on a command line, like "<>" or something. I don't have any druthers here.
Probably at first, you'd only support a default placement of the file name as the first parameter, and would always quote the full-path file name of it when you started it. The whole thing about managing parameters could get real ugly real fast, so for now, the simpler the better.
6. I seem to recall there was some discussion about an "EFTARG". Was that still on the table? It was something that an IMACRO could gain access to.
I'm starting to lose track of all the little pieces, so correct me if I'm off-base.
7. Finally, if you totally hate me for upsetting the apple cart, I get it.
R
p.s. Don't be mad.
|
|
|
Post by Stefan on Jun 28, 2023 3:38:43 GMT -5
George, Robert,
I'll leave you to discuss and agree a syntax for the extended EFT function.
As the new feature (ability to override profile values 'on the fly') is not yet fully formed, I wonder if I might raise an additional aspect....
I have a number of EFT entries which direct certain files (by name) to specific profiles. Many of these files use the .TXT filetype, because that's what they are, BUT I want them to be presented using a specific AUTO colorisation or maybe include an IMACRO/EMACRO. Because the xxxx.AUTO file name is derived from the profile name, the only way to achieve this is to use EFT to assign each file an individual profile. So I end up with more profiles than is strictly necessary, a bit like...
; Files with specific formatting requirements VITALS.INI = INI_VIT ; Vital Records CFGMaint EXP*.TXT = TXT_CFG Dictionary.TXT = TXT_DIC Match*.TXT = TXT_MCH ; MATCH Command support files .M3U = TXT_M3U ; Playlists
You can see I use a profile naming convention to show these are .TXT files, but with a twist. This way they sort together in the FM - CONFIGS display.
My question is:
Could the existing HILITE Profile value be extended to provide the <name> for the <name>.AUTO file, e.g HILITE AUTO ON | OFF | <name> ?
It would reduce the number of profiles to be managed in the CFG, although the number of xxxx.AUTO files would remain the same.
Files like those above could then all be handled using a single .TXT profile with appropriate overrides, e.g.
; Files with specific formatting requirements VITALS.INI = INI, HILITE AUTO VITALS
CFGMaint EXP*.TXT = TXT, HILITE AUTO CFG Dictionary.TXT = TXT, HILITE AUTO DICT Match*.TXT = TXT, HILITE AUTO MATCH, IMACRO im_MATCH, EMACRO em_MATCH
.M3U = TXT, HILITE AUTO M3U
|
|
|
Post by George on Jun 28, 2023 8:36:11 GMT -5
Robert: The syntax diagram is better laid out here:
eft-mask = {
prof-name [ ,profile-setting-command ] ...
|
NULL } [ OPENWITH { WINDOWS | full-file-path }
}
Sorry if the syntax annoys you, but I am not going back in to revise it at this point, it's in, it's working. I don't feel like changing and debugging it all over again. Maybe NULL -> IGNORE, but not the other stuff.
As to confusion over what operands are allowed together, that is all prevented by the EFT scanning routines.
George
|
|
|
Post by George on Jun 28, 2023 9:49:28 GMT -5
Stefan: I can see where HILITE and a specified AUTO file would be handy. I'll have a look.
George
|
|
|
Post by George on Jun 28, 2023 12:35:59 GMT -5
Stefan: Adding an override name to HILITE turned out to be very problematic, it messes up Profile handling a lot.
So, EFT will accept an AUTONAME xxxx override operand. Tested, seems to work fine.
George
|
|
|
Post by George on Jun 28, 2023 12:49:12 GMT -5
OK, another iteration of the EFT syntax: Comments welcome.
* The EFT (Extended File Type) support is being extended, and will take over
handling other file type related choices.
** File extensions which should share the DEFAULT profile
** File extensions which should be treated as non-text files
** File extensions which should be Opened by the Windows default app for
that extension
This means the DEFAULT extension list specified in Options => General will be removed, as well as the no-text list in Options => FM.
To handle this, the entries in the EFT list have new options. The syntax is
now: eft-mask = {
prof-name [ ,profile-override-command ] ...
|
IGNORE } [ OPENWITH { WINDOWS | full-file-path }
}
where:
eft-mask - Same as the current EFT support, no change.
prof-name - The name of the profile to use when a filename matches eft-mask.
IGNORE - The selected file is a non-text file.
OPENWITH operand - If OPENWITH WINDOWS is specified, File Manager will open the file with the default windows application for that filetype.
OPENWITH full-file-path - If a full-file-path is specified, File Manager will open the file using the specified application.
profile-setting-command - You may specify one or more commands here which will be used to 'override' the normal values contained in prof-name.
e.g.
EOL LF
SOURCE EBCDIC ... etc.
multiple commands may be entered separated by commas N.B. A new non-normal override is available as well: AUTONAME xxxxxx
which will override the normal colorization AUTO file for the Edit.
Some examples:
.TXT = DEFAULT - Use the DEFAULT profile for .TXT
.EBC = DEFAULT,SOURCE EBCDIC - EBC files use the DEFAULT Profile, with
the SOURCE overridden with EBCDIC
.EXE = IGNORE,OPENWITH WINDOWS- EXE files are non-text files and are to
be opened by Windows
.DLL = IGNORE - DLL files are non-text files. File
Manager will ignore them in Find-In-File
searches and will ignore them if clicked
on.
.PDF = IGNORE,OPENWITH "C:\Windows\. . .\SumatraPDF\SumatraPDF.exe"
- Will open the file using the specified
file-path
**/Linux/.TXT= DEFAULT,EOL LF,STATE OFF
- Will open all TXT files from the Linux
folder using the DEFAULT Profile and
overriding the EOL and STATE settings.
Conversion:
SPFLite will automatically convert your existing DEFAULT shr settings, and FM non-text file settings to the new EFT format on the first execution, you need to do nothing.
|
|
|
Post by Robert on Jun 28, 2023 16:49:28 GMT -5
George, I wish you had showed your proposed syntax before you implemented it, not after. By doing what you did, you committed to a design before user comments could be taken into account without redoing your work.
Do you really prefer,
.EXE = IGNORE,OPENWITH WINDOWS to .EXE : WINDOWS ??
My main problem, whether you say NULL or IGNORE, is that you're not really 'ignoring' it. You're just not opening it for editing. You're stuck with this because your syntax requires a 'profile name' after the = sign, but then you have to create this IGNORE kludge to make a 'name that's not a name' to get past your scanner.
Then, if you have IGNORE alone, that really IS ignoring it. So, you are using the IGNORE keyword for two completely different purposes, and you have to distinguish them by context.
I am not annoyed by the syntax because I didn't get my own way, but because it's needlessly awkward and wordy, and experience shows that context-sensitive grammars like this can be error-prone. The syntax doesn't really make any sense, and so you are forced to include a very large explanation in the Help to try to fix with documentation a design with a poor rationale. In doing so, you have placed a burden on users that will now have to live with this. The truth is, extended EFT specifications were intended for users such as yourself, George, because I personally don't need them. I really do mean it when I say it's because I didn't get my way. It's YOU that I was trying to help.
I don't approve of this, and I am disappointed that you didn't choose something better. But, I am determined not to argue about things, so I will have to let this one go.
I know you have done a lot of work, and believe it or not, I do appreciate it. But, I can see that you did more work than you needed to. My syntax would have been much easier to implement.
R
===> One more thing
I just want to remind you of the initial history of EFT. I tried to do my own regular-expression engine, and it ran to a couple thousand lines. But it didn't work, so I scrapped it and re-wrote it. Then I re-wrote it a third, fourth and fifth time, because what I had done was wrong, it was a flawed design. Part of a developer's design process is recognizing that sometimes you have to create something and throw it away, because (a) you know what you did was a mistake, and (b) you LEARNED from it, and you know the NEXT one will be better. I think all told, I went through maybe 5,000 lines of code before scrapping it all.
In the end, ALL of my code was wrong, so the SIXTH version ended up as a front-end to the regex engine. If I stopped at "version one" of EFT, only because I tested and debugged it and seemingly got it working and was too lazy to do it over, the EFT we have now would have been functionally crippled and would be inadequate for many users. Instead, I bit the bullet and redid it until it actually worked correctly.
If you only stick with a poor design out of laziness, it will bite you later.
Just saying.
|
|
|
Post by George on Jun 29, 2023 9:07:24 GMT -5
Robert: Wait for user comments? Really? And how many user comments have we received over the years that were about proposed enhancement designs? Close to ZIP. If we waited for user comments, we'd never implement anything.
Why stick with the = after the eft-mask? Well from one of your early comments on this, you said:
Well, that's what I did, and even added preliminary code to the current production release to avoid problems. And now after developing something which is working and avoids such conflicts, you want to throw out the simple "mask = parameters" structure with = signs and : colons which would definitely break any kind of backward compatibility.
As to the time I've spent getting to this point, re-writing it is not a problem if it buys us something. Like you, I've re-written code over and over.
But being honest, I won't do it because I don't like your proposed syntax AND it breaks backward compatibility.
I just don't see why something = operand1 [,operand2] [,operand3] causes you such a problem. Because the operands have different meanings?
A lot of things have multiple operands, in different formats and different meanings. Look at a basic PB Dialog command:
DIALOG NEW [PIXELS, | UNITS,] hParent, title$, [x&], [y&], xx&, yy& [, [style&] [, [exstyle&]]] [,] TO hDlg
It has keywords. some space delimited, some comma, it has variable references, it has numeric constants, text constants, flag equates, and a noise word (TO) thrown in.
And a simple comma delimited list somehow bugs you. I just don't understand it.
George
P.S. Looking at it some more, non-text files went from NULL to IGNORE (at your suggestion) but now neither of us likes IGNORE for various reasons, so it will simply become NONTEXT.
G.
|
|
|
Post by Stefan on Jul 3, 2023 7:10:20 GMT -5
Stefan: Adding an override name to HILITE turned out to be very problematic, it messes up Profile handling a lot. So, EFT will accept an AUTONAME xxxx override operand. Tested, seems to work fine. George Perfectly acceptable, thanks George.
PS: Don't forget to add AUTONAME to the documentation
|
|
|
Post by George on Jul 3, 2023 8:29:10 GMT -5
Stefan: Doing further testing has uncovered some basic internal structure problems. As a result I am tackling changes that I have been avoiding for a long time. It will be a while before any new code comes out. It may drag on past our upcoming trip unless things 'come together' nicely.
AUTONAME will become just another Profile variable. If non-null, it is used instead of the Profile name for AUTO files.
George
|
|
|
Post by Robert on Jul 3, 2023 13:08:32 GMT -5
I look forward to seeing this unfold. I am sorry I have been AWOL, I have not been feeling well for several days.
|
|
|
Post by George on Jul 3, 2023 14:35:35 GMT -5
Robert: Sorry to hear, hope things improve.
My restructuring is becoming a quite significant change, a lot of choices in the past are turning out to be bad ones. I think things will be a lot more straightforward if I ever get this to work again. Right now I can't even load a file.
George
|
|
|
Post by Robert on Jul 3, 2023 18:48:48 GMT -5
I am afraid my problems are not going away any time soon. Part is a consequence of the many medicines I have to take and their side effects. Part is the reality I'm facing is becoming a heavier weight each day. There are days when I am barely functional any more. I don't expect things to improve. Right now, the best I can hope for is to try to cope as best I can. There isn't really any 'better' in the forecast. Sigh. Here is a nice song I have been listening to, to help calm me down: youtu.be/sX2gEkKka7k
|
|