...toggle between two different keymaps

Benjamin, many MANY moons ago, I used VI for a brief time. Bear in mind that my attitude about VI is very negative, I will try to give you as good an answer as I can.

SPFLite does not operate in "modes" as VI does. That is because VI processed a stream of characters from stdin, while SPFLite works in true full-screen mode. There is no way to "condition" a command based on a "mode". There are no "conditions" or "predicates" within the command structure, and no modes defined that you are trying to simulate.

What you are suggesting to do is kind of like getting SPFLite and trying to turn it into VI. I would strongly recommend against it, especially since you are brand new to the editor. It would be much better if you would take some time to understand the rationale for how it works. In the beginning of the Help document, there is a link to the main IBM document that explains how mainframe ISPF works. Try looking through that. We did everything we could to make SPFLite work like ISPF, as much as possible. After that, we modified the design to do some things better than IBM did, and after 15+ years, it's pretty good. I would say, try it first for what it is.

As for "toggling", when you are in the data part of the screen, that's "data mode". If you want to "toggle to primary command mode", just press the Home key and type a primary command like FIND and press Enter. (But, "Enter" is often assigned to the right Ctrl key, for 3270 compatibility).

To "toggle to line command mode", move the cursor left to the "line command area" where you can type things like D for delete, R for repeat, C for copy, A or B for copying after or before some line, etc.

There are a lot of commands. They are divided into primary, line and keyboard-primitive. The primitives and the KEYMAP command allow you to tailor how the low-level behavior of each key operates. KEYMAP is very powerful and flexible.

Take some time, get to know the beast you're riding on.

R

Robert and George,

Thanks for the advice. It's only been a day or two. I'm still trying to wrap my head around everything. I didn't realize the Home key would take me back to the command prompt.

I did download the IBM document. I'd be glad at this point if I could just figure out how to add a new line to the bottom of a file.

Cheers!

OK, I tried I003. It worked. Mind blown.

I see in the manual that the "I" is a line command. I'm used to thinking in terms of operating on lines, since I've used "ed" a fair amount. It's just this interface is SO different. It's like I've gone to an alternate universe where the laws of nature are different.

Cheers!

Benjamin

Benjamin, I realize I didn't answer your first question about toggling between two keymaps.

The short answer is you can't, not directly. The longer answer is that you can define what are called Instances. Each unique instance has its own name and can have its own keymap and other important resources. You can switch between instances, and that would be a way of toggling between kepmaps.

However, as a long time user, I can tell you I have never felt a need to establish two different keymaps and switch between them. To me, the idea of having two different, inconsistent keyboard layouts seems like a very confusing arrangement. I might try it as an experiment, just to see if it could be done, but I would never run it like that on an ongoing basis. It would just seem very strange to me.

R

George, I've had an idea for a while, which I would call "conditional keymaps". The idea would be that you'd have (if), (else) and (endif) primitives, and then a set of testable conditions that would return true or false. Based on that, either the (if) clause or the (else) clause would get executed.

It's not a full-blown idea right now, just something to hold up as a concept. But, if you ever did a thing like that, it would be a means to toggle some kind of internal condition that could be tested in a conditional keymap like that.

R

I think that cramming it in would be easier than deciding on conditions that were important enough to justify it in the first place. That's why I said it was a concept, not a full blown idea.

Perhaps in an actual VI-style editor, that is treating the keyboard as a stream of data and commands all intermingled, the keyboard toggling idea might make sense, but since SPFLite just doesn't do anything of the sort, the justification for it is limited.

Maybe something that might have some limited use would be temporary keymap assignments. Suppose you wanted a keymap setting changed, but it was only for testing purposes. If assignments could be made temporary, they could be discarded at shutdown. Now, yes, you could set up an elaborate CFG maint process to save and restore the keyboard, but that would involve quite a bit of complications.

Anyway, this is all just spinning wild ideas based on Benjamin's initial post. You have to be able to come up with crazy ideas, so that you feel free to create good ones too.

R

Yes, and you can see how much of his philosophy was shaped by vi, emacs and vim. All those editors were based on the "terminal" interface. First, teletypes, then VT-100 screens which were really just "glass-TTY" devices. When you come from an IBM 3270 full-screen device, where the normal mode was transmission of entire screens, everything is different. That is what SPFLite is modelled on. We even recently added support for a PA1 key, to magically "undo" typing the way a real 3270 does. None of that fits into "modal" keyboard behavior.

As George asked me above, there might be a tiny window where keyboard processing might utilize modes or conditional operation, but the big question is why? What are you hoping to operate in various "modes"? Adding something like that into what we have now would be really hard. Like George always asks me, what does it buy you? And, what does it do that we don't have right now?

You are early in your learning curve, so before asking for a structural change like that, you really need a good handle on what we have now.

One thing that I thought about as I remember my use of VI, is that it forces its users to "think small". In contrast, much of what SPFLite does is "thinking big". Here are some SPFLite examples of thinking big:

Multi Edits
Power Typing
thinBasic macros operating in File Manager (FM) mode
interaction of Profiles with Extended File Types (EFT)
Split and Join
Submit
XFORMS

I'd say, you need to get the really BIG picture of SPFLite, first. Get comfortable with what it can really do, which is lot. Once you do, you may give up ideas about keyboard modes.

Robert