> Because we could remove it.
I think we never enabled it because we could not use good key combinations⦠the idea was to use ctrl-arrow keys for itâ¦
I still think that AST based navigation is a very good idea, removing it now without having ever used it for real is not good.
Marcus, would that make sense to:
* extract the core of the AST navigation as an API onto the RB AST (the ability to go up, down, left and right in a RB AST, basically), i.e. trying to preserve that way a bit some of the patterns solved by the AST navigation...
* and reduce whatever is linked with the GUI / text morph components ?
Oh, looking at the code, the two aspects are implemented together, so it will be painfull to refactor. Looking a bit more at the code... I'm interested by the rationale for askForNodeSelectionFrom:
Thierry
Marcus the problem is that the idea is cool but if nobody spent time making it useful for real then we will never know if it is working for real. I think that finding the right operations that makes sense can be probably difficult. Now we did the same analysis that thierry. The tree operations like parten children sibbling should not be on class side of nodes navigation but in the AST itself. We can keep used code in the image but I do not really understand why? So we have working tools such as the dependencies browser that could help us that were out of the image and things that nobody ever used in. For me I would unload the code and find a student or somebody interested to improve for real. Stef