On Wed, 16 Jun 1999, Paul Kinnucan wrote: > At 05:51 AM 6/16/99 +0000, you wrote: > >First off, my apologies for the previous message, I didn't look at the > >date I was replying to. > > > >Anyway, when I was browsing some java code today via JDE I noticed that > >getting API information is a real pain. So, in a few minutes I hacked > >together a couple of tools. These tools are truly hacks, based on high > >level integration, so they're not prime time material. > > > >The first, M-x jguess, guesses expansions for a class name. > > > >For example, when you see Vector v, you can select Vector and it will > >expand to java.lang.Vector (via a pipe from a java utility). It's not > >automatic and I don't know how to make it as such. > > > >Jguess is based on another posted java import tool. > > > > What tool? JDE 2.1.6beta1 has a built-in import tool that works as follows. > Position point in the name of the class you want to import, e.g., > > Vector v = new Vector(); > ^ > point Okay, I'm not up to 2.1.6beta1 yet, so I wasn't aware of this feature. There was a class import wizard posted on this newsgroup earlier, and I used it for this purpose. I'll check out the lisp tonight. > and then type C-c C-v C-z. The JDE creates the necessary import statement > in the "imports" section of the source file. Note that you do not have to > specify a qualified name. The JDE searches the classpath until it finds a > class of the specified unqualified name. If it finds more than one class, > it gives you a choice. This command uses the BeanShell and a Java-based > "wizard" to do its work. I like that approach, but for my purposes now -- reading and modifying java code, the imports have already been handled. I just need to tell where in the world "Thread" is in the API (which my help facility lended assistance to yesterday) > A Java help command could follow a similar approach. > >Then, I hacked a little tool called M-x jhelp... you select > >java.lang.Vector and it w3 browses in a buffer to the relevant page in the > >API. (based on URL concatenation, nothing fancy) > > > >Of course, it could work for "Vector" alone with a little modification, > >and delay... > > > >What I'd like to do is keep all these docs locally as text (since there is > >absolutely no useful graphics involved) that way it will be really fast, > >as w3 rendering slows me down. > > > >Also, it needs to open in a new frame for convenience. > > > >If it's not obvious, I'm new at java and reading code is arduous without > >quick conext-sensitive documentation. > > > > I agree this would be a very useful facility. Others have come up with > context-sensitive API help solutions but I haven't been able to get any of > them to work satisfactorily. It should be pretty easy now to construct an > elisp/ BeanShell/Java wizard approach to this feature. Here's how I see it > working: > > User interface: > > 1) Add a JDE variable, e.g., jde-api-doc-directories, that specifies a > list of API > doc directories. > > 2) The user types F1 or M-x jde-api-help with the point anywhere in a Java > source buffer. > > 3) The JDE looks up the api page for the symbol at point in > jde-api-doc-directories and, if it finds the page, displays the page > in the user's default HTML browser (as specified via browse-url). > > If the JDE cannot find a help page for the symbol, it displays an error > message in the minibuffer. If it finds multiple pages, it gives the user a > choice of which page to display in a temporary "choice" buffer. > > Implementation: > > As a first cut, the help facility might work only for symbols that are > class names (leaving, for example, methods and fields until later). (Much > of the code could be pilfered from the JDE import wizard. Here's how I see > it working: > > 1. Get the symbol at point (see elisp for Import Wizard). > > 2. Assuming the symbol is a class name, find the class's package. > (See the Java source for the Import Wizard for code that does this.) > If there are multiple classes of the same name in the classpath, > ask the user to "disambiguate" the symbol. If no classes are found, > display an error message in the minibuffer. > > 3. Construct an html file name from the class an package name, e.g., > java.awt.Vector becomes java/awt/Vector.html. > > 4. Search jde-api-doc-directories for the target file, e.g., suppose that > jde-api-doc-directories lists d:/jdk1.2/docs/api/. You would then > concatenate the jdk api directory with the target path, e.g., > d:/jdk1.2/docs/api/java/awt/Vector.html and test for existence > of this file, using the appropriate elisp file existence function. > > 5. Finally invoke browse-url on the file that has been found. If the JDE package is going to come with the API... then we can arrange it how we wish, and even have D:/jdk1.2/docs/api/java/awt/Vector/size.html Going further than this would be difficult, however... say, Vector v = new Vector(); v.clone().clone(); Is the elisp parser sufficient to know what a return type of an expression is? And precedence? > Note that a user can configure browse-url to use w3 or any other brower of > choice. > > Unless someone else is keen to do this, I will take on this project myself. If you're interested in doing this, great. At the same time, I'll try to do what I can if I come up with any quick ways of doing it for my own purposes until it's done officially. Either way, I prefer a separate pane to pop up (and I'm using the emacs reversed terminology for pane, meaning window). I also realize that there have been some discussions about the limitations of emacs in the GUI realm. I can still see this being put together.... you click on a java element and a bubble appears in the foreground with a simple description... this would be done with an unrelated process. > > > >At any rate, what this rambling is supposed to accomplish is that it may > >not be a big project to hack together a completion sequence until the > >professional version is completed. > > > >Email me if you want to collaborate. > > > > I suggest that you review the exensive discussions on this issue that have > occurred previously in this list. The issues that you raised have all been > raised before and discussed pretty thoroughly. > > Not also that JDE 2.1.6beta includes a full Java parser with an elisp > interface to that parser. My plan has been to use the parser to figure out > the object for which completion is desired. > > - Paul Thanks, Bill
