From: Peter G. <pe...@ar...> - 2002-08-01 18:06:44
|
This morning's 0.16.1+ development snapshot is up: http://armedbear.org/j.zip (source and documentation) http://armedbear.org/j-jar.zip (just j.jar) This snapshot introduces three new commands in C and C++ modes, one of which (iList) is a killer. These commands were inspired by similar features by Bram Moolenaar in vim, although j's implementation is quite different internally. Since the beginning of time, j has supported the concept of an include path for C and C++ modes. The idea is, you add lines like these to ~/.j/prefs: CMode.includePath =3D ../include:\ /usr/include:\ /usr/lib/gcc-lib/i386-linux/2.95.4/include CppMode.includePath =3D /usr/include:\ /usr/lib/gcc-lib/i386-linux/2.95.4/include:\ /usr/include/g++-3 Then, when you're working on a C file (for example), you can enter "stdarg.h" in the location bar, without any path prefix at all, and j will look in the C mode include path and find the file you're looking for, which is /usr/lib/gcc-lib/i386-linux/2.95.4/include/stdarg.h. If your include path is set up correctly, you can also put your caret anywhere at all on the line: #include <stdarg.h> and use gotoFile (Ctrl Shift G) to open stdarg.h in the aforementioned location, with no actual typing whatsoever. The new commands checkPath and listIncludes help you verify that you have your include path set up correctly. The command checkPath, not mapped by default but available via executeCommand (Alt X, "checkPath"), looks at all the #include lines in the current buffer and reports which included files can't be found in your include path (or in the current directory, if the filename is enclosed in quotes rather than in angle brackets). checkPath also recursively checks all the included files that it can find, and reports which (if any) of the files included by those files can't be found. listIncludes (Alt X, "listIncludes") is similar to checkPath, but it lists all the included files, not just the ones that can't be found. iList, mapped by default to Ctrl F6 in C and C++ modes, operates on the identifier at the current location of the caret. It creates a List Occurrences output buffer showing all occurrences of the identifier in question in the current buffer AND in any included files, in the order in which they occur. So, to take an example from the Linux kernel source, suppose your C mode include path is set up as in the example above and you're looking at this line in sched.c: #define MIN_TIMESLICE ( 10 * HZ / 1000) And you wonder what "HZ" is. If you put your caret on "HZ" and hit Ctrl F6, you'll get a List Occcurrences buffer that starts like this: Pattern: "HZ" Options: case sensitive, whole words only File: /usr/src/linux-2.4.19-pre10-ac2-A4/include/linux/sched.h 4:#include <asm/param.h> /* for HZ */ File: /usr/src/linux-2.4.19-pre10-ac2-A4/include/asm-i386/param.h 4:#ifndef HZ 5:#define HZ 100 =46rom which you can see that HZ is 100, as defined on line 5 of param.h.= The nice thing about iList is that all you have to do is set up your include path correctly. Without iList, you'd have to do the equivalent of grep in each of the directories in question, and then you still wouldn't be sure, since grep might find occurrences of the search string in files that your source file doesn't actually include. And without an automated tool like ilist (or listIncludes), it's often hard to see what files a source file does include, because include files tend to include other include files: Great fleas have little fleas upon their backs to bite 'em, And little fleas have lesser fleas, and so ad infinitum. [1] The new commands have one important limitation (shared by grep): they pay no attention to #ifdefs, so some of the included files that show up in the output lists may not actually be relevant to what you're doing because they may be excluded, in your compilation environment, by #ifdefs that j ignores. For this reason, the list that j gives you is likely to be a superset of the "real" list for your compilation environment. (But it should never be a subset.) As a concrete example, if you're looking at cross-platform source, checkPath will often complain that it can't find platform-specific system headers that might be required for a platform other than yours ("os_os2_cfg.h", for example). For this reason, iList silently ignores included files that are not present in your include path. checkPath and listIncludes still need a bit of work. In particular, you can't do much with the output buffers they generate. It would make sense to map Enter to some command that jumps to the corresponding location in the relevant included file, but that's not done yet. And I'm not entirely sure about the syntax highlighting. Feedback is welcome. Thanks for your support. -Peter [1] Augustus De Morgan, A Budget of Paradoxes (1872). |