|
|
| Added: |
>
> |
PSI handles imports for classes automatically. Use PsiElementFactory?.createClassReference, create some dummy references in your text, and then replace them. Alternatively, put fq names to text, and then use CodeStyleManagager?.shortenClassReferences.
-- DmitryLomov - 14 Jun 2003 |
|
|
| Added: |
>
> |
> Just curious, why would you need that?
I also looked for such factory method. You may need it for reformat tasks (e.g. insert a white space element or replace one white space element with another).
-- TimurZambalayev - 03 Jun 2003 |
|
|
| Added: |
>
> |
If I programmatically change the format of a file it takes a bit of time for IDEA to refresh the file and show the changes. Is there a way to programmatically force this refresh to occur?
-- SalCampana - 02 Jun 2003 |
|
|
| Added: |
>
> |
Intentions API question.
The newly opened intentions API looks about like I expected. The only method I didn't anticipate was Intention.getFamilyName(). As near as I can tell, though, it doesn't do anything. Is this just a future hook for some hypothetical "Intention Preferences" GUI, or is there something else going on?
-- DaveGriffith - 23 May 2003 |
|
|
| Added: |
>
> |
com.intellij.psi.codeStyle.CodeStyleManager.isUseDefaultDodeStyleScheme() should probably be changed to isUseDefaultCodeStyleScheme(), right? 
-- TimurZambalayev - May 14, 2003 |
|
|
| Added: |
>
> |
Here's a bit of code I've used to solve your problem. The code chunk uses a couple helper functions at the bottom. In my code example the 'formatter' is the class that you are using in new statement.
// craete import statement for formatter if necessary
PsiElement file = getFile(psiElement);
PsiElement[] topChildren = file.getContainingFile().getChildren();
for (int i = 0; i < topChildren.length; i++) {
PsiElement element = topChildren[i];
if (element instanceof PsiImportList) {
PsiImportList list = (PsiImportList)element;
addImportIfNecessary(list, formatterPkg, formatterFQName, psiFactory, psiElement, project);
break;
}
}
private static void addImportIfNecessary(PsiImportList list, String formatterPkg, String formatterFQName,
PsiElementFactory psiFactory, PsiElement psiElement, final Project project) throws IncorrectOperationException {
PsiImportStatement statement = list.findOnDemandImportStatement(formatterPkg);
if (statement == null) {
// didn't find pkg
statement = list.findSingleClassImportStatement(formatterFQName);
}
if (statement == null) {
// didn't find fqn
PsiElement newImport = psiFactory.createImportStatement(psiElement.getManager().findClass(formatterFQName));
newImport = list.add(newImport);
newImport = CodeStyleManager.getInstance(project).reformat(newImport);
}
}
private static PsiElement getFile(PsiElement selectedClass) {
PsiElement file = selectedClass;
while (!(file instanceof PsiJavaFile)) file = file.getParent();
return file;
}
-- BrianMcDonald - 26 Mar 2003 |
|
|
| Added: |
>
> |
Hi! I have a fairly basic question. I am writing a tool to help out with some of our code generation and ran into a problem working with imports using the PSI. I am creating statements from text (PsiElementFactory?.createStatementFromText()) and would like to add imports for the classes that I use within the statements. Right now I am using the fully qualified name. What is the best way to go about this? Thanks!
-- JohnHampton - 20 Mar 2003 |
|
|
| Added: |
>
> |
How to programmatically change IDEA project classpath?
Hi! I need to add/remove entries to/from IDEA project classpath from plugin code. Is it possible to do that, using OpenAPI or PsiAPI?? ProjectRootManager? has methods to retrieve classpath entries, but does not provide a way to manipulate it. I hope I havent overlooked the API call for that. It would be nice to be able to do so, otherwise users have to go ProjectOptions?/Paths/Classpath/Browse to find the correct entries, whereas this information is available in the plugin code. Thanks in advance!
-- PavlinZahariev - 07 Mar 2003 |
|
|
| Added: |
>
> |
I too would like to know how to either create a PsiWhiteSpace? element and replace an existing one with it, or modify the contents of an existing PsiWhiteSpace? element. Am trying to write a code beautifier
or reformatter plugin, and essentially need the ability to alter white space.
May I also ask, how would one go about reordering two PsiElements?, e.g. adjacent PsiDeclarationStatements??
-- DaveKriewall - 04 Mar 2003 |
|
|
| Added: |
>
> |
Is there a factory method for creating PsiJavaTokens? (e.g. commas, braces)? I'm attempting to insert a new element into a PsiArrayInitializerExpression? but can not determine how to either have the PsiArrayInitializerExpression?'s add function insert the comma for me or to do it manually. The ability to construct PsiWhiteSpace? programatically would also be useful (for inserting a newline after the array element).
-- BrianMcDonald - 14 Feb 2003 |
|
|
| Added: |
>
> |
When I use EditorFactory?.getInstance().createViewer to create a viewer for my java file, the method returns an instance of an editor which when shown doesn't not highlight java keywords but even though it hightlights class fields. Why is that? Besides it highlights class fields only in case the file has been already opened at least once for editing. That is a very strange side effect, isn't it?
-- KeshSibilev - 24 Jan 2003 |
|
|
| Added: |
>
> |
How can you get a reference to the JTree in the Project Window?
-- CharlesDeCroes - 09 Dec 2002
|
| Added: |
>
> | |
|
|
| Deleted: |
<
< |
What's the difference between the following two methods?
PsiVariable psiVariable = ...;
PsiType type = psiVariable.getType();
PsiType typeElement = psiVariable.getTypeElement();
Thanks!
-- ThomasVollmer - 30 Nov 2002
Existense of 2 methods for getting variable type is caused by ugly declaration syntax which is unfortunately allowed by java:
int a[]; // ugly syntax!
Note that PSI interfaces generally represents the structure of the source-tree. In the source tree of variable declaration, there should be a node representing variable type. Unfortunately, the above syntax makes it impossible to represent the actual type by one node. You may use PsiViewerPlugin to see how the source-tree of the above declaration looks like.
PsiVariable?.getTypeElement() always returns the actual node in the source tree corresponding to the variable type. And in case of the mentioned syntax it DOES NOT represent the actual variable type.
PsiVariable?.getType() returns the same value as PsiVariable?.getTypeElement() in case of "normal" syntax and constructs a "dummy" type representing the actual type otherwise. Note that PsiVariable?.getType() method should not be used for modifying the type (cause it might not belong to the original source-tree!).
There is a convenient method PsiVariable?.normalizeDeclaration() which removes this difference by "normalizing" the declaration (aside that, it also splits multiple variables declared in the same declaration into multiple declarations).
-- ValentinKipiatkov - 04 Dec 2002
Thanks for your detailed answer! I had totally forgotten about Java's "ability" to allow this ugly (and inconsistent) syntax. I never use it. If I understand correctly, then PsiVariable?.normalizeDeclaration() changes the source-tree, is that correct? After calling it, I'm assuming that I would have to re-enter the source-tree somewhere and work with the new structure?
-- ThomasVollmer - 05 Dec 2002
Yes, PsiVariable?.normalizeDeclaration() changes the source tree. However, the original PsiVariable? instance stays valid (although it may change its parent).
BTW, IDEA itself only uses this method when it need to perform some changes on a variable that would be difficult to perform otherwise (for example, change its type). If it doesn't need any modifications to a variable it doesn't do them.
-- ValentinKipiatkov - 05 Dec 2002 |
|
|
| Deleted: |
<
< |
I'm trying to figure out some methods in PSI and it's more difficult than it could be because there is no info on the parameter names. Only the parameter types are available in Parameter Info and Quick JavaDoc. It would be of great help if the parameter names were also available.
Here's an example:
PsiResolveHelper.resolveReference(PsiReference, boolean, boolean[], boolean[])
Thanks in advance!
-- ThomasVollmer - 29 Nov 2002
PsiElement resolveReference(PsiReference reference, boolean incompleteCode,
boolean[] problemWithAccess, boolean[] problemWithStatic);
PsiMethod resolveConstructor(PsiClass aClass, PsiExpressionList argumentList, PsiElement place,
boolean[] problemWithAccess);
PsiMethod[] getReferencedMethodCandidates(PsiReferenceElement reference, boolean dummyImplicitConstructor);
boolean hasReferencedMethodCandidates(PsiReferenceElement reference);
PsiClass resolveReferencedClass(String referenceText, PsiElement context);
PsiVariable resolveReferencedVariable(String referenceText, PsiElement context, PsiElement boundScope);
-- MikeAizatsky - 29 Nov 2002
Thanks! I'll still have to experiment but the parameter names will be a big help.
Would it be possible to make this available for the entire PSI API? Maybe JavaDocs or source code stubs? Note that I am not asking for a fully documented PSI API, just for the parameter names.
-- ThomasVollmer - 29 Nov 2002
|
| Added: |
>
> |
Yes, PsiVariable?.normalizeDeclaration() changes the source tree. However, the original PsiVariable? instance stays valid (although it may change its parent).
BTW, IDEA itself only uses this method when it need to perform some changes on a variable that would be difficult to perform otherwise (for example, change its type). If it doesn't need any modifications to a variable it doesn't do them.
-- ValentinKipiatkov - 05 Dec 2002
|
| Deleted: |
<
< |
The meaning of the parameters of the following method is clear:
PsiTreeUtil.getParentOfType(PsiElement, Class);
But what are the parameter names and meanings of these:
PsiTreeUtil.getParentOfType(PsiElement, Class, boolean);
PsiTreeUtil.getParentOfType(PsiElement, Class[]);
PsiTreeUtil.getParentOfType(PsiElement, Class[], boolean);
Thanks!
-- ThomasVollmer - 01 Dec 2002
I attached the whole source code of this utility class (cause it's implementation only uses PSI interfaces).
-- ValentinKipiatkov - 04 Dec 2002
Thank you very much. What a rare view into the inner workings of IDEA!
-- ThomasVollmer - 05 Dec 2002
What is the meaning of the boolean parameter of the following method?
PsiClass.findMethodBySignature(PsiMethod, boolean)
Could it be something like "also look in superclasses"?
Thanks!
-- ThomasVollmer - 02 Dec 2002
Yes, exactly. It controls whether methods of superclasses/interfaces should be checked as well.
-- ValentinKipiatkov - 04 Dec 2002
Thanks!
-- ThomasVollmer - 05 Dec 2002 |
|
|
| Added: |
>
> |
Thanks for your detailed answer! I had totally forgotten about Java's "ability" to allow this ugly (and inconsistent) syntax. I never use it. If I understand correctly, then PsiVariable?.normalizeDeclaration() changes the source-tree, is that correct? After calling it, I'm assuming that I would have to re-enter the source-tree somewhere and work with the new structure?
-- ThomasVollmer - 05 Dec 2002
|
| Added: |
>
> |
Thank you very much. What a rare view into the inner workings of IDEA!
-- ThomasVollmer - 05 Dec 2002
|
| Added: |
>
> |
Thanks!
-- ThomasVollmer - 05 Dec 2002 |
|
|
| Deleted: |
<
< |
There is a difference if a tag is created by
factory.createTagFromText("<attribute></attribute>");
or
factory.createTagFromText("<attribute/>");
The difference becomes visible if you try to add further tags to the
newly created one. In the latter case, the result looks like this:
<attribute/>
<name>name</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
Well, I do not know if this is actually erratic behavior, but I think
it's a bit strange and pointing this out here might help others facing the same result.
-- SaschaWeinreuter - 15 Nov 2002
The semanic of PsiElement?.add() method (and other tree modification methods) is not strictly defined at the moment. Sometimes it makes additional transformations (like inserting comma when adding a parameter into the list of parameters), sometimes it does not. We plan to redesign this consept so that there will be semantic-specific methods like "insertTag" or "insertParameter" and "pure" methods which will only do primitive tree modification operations.
-- ValentinKipiatkov - 26 Nov 2002
|
| Added: |
>
> |
Existense of 2 methods for getting variable type is caused by ugly declaration syntax which is unfortunately allowed by java:
int a[]; // ugly syntax!
Note that PSI interfaces generally represents the structure of the source-tree. In the source tree of variable declaration, there should be a node representing variable type. Unfortunately, the above syntax makes it impossible to represent the actual type by one node. You may use PsiViewerPlugin to see how the source-tree of the above declaration looks like.
PsiVariable?.getTypeElement() always returns the actual node in the source tree corresponding to the variable type. And in case of the mentioned syntax it DOES NOT represent the actual variable type.
PsiVariable?.getType() returns the same value as PsiVariable?.getTypeElement() in case of "normal" syntax and constructs a "dummy" type representing the actual type otherwise. Note that PsiVariable?.getType() method should not be used for modifying the type (cause it might not belong to the original source-tree!).
There is a convenient method PsiVariable?.normalizeDeclaration() which removes this difference by "normalizing" the declaration (aside that, it also splits multiple variables declared in the same declaration into multiple declarations).
-- ValentinKipiatkov - 04 Dec 2002
|
| Added: |
>
> |
Just curious, why would you need that?
-- ValentinKipiatkov - 04 Dec 2002
|
| Added: |
>
> |
I attached the whole source code of this utility class (cause it's implementation only uses PSI interfaces).
-- ValentinKipiatkov - 04 Dec 2002
|
| Added: |
>
> |
Yes, exactly. It controls whether methods of superclasses/interfaces should be checked as well.
-- ValentinKipiatkov - 04 Dec 2002
|
| Added: |
>
> |
%META:FILEATTACHMENT{name="PsiTreeUtil.java" attr="h" comment="PsiTreeUtil class source code" date="1039005959" path="C:\Work\Ariadna\source\com\intellij\psi\util\PsiTreeUtil.java" size="3864" user="ValentinKipiatkov" version="1.1"}% |
|
|
| Added: |
>
> |
There is a difference if a tag is created by
factory.createTagFromText("<attribute></attribute>");
or
factory.createTagFromText("<attribute/>");
The difference becomes visible if you try to add further tags to the
newly created one. In the latter case, the result looks like this:
<attribute/>
<name>name</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
Well, I do not know if this is actually erratic behavior, but I think
it's a bit strange and pointing this out here might help others facing the same result.
-- SaschaWeinreuter - 15 Nov 2002
The semanic of PsiElement?.add() method (and other tree modification methods) is not strictly defined at the moment. Sometimes it makes additional transformations (like inserting comma when adding a parameter into the list of parameters), sometimes it does not. We plan to redesign this consept so that there will be semantic-specific methods like "insertTag" or "insertParameter" and "pure" methods which will only do primitive tree modification operations.
-- ValentinKipiatkov - 26 Nov 2002
|
| Changed: |
<
< |
There is a difference if a tag is created by
factory.createTagFromText("<attribute></attribute>");
or
factory.createTagFromText("<attribute/>");
The difference becomes visible if you try to add further tags to the
newly created one. In the latter case, the result looks like this:
<attribute/>
<name>name</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
Well, I do not know if this is actually erratic behavior, but I think
it's a bit strange and pointing this out here might help others facing the same result.
-- SaschaWeinreuter - 15 Nov 2002
| >
> |
|
| Changed: |
<
< |
The semanic of PsiElement?.add() method (and other tree modification methods) is not strictly defined at the moment. Sometimes it makes additional transformations (like inserting comma when adding a parameter into the list of parameters), sometimes it does not. We plan to redesign this consept so that there will be semantic-specific methods like "insertTag" or "insertParameter" and "pure" methods which will only do primitive tree modification operations.
| >
> |
Hi! How can I create PsiWhiteSpace? elements? There seems to be no corresponding factory method..
|
| Changed: |
<
< |
-- ValentinKipiatkov - 26 Nov 2002
| >
> |
-- OleMatzura - 01 Dec 2002
|
| Changed: |
<
< |
How create PsiWhiteSpace? elements?
| >
> |
|
| Changed: |
<
< |
Hi! How can I create PsiWhiteSpace? elements? There seems to be no corresponding factory method..
| >
> |
The meaning of the parameters of the following method is clear:
|
| Changed: |
<
< |
-- OleMatzura - 01 Dec 2002
| >
> |
PsiTreeUtil.getParentOfType(PsiElement, Class);
|
| Added: |
>
> |
But what are the parameter names and meanings of these:
|
| Added: |
>
> |
PsiTreeUtil.getParentOfType(PsiElement, Class, boolean);
PsiTreeUtil.getParentOfType(PsiElement, Class[]);
PsiTreeUtil.getParentOfType(PsiElement, Class[], boolean);
|
| Added: |
>
> |
Thanks!
|
| Added: |
>
> |
-- ThomasVollmer - 01 Dec 2002 |
|
|
| Added: |
>
> |
How create PsiWhiteSpace? elements?
Hi! How can I create PsiWhiteSpace? elements? There seems to be no corresponding factory method..
-- OleMatzura - 01 Dec 2002
|
|
|
| Changed: |
<
< |
| >
> |
What's the difference between the following two methods?
PsiVariable psiVariable = ...;
PsiType type = psiVariable.getType();
PsiType typeElement = psiVariable.getTypeElement();
Thanks!
-- ThomasVollmer - 30 Nov 2002
|
|
|
| Added: |
>
> |
|
| Added: |
>
> |
|
| Added: |
>
> |
Thanks! I'll still have to experiment but the parameter names will be a big help.
Would it be possible to make this available for the entire PSI API? Maybe JavaDocs or source code stubs? Note that I am not asking for a fully documented PSI API, just for the parameter names.
-- ThomasVollmer - 29 Nov 2002 |
|
|
| Added: |
>
> |
PsiElement resolveReference(PsiReference reference, boolean incompleteCode,
boolean[] problemWithAccess, boolean[] problemWithStatic);
PsiMethod resolveConstructor(PsiClass aClass, PsiExpressionList argumentList, PsiElement place,
boolean[] problemWithAccess);
PsiMethod[] getReferencedMethodCandidates(PsiReferenceElement reference, boolean dummyImplicitConstructor);
boolean hasReferencedMethodCandidates(PsiReferenceElement reference);
PsiClass resolveReferencedClass(String referenceText, PsiElement context);
PsiVariable resolveReferencedVariable(String referenceText, PsiElement context, PsiElement boundScope);
-- MikeAizatsky - 29 Nov 2002 |
|
|
| Added: |
>
> |
I'm trying to figure out some methods in PSI and it's more difficult than it could be because there is no info on the parameter names. Only the parameter types are available in Parameter Info and Quick JavaDoc. It would be of great help if the parameter names were also available.
Here's an example:
PsiResolveHelper.resolveReference(PsiReference, boolean, boolean[], boolean[])
Thanks in advance!
-- ThomasVollmer - 29 Nov 2002 |
|
|
| Deleted: |
<
< |
Example:
-
package mypackage
-
import myclass
Shouldn't they be a PsiElementReference instead like when they get created as in the UnitTest? example?
The problem now is that some elements in the file are contained by it (getContainingFile()) and some are not. Kills the abstraction and forces the client to handle special cases.
-- JacquesMorel - 09 Nov 2002
All elements in the file are contained by it (that is getContainingFile() returns the file). So it looks like I didn't catch your thought. Please illustrate it by some example.
-- ValentinKipiatkov - 11 Nov 2002
Take a look at the PsiViewerPlugin 1.5 that I released yesterday. I added a property sheet that will help me explain my case. If you go hit Ctrl-Shift-Q the import statement and package declaration are always references not PsiClass or PsiPackage. However if I put my caret in one of the package or classes of import statement or package declaration and hit Ctrl-Shift-P I will get directly a PsiClass? or a PsiPackage?. If I look at their containingFile it won't be the file currently edited but the one where the class is defined and null for the package.
To be really concrete, I will take one of the plugins I am developing: the JUnitTestPlugin. This plugin amongst other things, allows navigation between test class and tested class. Both classes are going to be primary class of each file. Because of that I would like to give the ability to swap between them from anywhere in the file. Every PsiElement? I get gives me the current file if I query for the containing file except the 2 situations I previously described. I understand that the dereferencing is done behind the cover but I believe this breaks an important invariant: every element that I get from an action on that file should be contained in that file. Maybe have 2 data contexts, one not dereferenced and one dereferenced. Or maybe have the dereferencing utility readily available.
-- JacquesMorel - 13 Nov 2002
This problem has nothing to do with PSI, it's related with PsiViewer? plugin implementation. I checked it and found that when it fetches an element to be viewed (Helpers.getCurrentElement method) it has the following code at the very beginning:
final PsiElement? element = (PsiElement?) dataContext.getData("psi.Element");
if (element != null)
return element;
That's why it returns target when the caret is on a reference (it's behaviour of dataContext.getData("psi.Element") in editor).
BTW, the last version of PsiViewer? is unusable because it throws lot of exceptions. I guess you have them reported but if not, ask me I'll send you one.
-- ValentinKipiatkov - 13 Nov 2002
BTW is PsiElement.findElementAt(int i) doing the dereferencing automatically? Then would PsiElement.findReference(int i) always return elements that might be references but that are guaranteed to be contained in the file of the current element?
Is the i parameter, an offset from the beginning of the element or the containing file? Thanks
-- JacquesMorel - 13 Nov 2002
PsiElement?.findElementAt doesn't perform any dereferencing. It returns the "leaf" element containing the character at the offset (or null if offset is less than 0 or greater or equal to the file length).
PsiElement?.findReference(int) returns PsiReference? at offset, offset is from the beginning of the file.
-- ValentinKipiatkov - 13 Nov 2002
Again this kills the abstraction. Every position in the file should have an associated element.
-- JacquesMorel - 09 Nov 2002
All TEXT in the file is represented by elements. That is, if you sum up text of all leaf elements in the tree you'll get the file text. If you think it's not true, please illustrate it with some small example.
P.S. There is a PsiViewerPlugin which is very useful when exploring PSI structure (in particular, when learning it).
-- ValentinKipiatkov - 11 Nov 2002
Go to the end of the file (it should be a position with its own line without space), hit Ctrl-Shift-P. You will get nothing.
This is because that point offset is equal to the length of the file and apparently there isn't a PsiElement past the max offset.
This is the perfect case for a NullObject? pattern or here a PsiEndOfFile maybe. That way client do not have to handle this special case. I strongly believe that we should have this invariant: all position in the editor should have a PsiElement associated. This would simplify our life for a little cost. My 2 cents obviously
-- JacquesMorel - 13 Nov 2002
Any CHARACTER of the original text is included into some PsiElement? in the tree, not any POSITION. We might discuss whether the current model is better or worse comparing to the one that you propose but it makes little sense because it definitely won't change (too difficult to change such basic things not in the very beginning) so we should live with the current approach.
-- ValentinKipiatkov - 13 Nov 2002
|
| Added: |
>
> |
The semanic of PsiElement?.add() method (and other tree modification methods) is not strictly defined at the moment. Sometimes it makes additional transformations (like inserting comma when adding a parameter into the list of parameters), sometimes it does not. We plan to redesign this consept so that there will be semantic-specific methods like "insertTag" or "insertParameter" and "pure" methods which will only do primitive tree modification operations.
-- ValentinKipiatkov - 26 Nov 2002 |
|
|
| Added: |
>
> |
There is a difference if a tag is created by
factory.createTagFromText("<attribute></attribute>");
or
factory.createTagFromText("<attribute/>");
The difference becomes visible if you try to add further tags to the
newly created one. In the latter case, the result looks like this:
<attribute/>
<name>name</name>
<required>false</required>
<rtexprvalue>false</rtexprvalue>
Well, I do not know if this is actually erratic behavior, but I think
it's a bit strange and pointing this out here might help others facing the same result.
-- SaschaWeinreuter - 15 Nov 2002 |
|
|
| Added: |
>
> |
|
| Added: |
>
> |
-- JacquesMorel - 13 Nov 2002
This problem has nothing to do with PSI, it's related with PsiViewer? plugin implementation. I checked it and found that when it fetches an element to be viewed (Helpers.getCurrentElement method) it has the following code at the very beginning:
final PsiElement? element = (PsiElement?) dataContext.getData("psi.Element");
if (element != null)
return element;
That's why it returns target when the caret is on a reference (it's behaviour of dataContext.getData("psi.Element") in editor).
BTW, the last version of PsiViewer? is unusable because it throws lot of exceptions. I guess you have them reported but if not, ask me I'll send you one.
-- ValentinKipiatkov - 13 Nov 2002
|
| Changed: |
<
< |
Is the i parameter, an offset from the beginning of the element or the containing file? Thanks -- JacquesMorel - 13 Nov 2002
| >
> |
Is the i parameter, an offset from the beginning of the element or the containing file? Thanks
-- JacquesMorel - 13 Nov 2002
PsiElement?.findElementAt doesn't perform any dereferencing. It returns the "leaf" element containing the character at the offset (or null if offset is less than 0 or greater or equal to the file length).
PsiElement?.findReference(int) returns PsiReference? at offset, offset is from the beginning of the file.
-- ValentinKipiatkov - 13 Nov 2002
|
| Added: |
>
> |
|
| Added: |
>
> |
|
| Added: |
>
> |
|
| Deleted: |
<
< |
-- ValentinKipiatkov - 13 Nov 2002
|
| Added: |
>
> |
-- ValentinKipiatkov - 13 Nov 2002 |
|
|
| Deleted: |
<
< |
|
| Changed: |
<
< |
This is the perfect case for a NullObject? pattern or here a PsiEndOfFile maybe. That way client do not have to handle this special case. I strongly believe that we should have this invariant: all position in the editor should have a PsiElement associated. This would simplify our life for a little cost. My 2 cents obviously -- JacquesMorel - 13 Nov 2002
| >
> |
This is the perfect case for a NullObject? pattern or here a PsiEndOfFile maybe. That way client do not have to handle this special case. I strongly believe that we should have this invariant: all position in the editor should have a PsiElement associated. This would simplify our life for a little cost. My 2 cents obviously
-- JacquesMorel - 13 Nov 2002
Any CHARACTER of the original text is included into some PsiElement? in the tree, not any POSITION. We might discuss whether the current model is better or worse comparing to the one that you propose but it makes little sense because it definitely won't change (too difficult to change such basic things not in the very beginning) so we should live with the current approach.
-- ValentinKipiatkov - 13 Nov 2002 |
|
|
| Added: |
>
> |
Take a look at the PsiViewerPlugin 1.5 that I released yesterday. I added a property sheet that will help me explain my case. If you go hit Ctrl-Shift-Q the import statement and package declaration are always references not PsiClass or PsiPackage. However if I put my caret in one of the package or classes of import statement or package declaration and hit Ctrl-Shift-P I will get directly a PsiClass? or a PsiPackage?. If I look at their containingFile it won't be the file currently edited but the one where the class is defined and null for the package.
To be really concrete, I will take one of the plugins I am developing: the JUnitTestPlugin. This plugin amongst other things, allows navigation between test class and tested class. Both classes are going to be primary class of each file. Because of that I would like to give the ability to swap between them from anywhere in the file. Every PsiElement? I get gives me the current file if I query for the containing file except the 2 situations I previously described. I understand that the dereferencing is done behind the cover but I believe this breaks an important invariant: every element that I get from an action on that file should be contained in that file. Maybe have 2 data contexts, one not dereferenced and one dereferenced. Or maybe have the dereferencing utility readily available.
BTW is PsiElement.findElementAt(int i) doing the dereferencing automatically? Then would PsiElement.findReference(int i) always return elements that might be references but that are guaranteed to be contained in the file of the current element?
Is the i parameter, an offset from the beginning of the element or the containing file? Thanks -- JacquesMorel - 13 Nov 2002
|
| Added: |
>
> |
Go to the end of the file (it should be a position with its own line without space), hit Ctrl-Shift-P. You will get nothing.
This is because that point offset is equal to the length of the file and apparently there isn't a PsiElement past the max offset.
This is the perfect case for a NullObject? pattern or here a PsiEndOfFile maybe. That way client do not have to handle this special case. I strongly believe that we should have this invariant: all position in the editor should have a PsiElement associated. This would simplify our life for a little cost. My 2 cents obviously -- JacquesMorel - 13 Nov 2002 |
|
|
| Added: |
>
> |
All elements in the file are contained by it (that is getContainingFile() returns the file). So it looks like I didn't catch your thought. Please illustrate it by some example.
-- ValentinKipiatkov - 11 Nov 2002
|
| Added: |
>
> |
All TEXT in the file is represented by elements. That is, if you sum up text of all leaf elements in the tree you'll get the file text. If you think it's not true, please illustrate it with some small example.
P.S. There is a PsiViewerPlugin which is very useful when exploring PSI structure (in particular, when learning it).
-- ValentinKipiatkov - 11 Nov 2002 |
|
|
| Changed: |
<
< |
PSI Questions and answers
| >
> |
PSI Questions and answers
|
| Changed: |
<
< |
Put your questions (and answers if you have them) here.
| >
> |
Example:
-
package mypackage
-
import myclass
Shouldn't they be a PsiElementReference instead like when they get created as in the UnitTest? example?
The problem now is that some elements in the file are contained by it (getContainingFile()) and some are not. Kills the abstraction and forces the client to handle special cases.
-- JacquesMorel - 09 Nov 2002
Again this kills the abstraction. Every position in the file should have an associated element.
-- JacquesMorel - 09 Nov 2002
|
| Deleted: |
<
< |
-- MikeAizatsky - 28 Oct 2002 |
|
|
| Added: |
>
> |
%META:TOPICINFO{author="MikeAizatsky" date="1035809369" format="1.0" version="1.1"}%
%META:TOPICPARENT{name="ProgramStructureInterface"}%
PSI Questions and answers
Put your questions (and answers if you have them) here.
-- MikeAizatsky - 28 Oct 2002 |
View
| Diffs | r1.38 | > | r1.37 | > | r1.36
| More
|
|