From 1c593af14db09a318d50dc4517b82b76d90ae029 Mon Sep 17 00:00:00 2001 From: Manindra Moharana Date: Fri, 5 Jul 2013 18:19:37 +0530 Subject: [PATCH] Updated todo, untracking EMode.jar --- pdex/Todo, GSoC 2013.txt | 11 +++++------ .../processing/mode/experimental/ASTGenerator.java | 4 +++- 2 files changed, 8 insertions(+), 7 deletions(-) diff --git a/pdex/Todo, GSoC 2013.txt b/pdex/Todo, GSoC 2013.txt index caa3b1df8..2185b7af6 100644 --- a/pdex/Todo, GSoC 2013.txt +++ b/pdex/Todo, GSoC 2013.txt @@ -13,27 +13,26 @@ x! Code competition for local code is working with recursive look up. x! Code completion with library code, non-nested seems to be broken, fix it. Fixed. x Completion for external classes - ArrayList, HashMap, etc. *! Recursive lookup for compiled(library) code! -*! Library CC for nested would be tricky. Need to jump from local->compiled code while searching recursively. Recursive find's current implementation is based on ASTNode return type. Afaik, no way to instantiate orphaned -ASTNode objects(or did I miss it?). ASTNode objects have to be created only from the main ast instance. But I need to find a way to switch to compiled instances from local class instance. +*! Library CC for nested would be tricky. Need to jump from local->compiled code while searching recursively. Recursive find's current implementation is based on ASTNode return type. Afaik, no way to instantiate orphaned ASTNode objects(or did I miss it?). ASTNode objects have to be created only from the main ast instance. But I need to find a way to switch to compiled instances from local class instance. *! May be I should just implement recursive find for compiled code first, see how it goes and hopefully it would give me some ideas about how to integrating the two. x! Should I implement wrapper for ASTNode? - possibly needed for code completion with compiled and non-compiled code. Done. * Trie implementation would be lower priority, "premature optimisation is pure evil". Get all features of CC working good enough and then plan this. -*+ Differentiating between multiple statements on the same line. How to? +x Differentiating between multiple statements on the same line. How to? Done with offset handling. Finer details * Obj a1; a1.-> completion doesn't work before it is instantiated. Look into that. * printStuff(int,float,String) - completion endings have to be appropriate. Right now it's just printStuff(,,). Cursor positioning also needs to be taken care of. Argument list as tooltip if possible? * Sorted list of completion candidates - fields, then methods. It's unsorted presently. -*! p5 enhanced stuff in java, how does it fit in with everything else, and edge cases. Possibly add support for them. +*! p5 enhanced stuff in java, how does it fit in with everything else, and edge cases. Possibly add support for them. Offset handling improvements should help here. * Reflection API - getMethods vs getDeclaredMethods. -* Need to add offset correction to ASTGenerator and its lookup methods. Or leave it for later? +* Need to add offset correction to ASTGenerator and its lookup methods. Or leave it for later? All set to implement Offset Mapping ============== First major hurdle is offset mapping *! pde<->java code offset : precise conversion needed x for the above, I've decide to first implement a sketch outline like feature, which would highlight an AST element precisely in the pde code. This would ensure I've got the mapping working properly. And may lead to a future feature. -* This is precise upto a certain line. Once on a line, pde stuff have to be taken into consideration. +x This is precise upto a certain line. Once on a line, pde stuff have to be taken into consideration. x Edge case - multiple statements in a single line x PDE specific enhancements will also have to be tackled like int(), # literals. The length of the node returned needs to be modified to make up for extra chars added like PApplet.parseFloat, etc. Also the 2nd or futher pde enhancements in the same line means even the beginning offset would need adjustment. Meh. * The above is almost working. There are some offset issues when multiple pde statements are in the same line, but I guess it's good enough for now to proceed ahead. Will keep a close watch for potential bugs. diff --git a/pdex/src/processing/mode/experimental/ASTGenerator.java b/pdex/src/processing/mode/experimental/ASTGenerator.java index 29348659d..99c522ba4 100644 --- a/pdex/src/processing/mode/experimental/ASTGenerator.java +++ b/pdex/src/processing/mode/experimental/ASTGenerator.java @@ -183,7 +183,7 @@ public class ASTGenerator { // frameAutoComp = new JFrame(); // frameAutoComp.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); // frameAutoComp.setBounds(new Rectangle(1280, 100, 460, 620)); -// tableAuto = new JTable(); + tableAuto = new JTable(); // JScrollPane sp2 = new JScrollPane(); // sp2.setViewportView(tableAuto); // frameAutoComp.add(sp2); @@ -1593,6 +1593,8 @@ public class ASTGenerator { SwingUtilities.invokeLater(new Runnable() { @Override public void run() { + frmOccurenceList.setTitle("All occurrences of " + + editor.ta.getSelectedText()); lblRefactorOldName.setText("Current name: " + editor.ta.getSelectedText()); txtRenameField.requestFocus();