Hi guys does any of you use the AST code navigation? Because we could remove it. Stef
On 30 Jun 2015, at 19:21, stepharo <stepharo@free.fr> wrote:
Hi guys
does any of you use the AST code navigation? 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
Hi Marcus, Stef, 2015-07-01 11:24 GMT+02:00 Marcus Denker <marcus.denker@inria.fr>:
On 30 Jun 2015, at 19:21, stepharo <stepharo@free.fr> wrote:
Hi guys
does any of you use the AST code navigation?
I haven't.
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
On 01 Jul 2015, at 14:28, Thierry Goubier <thierry.goubier@gmail.com> wrote:
Hi Marcus, Stef,
2015-07-01 11:24 GMT+02:00 Marcus Denker <marcus.denker@inria.fr <mailto:marcus.denker@inria.fr>>:
On 30 Jun 2015, at 19:21, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote:
Hi guys
does any of you use the AST code navigation?
I haven't.
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 ?
Yes, sounds good...
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:
> 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
On 01 Jul 2015, at 23:30, stepharo <stepharo@free.fr> wrote:
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.
We could remove it for now⦠it makes only sens when we can use CTRL-arrow keys to navigate, but there are problems with that related to the keyboard events, I think. Marcus
participants (3)
-
Marcus Denker -
stepharo -
Thierry Goubier