idlwave: Troubleshooting
Appendix E Troubleshooting
**************************
Although IDLWAVE usually installs and works without difficulty, a few
common problems and their solutions are documented below.
1. *Whenever an IDL error occurs or a breakpoint is hit, I get errors
or strange behavior when I try to type anything into some of my
IDLWAVE buffers.*
This is a _feature_, not an error. You’re in _Electric Debug Mode_
(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.
2. *I get errors like ‘Searching for program: no such file or
directory, idl’ when attempting to start the IDL shell.*
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.
3. *IDLWAVE is disregarding my ‘IDL_PATH’ which I set under macOS*
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.
4. *I get errors like ‘Symbol's function is void: overlayp’*
You don’t have the ‘fsf-compat’ package installed, which IDLWAVE
needs to run under XEmacs. Install it, or find an XEmacs
distribution which includes it by default.
5. *I’m getting errors like ‘Symbol's value as variable is void:
cl-builtin-gethash’ on completion or routine info.*
This error arises if you upgraded Emacs from 20.x to 21.x without
re-installing IDLWAVE. Old Emacs and new Emacs are not
byte-compatible in compiled lisp files. Presumably, you kept the
original .elc files in place, and this is the source of the error.
If you recompile (or just "make; make install") from source, it
should resolve this problem. Another option is to recompile the
‘idlw*.el’ files by hand using ‘M-x byte-compile-file’.
6. *‘M-<TAB>’ doesn’t complete words, it switches windows on my
desktop.*
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>’.
7. *When stopping at breakpoints or errors, IDLWAVE does not seem to
highlight the relevant line in the source.*
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.
8. *IDLWAVE doesn’t work correctly when using ENVI.*
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’ (Starting the Shell), e.g.,
in your ‘.emacs’:
(setq idlwave-shell-prompt-pattern "^\r? ?\\(ENVI\\|IDL\\)> ")
9. *Attempts to set breakpoints fail: no breakpoint is indicated in
the IDLWAVE buffer.*
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>’.
10. *I installed a new version of IDLWAVE, but the old version is
still being used* or *IDLWAVE works, but when I tried to install
the optional modules ‘idlw-roprompt.el’ or
‘idlw-complete-structtag’, I get errors like ‘Cannot open load
file’*.
The problem is that your Emacs is not finding the version of
IDLWAVE you installed. Many Emacsen come with an older bundled
copy of IDLWAVE (e.g., v4.7 for Emacs 21.x), 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.
11. *IDLWAVE is screwing up the formatting of my ‘.idl’ files.*
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)
12. *The routine info for my local routines is out of date!*
IDLWAVE collects routine info from various locations (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.
13. *All the Greek-font characters in the HTML help are displayed as
Latin characters!*
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: HTML Help Browser Tips.
14. *In the shell, my long commands are truncated at 256 characters!*
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’).
15. *When I invoke IDL HTML help on a routine, the page which is
loaded is one page off, e.g., for ‘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.
16. *I get errors such as ‘void-variable browse-url-browser-function’
or similar when attempting to load IDLWAVE under XEmacs.*
You don’t have the ‘browse-url’ (or other required) XEmacs package.
Unlike Emacs, XEmacs distributes many packages separately from the
main program. IDLWAVE is actually among these, but is not always
the most up to date. When installing IDLWAVE as an XEmacs package,
it should prompt you for required additional packages. When
installing it from source, it won’t and you’ll get this error. The
easiest solution is to install all the packages when you install
XEmacs (the so-called ‘sumo’ bundle). The minimum set of XEmacs
packages required by IDLWAVE is ‘fsf-compat, xemacs-base,
mail-lib’.