stepinto / polaris Goto Github PK

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

for example, "List"

may be can improved using custom Sort

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

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

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

as the title

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.

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.

put javadoc into index

It should show the following:

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

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

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.

Currently, primitive type void is mapped to Void.

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

Index file path and show directory hierarchy on UI

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.

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

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.