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
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.
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.
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.
>Next, I've noticed everyone in this newsgroup really needs method lists.
>I do too. I realize Paul has some other projects to work on, and I
>appreciate the work he's doing. I've got a few things in mind for this
>right now...
>
>First, ever noticed that M-/ cycles through completions? This is an
>acceptable way to handle it as opposed to a popup window. A hack for this
>sort of behavior I can see happening this way:
>
>First time you try to complete, an external tool rummages through the
>CLASSPATH api. It could just be a list like:
>("java.util.Vector" "java.util.List" ...)
>completion would be minimal for data types, in otherwords
>jav<complete> -> java
>java.u <complete> -> java.util
>java.util.V <complete> -> java.util.Vector
>
>That's probably not tough to manage.
>
>Then you have the variable properties which are a different matter... Of
>course, this requires meaningful interpretation of the current buffer. To
>speed things up we could require that users declare variables like this:
>
>String s;
>
>instead of
>String
>s;
>
>Which is technically legal. Then, all we have to do is search for all
>lines in the current scope that match this tokenization:
><data type> <variable>;
>
>Since finding the current scope might require effort (ugghh effort) in a
>file in edit, a good approximation is nearest declaration of the variable
>of that name...
>
>Alternatively we could use environmental frames
>{
><open frame x>
>}
><close frame x>
>
>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
- Paul
