rb highlighting is not up to the task yet

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

rb highlighting is not up to the task yet

Tudor Girba-2
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

Nicolai Hess
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"

Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

Tudor Girba-2
Hi,

Here is an example.

Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black:
| a b c d |
a := 42.
b := a + 1.
c := b + 1.
d := c + 1.
 a . b . c . d }

Inline image 2

Here is how this looks in a Pharo 4:

Inline image 1

Cheers,
Doru


On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <[hidden email]> wrote:
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"




--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

Marcus Denker-4
Hello,

Yes, I am aware of that.

The idea was to evaluate how good the RB AST colouring is already and maybe find the energy to
fix all remaining problems… we fixed many but not all.

I propose that we keep it for some month more and if we don’t improve these problems go
back to the old scheme for Pharo5.

Then we can re-start to work on this in Pharo6.


Marcus

On 05 Sep 2015, at 07:28, Tudor Girba <[hidden email]> wrote:

Hi,

Here is an example.

Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black:
| a b c d |
a := 42.
b := a + 1.
c := b + 1.
d := c + 1.
 a . b . c . d }

<Playground-50.png>

Here is how this looks in a Pharo 4:

<Playground-40.png>

Cheers,
Doru


On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <[hidden email]> wrote:
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"




--

"Every thing has its own flow"

Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

Tudor Girba-2
Hi,

Yes, indeed. I think it is already much better than it was some months ago, and I definitely think it is a great goal to have everything around RB.

My question was only if there is anyone that invests in this actively because perhaps we can work together?

Cheers,
Doru



On Sat, Sep 5, 2015 at 6:34 PM, Marcus Denker <[hidden email]> wrote:
Hello,

Yes, I am aware of that.

The idea was to evaluate how good the RB AST colouring is already and maybe find the energy to
fix all remaining problems… we fixed many but not all.

I propose that we keep it for some month more and if we don’t improve these problems go
back to the old scheme for Pharo5.

Then we can re-start to work on this in Pharo6.


Marcus

On 05 Sep 2015, at 07:28, Tudor Girba <[hidden email]> wrote:

Hi,

Here is an example.

Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black:
| a b c d |
a := 42.
b := a + 1.
c := b + 1.
d := c + 1.
 a . b . c . d }

<Playground-50.png>

Here is how this looks in a Pharo 4:

<Playground-40.png>

Cheers,
Doru


On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <[hidden email]> wrote:
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"




--

"Every thing has its own flow"




--

"Every thing has its own flow"
Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

stepharo
In reply to this post by Marcus Denker-4
+ 1
We cannot be improving all fronts in parallel.

Stef

Le 5/9/15 18:34, Marcus Denker a écrit :
Hello,

Yes, I am aware of that.

The idea was to evaluate how good the RB AST colouring is already and maybe find the energy to
fix all remaining problems… we fixed many but not all.

I propose that we keep it for some month more and if we don’t improve these problems go
back to the old scheme for Pharo5.

Then we can re-start to work on this in Pharo6.


Marcus

On 05 Sep 2015, at 07:28, Tudor Girba <[hidden email]> wrote:

Hi,

Here is an example.

Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black:
| a b c d |
a := 42.
b := a + 1.
c := b + 1.
d := c + 1.
 a . b . c . d }

<Playground-50.png>

Here is how this looks in a Pharo 4:

<Playground-40.png>

Cheers,
Doru


On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <[hidden email]> wrote:
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"




--

"Every thing has its own flow"


Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

Nicolai Hess
In reply to this post by Tudor Girba-2
I do, working with RBStyler makes much more fun than with the other one and working
with AST instead of plain code text, gives us many possibilities to create great tools (highlighter for example:) )


I think we should not go back to the old one, but force the work on the rb styler.
Just report any issues you see. 


2015-09-05 20:29 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

Yes, indeed. I think it is already much better than it was some months ago, and I definitely think it is a great goal to have everything around RB.

My question was only if there is anyone that invests in this actively because perhaps we can work together?

Cheers,
Doru



On Sat, Sep 5, 2015 at 6:34 PM, Marcus Denker <[hidden email]> wrote:
Hello,

Yes, I am aware of that.

The idea was to evaluate how good the RB AST colouring is already and maybe find the energy to
fix all remaining problems… we fixed many but not all.

I propose that we keep it for some month more and if we don’t improve these problems go
back to the old scheme for Pharo5.

Then we can re-start to work on this in Pharo6.


Marcus

On 05 Sep 2015, at 07:28, Tudor Girba <[hidden email]> wrote:

Hi,

Here is an example.

Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black:
| a b c d |
a := 42.
b := a + 1.
c := b + 1.
d := c + 1.
 a . b . c . d }

<Playground-50.png>

Here is how this looks in a Pharo 4:

<Playground-40.png>

Cheers,
Doru


On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <[hidden email]> wrote:
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"




--

"Every thing has its own flow"




--

"Every thing has its own flow"

Reply | Threaded
Open this post in threaded view
|

Re: rb highlighting is not up to the task yet

Tudor Girba-2
Great. I also think we should push in this direction.

So, I will continue testing and provide feedback. Please ping me when you modify something. Ok?

Cheers,
Doru

On Sat, Sep 5, 2015 at 9:15 PM, Nicolai Hess <[hidden email]> wrote:
I do, working with RBStyler makes much more fun than with the other one and working
with AST instead of plain code text, gives us many possibilities to create great tools (highlighter for example:) )


I think we should not go back to the old one, but force the work on the rb styler.
Just report any issues you see. 


2015-09-05 20:29 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

Yes, indeed. I think it is already much better than it was some months ago, and I definitely think it is a great goal to have everything around RB.

My question was only if there is anyone that invests in this actively because perhaps we can work together?

Cheers,
Doru



On Sat, Sep 5, 2015 at 6:34 PM, Marcus Denker <[hidden email]> wrote:
Hello,

Yes, I am aware of that.

The idea was to evaluate how good the RB AST colouring is already and maybe find the energy to
fix all remaining problems… we fixed many but not all.

I propose that we keep it for some month more and if we don’t improve these problems go
back to the old scheme for Pharo5.

Then we can re-start to work on this in Pharo6.


Marcus

On 05 Sep 2015, at 07:28, Tudor Girba <[hidden email]> wrote:

Hi,

Here is an example.

Type this in a playground in a Pharo 5 image, and all statements before the parentheses become black:
| a b c d |
a := 42.
b := a + 1.
c := b + 1.
d := c + 1.
 a . b . c . d }

<Playground-50.png>

Here is how this looks in a Pharo 4:

<Playground-40.png>

Cheers,
Doru


On Sat, Sep 5, 2015 at 12:16 AM, Nicolai Hess <[hidden email]> wrote:
This depends on the kind of error. For example, a missing open or closed parenthesis will most
likely mark the whole (following) code.

But it should still highlight the preceding code.
Can you give an example.


nicolai


2015-09-04 23:10 GMT+02:00 Tudor Girba <[hidden email]>:
Hi,

I think it's nice that we are going towards consolidating our tools around RB.

However, the highlighting logic is not quite enough because if I have an error anywhere in the code, the whole highlighting disappears. In contrast, Shout manages to limit the problem only to the surrounding code.

Is anyone working on this part of the highlighting?

Cheers,
Doru

--

"Every thing has its own flow"




--

"Every thing has its own flow"




--

"Every thing has its own flow"




--

"Every thing has its own flow"