|
Post by Robert on Jan 26, 2023 12:11:40 GMT -5
All these seem reasonable changes. I do have a question about (DataInsert).
Suppose my keyboard default is OVR. Then I press the INS key and now I am in INS mode.
Now, I press the key for (DataInsert). The state is now d-INS.
If I press (DataInsert) again to disable d-INS, do I want the keyboard default OVR/INS state, or do I want the state that existed prior to doing (DataInsert) the first time?
Some these actions, if they involve restores of prior states, might imply a 'stack'. Adding stack logic complicates the behavior and is harder to document, but we DO have such behavior for (SetInsert) and (ResetInsert) vs. (RestoreInsert).
I am not advocating for you to change what you just put in the beta. Mainly, I am just asking the question, is this the correct way to do it? I am not sure myself what's right.
===> More information.
I tested again on 23.026.
If I am in d-INS mode, it doesn't matter if I then press INS or the d-INS key; either one will return me to plain OVR mode.
I am not sure if this is "correct", but one thing I *am* sure of: It's simple and easy to understand.
That in itself is probably a good argument for leaving the beta code in place, unless someone finds a bug.
|
|
|
Post by Robert on Jan 26, 2023 11:55:02 GMT -5
Just got the beta. Yes, it is better. It is clear when it's INS or Data INS, and unobtrusive when it's normal OVR mode.
This is better than all of my suggestions.
Thanks.
|
|
|
Post by Robert on Jan 26, 2023 10:12:40 GMT -5
I hate the blob.
Double-checking, what Word does is it shows OVR grayed out in insert mode, but shows OVR solidly in overwrite mode. Of course, Word defaults to insert, which is the opposite of SPFLite that defaults to OVR.
Personally, I don't like "OVR" meaning two different things, even if they ARE different colors. I find it confusing.
Possibility: OVR grayed out in overwrite mode, and INS solidly in insert mode.
As I said, a dozen different ways to do it. I don't have a real strong feeling about the specifics; I just need them to look more different than they do now.
|
|
|
Post by Robert on Jan 26, 2023 8:43:46 GMT -5
This is more of a 'need' than a suggestion. As my decrepit eyesight continues to deteriorate, I am finding it harder and harder to quickly distinguish between INS and OVR on the status line. In younger days, these two things would be a cinch to tell apart. Today, not so much. Yes, I can take off my glasses and stare, but there are limits to how well this works.
Off the top of my head, I thought up a dozen different ways to accomplish this, from making either INS or OVR show in red font, to making a different background color, like Data INS does now, to putting (OVR) in parens, and so on, and so on.
I am not all that fussy how it gets done, although using two different background colors might be an issue for colorblind users to tell apart.
Here is what I think would work, wouldn't make things worse, and would be easy to do:
Change OVR to OVER
That's it. OVER and INS will look so different, I won't even have to look close to tell.
Runner-up: Change spelling of OVR to "ovr". That way, the case-change from "ovr" to "INS" would make it stand out.
You may have a better idea. As I say, I came up with a dozen different ways. Using OVER has the advantage that it's extremely simple to do, and will work.
===> Just a thought.
A lot of editors like Word make this distinction by graying-out OVR, because their normal mode is INS. In SPFLite, normal mode is OVR. If you could do that, that would work too. Other editors simply don't show OVR at all; having INS is the "non-normal" state, so just leaving OVR mode blank would make it very obvious that it's "NOT insert mode". So, you wouldn't be talking about INS/OVR mode any more; you only mention INS mode because that would be the only one you'd "see" on the status bar: INS or nothing.
|
|
|
Post by Robert on Jan 25, 2023 14:09:17 GMT -5
I was unable to reproduce the "data insert mini bug". It does not act on my system the way Stefan claims. Instead, Data INS followed by INS shuts off Data INS and restores the state to OVR.
I was unable to perform any combination of Data INS and normal INS that caused any malfunction. AFAICT, there is no bug.
|
|
|
Post by Robert on Jan 25, 2023 12:32:16 GMT -5
The problem about changing it, is that if you're writing a keyboard macro, and you want to properly save and restore the insert state, you don't know what the prior state is.
Say you have insert OFF first, and your macro needed insert to be on.
If the macro did INSERT ON, DO SOMETHING, INSERT OFF
that would be fine. If insert were ON beforehand, the macro would "work" but now the prior ON state has be changed to OFF, when you didn't want that to happen.
The goal in all this is to prevent a macro from altering the "prior state". You want the macro to go in, "do something" and get out, without interrupting what the user was doing previously.
The design of the existing functions already does that now, and it works. You should know; YOU wrote it.
I believe it is best to avoid over-thinking this. What was the original complaint?
"There is no primitive that simply turns OFF all Insert modes."
To fix the complaint without breaking what is there:
1. Leave all existing functions alone.
2. New function: (ClearInsert)
Let (ClearInsert) clear whatever is necessary to resolve the problem.
|
|
|
Post by Robert on Jan 25, 2023 12:23:42 GMT -5
If I were doing it, I would make a minor change to the line command parser, so that if the first character in it were = you would first pad it with a blank, so that the = would be treated like a 1-char name.
That way, you could say =NOTEPAD instead of = NOTEPAD
But, that's just me. It would definitely be a 'hack' and could have possible side effects. And, it's not totally necessary. As for EX/EXEC, that is something I would never use, given that I can now say =
|
|
|
Post by Robert on Jan 25, 2023 10:40:01 GMT -5
The functions internally save so that you don't need a separate step to save when you later restore, because the restore function has no way to know if a prior save was done or not. The way it works now, you can safely restore without risking a "restore has no data to restore" trap. This is not a zoo. It was intentional. If you change things you will break this behavior.
As the developer, if you wish to break it, that's up to you. Be forewarned, that's all.
|
|
|
Post by Robert on Jan 25, 2023 10:14:36 GMT -5
I believe the problem stems from this line in the Change Log:
"SPFLite will invoke the command and add the fully quoted filename from the selected FM line."
The only way I know to SELECT a line in FM is to put an S on it. That leaves EXEC as a primary command.
The word "Line" that precedes all this got glossed over in the shuffle.
Sorry for the confusion.
|
|
|
Post by Robert on Jan 24, 2023 16:22:41 GMT -5
I am sorry my explanation was lacking, but that's really all I can tell you. I tried EX NOTEPAD and put an S on a line of a text file in FM, and pressed Enter. Nothing happened. Utterly nothing. It acted like I didn't do anything. Sorry. That's it.
When I tried EX alone, it issues a complaint about EXCLUDE needs 1 parameter. You created a name class clash with EXEC because both it and EXCLUDE have EX as abbreviations.
As for why it failed? No idea. There is nothing more I can say, except that when I made my macro and tried to run Notepad++ it didn't work, but at least I got an SPF_exec error. That was because the directory for NotePad++ was not in the Windows PATH.
|
|
|
Post by Robert on Jan 24, 2023 14:21:59 GMT -5
This macro can be used to directly execute a command from an FM line, such as NOTEPAD In the line command area, type this: = NOTEPADThere must be a blank between the initial = and the Windows command name. The name is any simple name that you could type on a Windows command line. For existing commands that won't currently run on a Windows command line, you may need to update your system environment variable PATH to include the path of your desired command. To make this work, the macro has the actual file name of =.MACROWhile this is a very unusual file name, it seems to work fine. In this post, the file is called " attachment.macro" because the forum doesn't know quite what to do with the name =.MACROAfter you download this file into your MACROS directory, you must RENAME it to the unusual name of =.MACRONote: A correction was made; I should have called SPF_Shell rather than SPF_Exec. Let me know if you find any issues with this macro. It seems to work, but it's hot off the presses. Attachments:attachment.macro (798 B)
|
|
|
Post by Robert on Jan 24, 2023 11:01:10 GMT -5
I believe the EX/EXEC function could be implemented as a macro, except that most FM functions that are needed require an "FNum" argument to specify the line number within the FM display, but I cannot find a function to get an FNum when an FM line-command macro is executed. All the FM macro examples show a loop from 1 to FMGet_Count.
|
|
|
Post by Robert on Jan 24, 2023 9:55:37 GMT -5
As a new user you may not have run into this yet, but PROFILE USING has been replaced by a thing called EFT, which means Extended File Types.
Issue a primary command of HELP EXTENDED for more information.
|
|
|
Post by Robert on Jan 24, 2023 9:51:38 GMT -5
I am not sure if my suggestions are in demand, but it seems to me that there is an easier way to accomplish this. There is nothing to prevent a Windows command from being typed in the line command area. If you wanted to apply a command to a file in the FM, I see two ways of doing this:
1. Allow the windows command to be typed directly. So, if I wanted NOTEPAD.EXE to be run, that's exactly what you would type in the line command. It would be necessary to look for the extensions that are considered "commands". A complete list of these can be found from the ASSOC windows command. But, it's a long list.
2. Adopt a convention that a command ending in some special character means to run an external command with that name. Suppose that character were the = sign. Then, if I wanted to run NOTEPAD, I would type NOTEPAD= in the line command. (Using =NOTEPAD would also work.) Right now, if I do this, I just get "invalid command" from SPFLite. This has the advantage that you don't need to say EXE, BAT or anything else, you would internally just run the command and let Windows figure out what the application is, somewhat similar to how the SPFLite command RUN works.
|
|
|
Post by Robert on Jan 23, 2023 14:47:59 GMT -5
The change log for 23.019 shows,
"Add a new FM Line Command - EXEC / EX. This command requires a single operand, the name of a normal system command, BAT file or program. SPFLite will invoke the command and add the fully quoted filename from the selected FM line. e.g. EX NOTEPAD would open the selected file in the NOTEPAD editor."
This does not appear to work.
I am sure you can resolve this.
|
|