Although IDLWAVE usually installs and works without difficulty, a few common problems and their solutions are documented below.
This is a feature, not an error. You’re in Electric
Debug Mode (see Electric Debug Mode). You should see
*Debugging* in the mode-line. The buffer is read-only and all
debugging and examination commands are available as single keystrokes;
C-? lists these shortcuts. Use q to quit the mode, and
customize the variable idlwave-shell-automatic-electric-debug
if you prefer not to enter electric debug on breakpoints… but
you really should try it before you disable it! You can also
customize this variable to enter debug mode when errors are
encountered.
IDLWAVE needs to know where IDL is in order to run it as a process.
By default, it attempts to invoke it simply as ‘idl’, which
presumes such an executable is on your search path. You need to
ensure ‘idl’ is on your ‘$PATH’, or specify the full
pathname to the idl program with the variable
idlwave-shell-explicit-file-name. Note that you may need to
set your shell search path in two places when running Emacs as an Aqua
application with macOS; see the next topic.
If you run Emacs directly as an Aqua application, rather than from the console shell, the environment is set not from your usual shell configuration files (e.g., .cshrc), but from the file ~/.MacOSX/environment.plist. Either include your path settings there, or start Emacs and IDLWAVE from the shell.
Your system is trapping M-TAB and using it for its own nefarious purposes: Emacs never sees the keystrokes. On many Unix systems, you can reconfigure your window manager to use another key sequence for switching among windows. Another option is to use the equivalent sequence ESC-TAB.
IDLWAVE scans for error and halt messages and highlights the stop location in the correct file. However, if you’ve changed the system variable ‘!ERROR_STATE.MSG_PREFIX’, it is unable to parse these message correctly. Don’t do that.
Though IDLWAVE was not written with ENVI in mind, it works just fine
with it, as long as you update the prompt it’s looking for (‘IDL>
’ by default). You can do this with the variable
idlwave-shell-prompt-pattern (see Starting the Shell), e.g.,
in your .emacs:
(setq idlwave-shell-prompt-pattern "^\r? ?\\(ENVI\\|IDL\\)> ")
IDL changed its breakpoint reporting format starting with IDLv5.5. The first version of IDLWAVE to support the new format is IDLWAVE v4.10. If you have an older version and are using IDL >v5.5, you need to upgrade, and/or make sure your recent version of IDLWAVE is being found on the Emacs load-path (see the next entry). You can list the version being used with C-h v idlwave-mode-version RET.
The problem is that your Emacs is not finding the version of IDLWAVE you installed. Emacs might come with an older bundled copy of IDLWAVE which is likely what’s being used instead. You need to make sure your Emacs load-path contains the directory where IDLWAVE is installed (/usr/local/share/emacs/site-lisp, by default), before Emacs’s default search directories. You can accomplish this by putting the following in your .emacs:
(setq load-path (cons "/usr/local/share/emacs/site-lisp" load-path))
You can check on your load-path value using C-h v load-path RET, and C-h m in an IDLWAVE buffer should show you the version Emacs is using.
Actually, this isn’t IDLWAVE at all, but ‘idl-mode’, an unrelated programming mode for CORBA’s Interface Definition Language (you should see ‘(IDL)’, not ‘(IDLWAVE)’ in the mode-line). One solution: don’t name your file .idl, but rather .pro. Another solution: make sure .idl files load IDLWAVE instead of ‘idl-mode’ by adding the following to your .emacs:
(setcdr (rassoc 'idl-mode auto-mode-alist) 'idlwave-mode)
IDLWAVE collects routine info from various locations (see Routine Information Sources). Routines in files visited in a buffer or compiled in the shell should be up to date. For other routines, the information is only as current as the most recent scan. If you have a rapidly changing set of routines, and you’d like the latest routine information to be available for it, one powerful technique is to make use of the library catalog tool, ‘idlwave_catalog’. Simply add a line to your ‘cron’ file (‘crontab -e’ will let you edit this on some systems), like this
45 3 * * 1-5 (cd /path/to/myidllib; /path/to/idlwave_catalog MyLib)
where ‘MyLib’ is the name of your library. This will rescan all .pro files at or below /path/to/myidllib every week night at 3:45am. You can even scan site-wide libraries with this method, and the most recent information will be available to all users. Since the scanning is very fast, there is very little impact.
Unfortunately, the HTMLHelp files RSI provides attempt to switch to ‘Symbol’ font to display Greek characters, which is not really an permitted method for doing this in HTML. There is a "workaround" for some browsers: See HTML Help Browser Tips.
This actually happens when running IDL in an XTerm as well. There are
a couple of workarounds: define_key,/control,'^d' (e.g., in
your $IDL_STARTUP file) will disable the ‘EOF’ character
and give you a 512 character limit. You won’t be able to use
C-d to quit the shell, however. Another possibility is
!EDIT_INPUT=0, which gives you an infinite limit (OK, a
memory-bounded limit), but disables the processing of background
widget events (those with /NO_BLOCK passed to XManager).
CONVERT_COORD, I get
CONTOUR.
You have a mismatch between your help index and the HTML help package you downloaded. You need to ensure you download a “downgrade kit” if you are using anything older than the latest HTML help package. A new help package appears with each IDL release (assuming the documentation is updated). Starting with IDL 6.2, the HTML help and its catalog are distributed with IDL, and so should never be inconsistent.