|
Post by George on Jul 13, 2023 15:43:41 GMT -5
Robert: As I look further in this, it gets real murky. i.e. FM SELECT simply issues an internal EDIT command. So ... is this a generic EDIT or a specific EDIT command. The EDIT command processor will indicate it's a specific EDIT command, which will probably override the SELECT command saying it's generic. But it IS a generic EDIT. Right now I've no idea how to cope with this.
We have a higher level command issuing a lower level command, and each will try and say "I'm the guy issuing the command", but the lower level guy will win. This is a real problem, and it's not simple to overcome.
I don't want functions like FM SELECT to have to basically duplicate what EDIT/BROWSE/VIEW do so that they don't 'lose' their originator-of-the-request status. This ain't easy.
George
|
|
|
Post by Robert on Jul 13, 2023 16:28:44 GMT -5
Yes, and that is a key part of the idea. In the past, Select and Edit were identically the same thing for a data file. Under the new concept, they are not.
This won't really work unless you can "dis-unify" them, in Unicode parlance. They have to be different, otherwise there is no way to apply (or not apply) the EFT override for MODE.
I don't *think* that SELECT should or needs to "duplicate" anything. All it should be doing is (I believe):
1. "Pretend" you are doing an Edit, but remember (somewhere) the actual command was select.
2. Go through the normal motions of Edit. During that process, you must determine any MODE in effect from either EFT or from the Profile, or else assume MODE EDIT.
3. When the edit session is about to begin, you check the actual command that you remembered in step 1. If it is Select, and there is a MODE in affect, apply it. That could change the running mode of an Edit to Browse or View.
As far as higher vs. lower levels of commands, I am not sure I understand what you mean, with me not knowing the internals. Maybe you could explain it, so that I don't get carried away making dumb-ass suggestions.
Ditto about the "generic" edit. I suspect you don't actually need to deal with a "generic" state of an Edit. Use a REAL one, yet keeping in mind that you might need to change the final running mode to something other than Edit at the very last moment.
R
|
|
|
Post by Jo on Jul 14, 2023 8:17:59 GMT -5
I'm late with my comments, but I will like the proposed enhancements.
Line numbers: Were very useful when I had to move files from and to the mainframe, but now I don't use it anymore. MODE switching: I would like to have a MODE switching command. I often open some include-files just for reference, so I use VIEW or BROWSE for all of them, to not accidentally change anything. But sometimes I see a typo or other error in one of them. In this case it would be fine to change to EDIT, correct & SAVE, and change back to BROWSE. FM DEFAULT: I rarely used it, but sometimes its very useful (DEFAULT W Notepad). And I wonder if dropping the FM DEFAULT would be helpful in then E/B/V-Profile determination ? EFT Syntax: I don't care. Currently I have just 6 simple EFT-Entries, but I will use it much more as soon the new parms are available. I'm prepared for a complete rewrite. AUTONAME: I extensively use autocolorization for a lot of different filetypes, all of them are ASCII-Text-Files with common profile values. That would reduce my profiles a lot. But it will not be " The end of profiles as we know them.", there are still different Tabs and Column Markers.
Finally I want to thank you all for still enhancing this great product. Jo
|
|
|
Post by George on Jul 14, 2023 8:38:41 GMT -5
Jo: Appreciate all your comments.
Robert: As to 'levels' of commands. That's where command "A" (actual command line type) does something and then passes off processing to another command internally. e.g. SET and EFT, which setup things and pass off to CLIP to load and edit the data. Or DIFF which also uses the PASTE command to load the final report. Or FM SELECT handing off to EDIT/VIEW/BROWSE. It gets tricky.
George
|
|