Guru: Ready Or Not, Big Changes in RDi V9.6! Part 1, Key Behavior
February 26, 2018 Susan Gantner
Version 9.6 of RDi has many new features. If you’ve upgraded your RDi, you have undoubtedly noticed some of the enhancements, because most of the new features are enabled by default. Just in case you’re not a huge fan of some of those features, most can also be disabled to make things work as before if you know where to look.
In this series, we’ll take a look at some of the new features and how to enable and/or disable them. In this first part, we’ll study two new key behaviors and how to control them.
Many of the enhancements we’ll talk about here are related to RPG IV, or as RDi prefers to call it, ILE RPG. So many new features were added that a new preference page was added since the base ILE RPG preference page was getting pretty long! The new Key Behavior preference page has become the home for some preferences previously found on the base ILE RPG page, as well as some of the new features in V9.6. Looking at the image of that page below, you’ll already get some good hints as to some of the new features, especially since I’ve highlighted them. The image shows the default preferences for key behavior — not my own personal preferences.
As you can see, the two new key behaviors relate to new behaviors for the Enter and Tab keys, both of which are enabled by default.
Enter Key Behavior
In free-form RPG code only, the Enter key will now by default split the line at the current cursor position, much as the Alt-S shortcut did in the past. It’s not identical to the Alt-S behavior in that the subsequent positioning of the code on the line below is different, either with or without the preference above this one enabled. I think the new behavior comes much closer to the positioning I really want for the second line — indented slightly under the first non-blank character on the first line. The amount of indentation used is controlled by the preference on the Formatter preference page – Number of spaces to indent by. In case you missed it, the Formatter preference page appeared back in V9.5 in support of the option to format (or re-format) any free-form RPG code.
Personally, I really like the new Enter key default behavior. It only took me a little while to get accustomed to it, although I should confess that I still occasionally forget, accidentally splitting a line with the Enter key when I just meant to get a new line but I wasn’t positioned at the end of the line. Then again, the new behavior is certainly more in line with how most other editors, such as Word and Pages, work.
One thing to keep in mind is that this new behavior doesn’t work everywhere. Remember that it’s an ILE RPG preference, so don’t expect it work in CL, for example, even though CL has always been free format. Even in RPG, it only works on free-format lines of code, so if you’re working on code that isn’t free-format yet—such as some older D specs that haven’t been converted or even (shudder!) some old fixed-format logic.
This new Enter Key support currently doesn’t seem to work inside embedded SQL statements, even when they are embedded into free-form source. I’m not sure whether this is a bug or if it is considered to be “working as designed.” Either way, hopefully it is something that we may see enabled later on.
Tab Key Behavior
The new default behavior for the Tab key is to insert spaces, effectively shifting the code to the right. Shift+Tab will remove spaces, shifting to the left. As the preference page says, the number of spaces to be inserted on each tab is controlled by the “Number of spaces to indent by” setting on the Formatter preference page, just as the split via the Enter key is.
As with the new Enter key split, this only works with free-form RPG source, and its behavior is sensitive to cursor position, at least most of the time. For example, if you position your cursor immediately after the field name on a Dcl-s statement and press Tab, the field name (to the left of my cursor) remains in place while the data type and other keywords (to the right of my cursor) are shifted the appropriate number of spaces right. Positioning on/immediately before the Dcl-s, the whole statement is shifted right. However, if I position somewhere in between the far left margin (just after the sequence number) and the beginning of the Dcl-s, the first tab simply moves the cursor to the first non-blank character on the line – i.e., no code is shifted. A second tab at that point will shift the code right, of course.
Interestingly, the Shift+Tab (shift left) behavior doesn’t seem completely consistent with the Tab (shift right) behavior. As mentioned above, I can position my cursor in the middle of some code on a line and the tab key will shift only the code to the right of my cursor. However, a Shift+Tab seems to always shift the entire line of code to the left regardless of my cursor position.
Another interesting difference: If you are not in a **Free member — meaning that your code must be coded within columns 8 to 80 — Shift+Tab will not shift your code any further right than column 80. However, Tab doesn’t stop shifting code right when it hits column 80. Perhaps some of the inconsistencies about tabbing will be changed in the future.
So far the behavior I’ve been describing is using the Tab or Shift+Tab without any code selected. But this new tabbing support is even more useful when a block of code is selected. If I select, for example, 10 lines of code, either by dragging my mouse over the block or by using Alt-L on the first and Alt-L again on the last line of code in the block, then the Tab key shifts all the lines in the block to the right. This can be useful if you’re about to add another level of nested logic and you want to shift some existing code right (or left with Shift+Tab) to make room for the new indentation level. I did this in the past by selecting a block of code with the Alt+L technique mentioned above and using Alt+F8 (shift right) or Alt+F9 (shift left). The new support is nicer, not only because it’s much easier to remember, but also because it works regardless of how I select the code block.
Now you know how these two new key behaviors work. But remember that if you prefer things to work the way they did before, you can always disable one or both of these features on the preference page. Don’t forget that you can also control the number of spaces inserted by Tab in preferences as well.
Next time, I’ll look at some other features in V9.6, such as new hover information and various new annotation features. As I did here, I’ll also tell you which features are enabled by default. (Spoiler Alert: not all of them are). And I will tell you how to turn them on or off. (Spoiler Alert: Not all of them can be turned off).
RELATED STORIES
Guru: Confessions Of A Recovering RDi Outline Addict
Guru: How Do You Do That With RDi? Part 3: Complex Compiles
Thank you for this, we are the process of upgrading from 9.5 to 9.6 and these articles are very informative. I look forward to the next