On Tue, Mar 28, 2017 at 11:29 AM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:
On 3/27/2017 6:55 PM, John Yeung wrote:
It seems a little odd to me that this isn't one of the core,
streamlined, unclunky functions of a programmer's editor.
I apologise for being unable to be both clear and concise. I can often
get one, but it seems to be at the expense of the other.
I think you were sufficiently clear for readers who are RDi users.
I deliberately used the phrase 'seem a bit clunky' because many people
seem to have a mental bobble when trying to use RDi. In particular,
they expect RDi to act like Word, or some other Windows app. RDi is not
Word with an accent; it is its own unique, individual thing.
Well, I'll quibble with Word as the exemplar here, because
statistically no people use Word as a programming editor. But your
point is equally (or better) made inserting almost any programming
editor that runs in Windows. Perhaps most to the point: "many people
have a mental bobble when using RDi because they expect LPEX to act
like Eclipse's editor for Java".
I admit I'm in that group of people. I do keep forgetting that LPEX
has a long history. I also keep forgetting that people are going to
use RDi to work on whatever RPG code is on their system, and for a
very high percentage of RDi users, that is going to necessarily
include some fixed-format code, which by its nature isn't well suited
for the same editing techniques as typically used for C, Pascal, Java,
etc.
The editor almost necessarily is shaped by the language(s) it handles,
and since RPG is what it is, LPEX almost has to be what it is. I can
accept this.
RDi has several ways to select text.
Here is one area that I am not convinced has to be the way it is in
LPEX. I believe stream and line selection could be unified. So many
modern editors do it. Operations that only make sense in a line
context could simply apply as though the first and last lines of the
stream selection were extended to include their entire lines. The
editor version of automatic floor/ceiling, if you will.
Line Selection /is/ a regular selection.
Fine. Great, in fact.
To remove the selection, Alt-U
So, I take it you have to use Alt+U to remove a stream selection as
well, since it's really just the same kind of selection, arrived at
via different keys?
I think this is going to be an "ugh, clunk" for me no matter what the
answer is. If the answer is "yes, they both (because they are the same
thing) have to be canceled with Alt+U", then I am thinking it's a
shame that regular, Windows-style selection has an extra, unnecessary
step. (This is a similar feeling I get with the required semicolons
after the "if" or "else" line in free-form.)
If the answer is "no, line and stream selection are different after
all, but only one can be active at a time, and stream selection
doesn't require Alt+U" then I am thinking it's a shame that the two
selection modes aren't truly the same thing. But I think I prefer this
second answer, because it embraces and accentuates the difference
between line and stream, and smooths the workflow for stream selection
(which I suspect would overwhelmingly be the selection method of
choice for Windows natives).
This whole indentation selection thing... is this something that was
implemented specifically for RDi, or is this how it's done in Eclipse?
Javascript uses Ctrl-I to indent.
Unfortunately, you went deep into "too concise" territory there.
JavaScript is a programming language; it doesn't have any mandated or
default keybindings. So you must be talking about some editor which is
used to edit JavaScript code. Which editor would this be? The editors
*I* use all indent JavaScript the same way they indent C or Python or
plain English text: Tab to increase one indent level, Shift+Tab to
decrease one indent level.
Also, whichever editor this turns out to be, it misses the point. I'm
not so concerned about whether it's Alt+F7 or Shift+Tab. The phrase
"indentation selection thing" refers to the idea that indenting a
bunch of lines requires a different kind of selection than regular
stream selection.
Now, I have since learned that you were talking about "line selection"
and not some kind of special selection whose only purpose is mass
indentation. Fine. But you said the indentation function can only be
performed on a line selection, not a stream selection. Does this mean
that even if I'm careful to only select whole lines using nothing but
Shift and the arrow keys, mass indentation (via Alt+F7/F8) won't work?
If you were an Emacs-er on a Vim mailing list, you'd probably have as
many wonderments as you have on this one.
I get what you are trying to say. For me personally, it so happens I
used both Emacs and vi (though not Vim) heavily during my undergrad
years, so I wouldn't have a lot more wonderment on one list or the
other. I am not sure I was atypical, either. The Unix culture, at
least what I was exposed to in school, included the sense of "hey,
it's on your system - try it, learn it". So while there were a lot of
Emacs-vs.-vi feuds, they mostly came from genuine philosophical
differences rather than from ignorance. My wonderment on these lists
definitely has a large ignorance component. And unlike Emacs and vi,
RDi did not come preinstalled on my computer.
I'm a tad surprised though that an SEU user didn't suggest the RRnn
block command. Which work fine in RDi and always have. :-)
Dave Shaw did point this out in passing, inadvertently. He was trying
to say that the line-selection-indentation workflow in RDi is much
faster for him than the corresponding SEU commands. (He didn't mention
that you can use the SEU commands in RDi. This fact has come up from
time to time on this list, but not often enough to become entrenched
in my memory.)
But now that I've looked back to confirm it, I'm noticing he also said
something else: after selecting his lines, he uses Alt+Shift+arrow to
do the actual indenting, not Alt+F7/F8. Is this a built-in alternate,
or a custom keybinding? (This question is pure curiosity. I don't
think it would affect my opinion of RDi in any appreciable way.)
John Y.
As an Amazon Associate we earn from qualifying purchases.