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 (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.

  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. 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.

  5. 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.

  6. 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 (see Starting the Shell), e.g., in your .emacs:

    (setq idlwave-shell-prompt-pattern "^\r? ?\\(ENVI\\|IDL\\)> ")
    
  7. 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.

  8. 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. 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.

  9. 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)
    
  10. The routine info for my local routines is out of date!

    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.

  11. 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: See HTML Help Browser Tips.

  12. 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).

  13. 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.