2016-08-31 10:14 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com>:
> Oops. No need to add a step method; the increment method already exists:
>
>
>
On Wed, Aug 31, 2016 at 9:12 AM, Eliot Miranda <eliot.mira...@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Aug 30, 2016 at 8:14 AM, Nicolai Hess <nicolaih...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> 2016-08-29 21:38 GMT+02:00 Thierry Goubier <thierry.goub...@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 <steph...@free.fr
>>>>>> <mailto:steph...@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-doubl
>>>>>> e-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)
>>>
>>> ? )
>>>
>>
>> Find attached something that works in Squeak 5
>>
>
Nice,
But actually I wasn't clear about the requirements :-)
The purpose was to merge source code intervals after parsing code comments.
The comments may be adjacent and could be merged into one comment. For this
I would like to merge an collection of intervals in a smaller number of
intervals with adjacent intervals merged into one:
{ (30 to: 35) . (36 to:40) . (50 to:100) }
-> { (30 to:40) . (50 to:100) }
But Thierry already changed the scanner to produce this smaller set of
intervals/comments :-)
>> 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
>>>>>>
>>>>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot
>
