does anybody use the AST navigation?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

does anybody use the AST navigation?

stepharo
Hi guys

does any of you use the AST code navigation?
Because we could remove it.

Stef



Reply | Threaded
Open this post in threaded view
|

Re: does anybody use the AST navigation?

Marcus Denker-4

> On 30 Jun 2015, at 19:21, stepharo <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: does anybody use the AST navigation?

Thierry Goubier
Hi Marcus, Stef,

2015-07-01 11:24 GMT+02:00 Marcus Denker <[hidden email]>:

> On 30 Jun 2015, at 19:21, stepharo <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: does anybody use the AST navigation?

Marcus Denker-4

On 01 Jul 2015, at 14:28, Thierry Goubier <[hidden email]> wrote:

Hi Marcus, Stef,

2015-07-01 11:24 GMT+02:00 Marcus Denker <[hidden email]>:

> On 30 Jun 2015, at 19:21, stepharo <[hidden email]> 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:


Reply | Threaded
Open this post in threaded view
|

Re: does anybody use the AST navigation?

stepharo
In reply to this post by Thierry Goubier

> 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
Reply | Threaded
Open this post in threaded view
|

Re: does anybody use the AST navigation?

Marcus Denker-4

On 01 Jul 2015, at 23:30, stepharo <[hidden email]> 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