On Sat, 9 Aug 2014 13:29:32 -0700, Jon Perryman wrote:
>For edit macro's, placing the cursor at the end risks far less data than
>leaving the cursor alone. Right or wrong is a matter of opinion. Leaving the
>cursor at the current location will certainly teach programmers to check
>return codes and not make false assumptions the first time they destroy their
>data because they didn't check the return code.
>
A nonsensical argument. Carrying that reasoning to the extreme,
the safest thing to do on an unsuccessful search is to Cancel the
edit session leaving the file unchanged and data intact.
I suppose it's unfortunate that checking the return code is part of
the macro language rather than of the host environment. Otherwise
Edit could abort the macro if it issued another command without
extracting the return code.
(I'd imagine some syntax such as:
FIND Target Failure=failure-option
... where the default failure-option is CANCEL.)
And what you consider proper for a macro, I consider improper for interactive
editing. For interactive editing, I place a premium on economy of keystrokes
and hand motion. For example, ISPF Edit requires six keystrokes to search for
a comma; another editor I use needs only three. (To be fair, each requires
four to search for a period.) And rodent-oriented editors that pop up a dialog
box to do a search are dreadful.
Forget Case Insensitive Disambiguating Tables; forget lexical separation.
I'd welcome:
Instead of the terse
f 'Foo Bar'<ENTER> fFoo Bar<ENTER>
f c'Foo Bar'<ENTER> FFoo Bar<ENTER>
("f" means case-insensitive search; "F" case-sensitive.)
Interactive editing commands are not code; self-documentation
and comments are counterproductive; it's a motor skill.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
