VPE v15.1

Install Instructions (first time)

Load the .RSA file into your M implementation, and run ^XV.

Upgrade Instructions (from v13-14)

If you are upgrading from v13-14, and have saved user QWIKs, you need to follow the following instructions:

1. Make sure all users have halted off VPE Shell
2. Merge User QWIKS and IDs from ^XVEMS("QU") and ^XVEMS("ID") to a scratch global
3. Delete routines XVEM*, XVS*, XVVM*, and XV
4. Kill global ^XVEMS
5. Load VPE_XXPX.RSA routines from the disk
6. Do ^XV to install and start VPE
7. Merge Saved user QWIKS and IDs from scratch global to ^XVEMS("QU") and ^XVEMS("ID")
8. Run ..PARAM to adjust your parameters if you wish

Upgrade Instructions (from v12 and earlier)

1. Load the .RSA file
2. Run ^XV
3. At the MUMPS prompt (not while in VPE) enter the following:

M ^XVEMS("ID")=^%ZVEMS("ID")
M ^XVEMS("QU")=^%ZVEMS("QU")

You can still run the old VPE v12 using X ^%ZVEMS; as the new VPE runs in a different namespace.

Authors for version 15.1

Sam Habiel (SMH) & David Wicksell (DLW)

Changes for version 15.1

Changes with * have Integration Tests.

• Code to save routines is now VPE's own built in code. Previously code to save
  routines was obtained from Fileman if it is installed. This was found because
  Fileman had a bug in saving % routine on GTM/YDB. Use of Fileman in preference
  to VPE is not in accordance with VPE's VistA indepdendent philosophy.* (DLW)
• Due to a bug in how a logical condition apropos De Morgan's Law, ZLINK was
  not invoked on GTM/YDB when saving a routine. This bug was introduced in
  v13.0; the code was correct in v12 (the pre-XV version).* (DLW)
• If a routine contained over 999 lines, the line counter at the top didn't
  show the number correctly. This is now fixed.* (test not active as it takes
  too long to run) (DLW)
• Syntax highlighting parameters have been improved: ESC key aborts changes;
  selected colors can be seen in real time while selecting them.* (DLW)
• Parameter selection for width and height are limited at the lower bound of
  80 x 24 as the routine editor is glitchy with a lower selection.* (DLW)
• Previously VPE had a facility for automatically stripping spaces, but only
  when the backspace key was pressed. This interfered with Syntax Highlighting;
  so this feature was removed; this aside from the fact that this behavior is
  very counterintuitive and undocumented. Future enhancements may add stripping
  of trailing spaces when saving a routine. (DLW)
• General improvements to Syntax Highlighting code introduced in 15.0. (DLW)
• New features and bug fixes of ESC-G to from 14.0: (SMH)
  • As previously ESC-G at ^ will get you the full global reference until the
    ending parentheses.*
  • ESC-G at the opening parentheses will display the global data under the
    global name only.*
  • ESC-G at any comma of the subscripts will get you the global up to the
    subscripts before the comma.*
  • Fixed help text for ..E/..VRR to describe how to use ESC-G with these
    changes.
  • (bug fix): ESC-G resolves $ expression (ISVs, intrinsic functions, or
    extrinsic functions) inside of global references. $J is kept, anything
    else is discarded.*
  • (bug fix): Expressions with nested parentheses inside a global reference
    (e.g. $P($G(RXFL(RX)),"^",0)) are discarded correctly.*
  • In all the above cases, ESC-G tries to substitute any expressions or
    variables (with the exception of $J as mentioned above) with the
    continuation character (:) when sending the input into ..VGL.*
• Removed upper limit on ID. Previously, in VistA instances such as the CPRS
  Demo (aka VEHU), you couldn't log-in with users with DUZ in the billions
  because VPE did not allow that. Fixes Issue #23.* (SMH)
• Upgrade and Uninstall instructions printed to the user upon installation were
  not correct. They are now fixed. (SMH)
• Tell user about old VPE if it is installed during installation.* (SMH)
• Branched to routines didn't ZLINK when saved because they did not use the
  correct entry point for saving. This is now fixed.* (SMH)
• Prevent ESC-ESC from exiting the routine save dialog. This is contrary to
  VPE philosophy, where all dialogs are escapable using ESC-ESC. However, in
  this specific case, many new users held the ESC key for too long when trying
  to save a routine, with the result that they lost the routine when they
  escaped from the save dialog. Fixes Issue #29.* (SMH)
• Remove VGL/VEDD drill down restriction. If you invoke VGL or VEDD from the
  Menubar from ..E/..VRR after having branched down two routines, you were
  prevented. Fixes #39. (SMH)
• In VGL, display global references being shown next to the session number; and
  show the global if we are telling the user that there is no data. These
  improvements were made to address the fact that ESC-G in the routine editor
  auto-resolved what global it was by substituting variables, but it was not
  obvious to the end user what did ESC-G finally select as the global to
  search.* (SMH)

Notes from DLW regarding Syntax Highlighting and catching errors in code:

I made a decision not to try to catch every error, but just the main, obvious
ones, and only if I could do so without significantly complicating the code.

With this code, I have to balance how strict the parsing is, with
performance. If I add really strict parsing logic, and try to make it
into basically a reference grammar parser for MUMPS, then it probably
will not run fast enough for an editor. That's not to say that making it
much more strict, and keeping good performance is impossible, just that
it would be hard.

For example, I chose to be pretty strict with commands, so that it is
good about flagging errors for commands that don't exist (except for
ones that start with a Z, which I basically leave alone). But, for
intrinsic functions and ISVs, I didn't do that. It only checks to make
sure they follow the rules for identifiers from the standard, but not
that they are a function or ISV that exists. I was planning a future
upgrade to improve the error highlighting of the code, but wanted to get
something out there that was useful, and performed well enough that
people would enjoy using it.

So, to summarize, the syntax highlighter should always color all
syntax elements correctly, and it should never flag as an error, valid M
syntax (all bets are off if you use ISC extensions like COS). But it
isn't going to catch every error, though I'm hoping to improve that over
time. So if you try to abuse it, you'll be able to find
less-than-perfect results.