stepinto / polaris Goto Github PK

The syntax highlight widget cannot handle a code snippet that cut from the middle of a comment block. We need to do something special to handle this.

Currently, primitive type void is mapped to Void.

We may need to write a code highlight widget, since we need some special handling for context (popup) menu for identifiers. The ideal scenario is that a user clicks on a identifier, the menu shows options like "Go to defination", "Find usages".

It should show the following:

• show value of a constants
• show variable type
• super/sub-classes
• overridden methods

We don't support non-ASCII chars in source code yet. The reason is that all line/cols produced by JavaParser are the raw offset, but we use unicode internally when analyzing files. This creates a mismatch. Since unicode content may be shorter than UTF-8 ones, it may leads to ArrayIndexOutOfBoundsException.

The current walkaround is refusing to analyze any non-ASCII sources, since there should not be that many.

should using segmentation technique to analyze and index long symbols
for example
ArrayList -> [array, list]
Filesystem->[file, system]

maybe a ChineseAnalyzer with a custom english dict will work

put javadoc into index

as the title

Type java.util.L. It doesn't give candidates java.util.List. I guess we didn't handle prefix query right.

Like what grepcode does for javadoc. At least, we should translate format tags in javadoc like {@code} {@link} into html code.

Source file: openjdk/langtools/test/tools/javac/DeepStringConcat.java

What's more interesting is IntelliJ suffers from a similar problem (http://youtrack.jetbrains.com/issue/IDEA-25679). A temporary walkaround for us is to catch StackOverflowError.

The current parser only produces a list of token, which is going to indexed. I would like to refactor it so that it also generates a list of java types with fields/methods. Tokens are also used for annotation of the source code and does not need to indexed directly.

We don't support non-ASCII chars in source code yet. The reason is that all line/cols produced by JavaParser are the raw offset, but we use unicode internally when analyzing files. This creates a mismatch. Since unicode content may be shorter than UTF-8 ones, it may leads to ArrayIndexOutOfBoundsException.

The current walkaround is refusing to analyze any non-ASCII sources, since there should not be that many.

Index file path and show directory hierarchy on UI

Parser needs to handle inner class correctly. Currently String is resolved to a private class T6722234c.String.

for example, "List"

may be can improved using custom Sort

Index multiple projects. A user can search in all projects.

Provides a window like PS's undo/redo window that help user to navigate back and forth.