2016-08-29 21:38 GMT+02:00 Thierry Goubier <thierry.goubier@gmail.com>:

Le 29/08/2016 �� 21:28, stepharo a ��crit :

Le 29/8/16 �� 17:45, Thierry Goubier a ��crit :

Hi Stef,

2016-08-29 11:42 GMT+02:00 stepharo <stepharo@free.fr
<mailto:stepharo@free.fr>>:

�� Thierry

�� If you have a better editor control even better :)

�� Syntax wise, one could consider "" to be inside a comment (i.e.
�� do not split into two comments if encountered inside a comment,
�� as it is done now).

�� This one could be nice too :)

��https://pharo.fogbugz.com/f/cases/19011/Integrate-two-double-quotes-inside-comments

I'll have the slice ready soon. Any comments on what that would mean
regarding the Smalltalk commonly accepted syntax if that feature is
integrated?

It will break compatibility for people using it now we should raise the
topic and lets a chance to people to discuss about it. We could check
before publishing if code contain nested comments.

Hum. The slice should parse anything legal Smalltalk; just that it may show less comments intervals (because in fact it will coalesce adjacent comments).

Yes, I think the change for RBScanner is fine, it does not changes what kind of comments are accepted, only how they are assigned to

the AST nodes (one vs. multiple comments).

(BTW. do we have a function that would do the coalescing of intervals:

(1 to:99) (100 to: 199) -> (1 to:199)

? )

��

For example, standard parse will say that:

'"this ""test"' is a token with two comments, intervals 1 to: 7 and 8 to: 13.

The slice makes that a single comment:

'"this ""test"' is a token with one comment, interval 1 to: 13.

Now, this has probably no impact on parsing smalltalk code. But it changes a bit the language definition, so that's why I'd like comments on it.

I think that I would use them only when developing.

Up to you :)

The most interesting is to have the correct comment/uncomment behavior in an editor... that one works independently and is quite cool.

Thierry

Stef

Thierry