> 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
