[Cuis-dev] [ChangeSet] source code intervals + changes on refactorings

[Nicolas Cellier]

Just FYI, I gave it a quick try in Squeak and replaced the Interval in
TextEditor, Parser, and RB* with such a simple Range.
My findings is that I prefer to handle Range exactly as a Stream position,
0=before first character, size=after last character.
I thus keep the position (0-based) + the length, and it is looking quite
like a Python range.

Le lun. 18 mai 2020 à 18:16, Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> a écrit :

> Hi Folks,
>
> Any news wrt this? An implementation taking account of all the great
> insights in this thread would be great.
>
> Nahuel? Hernán?
>
> Thanks,
>
> On 5/11/2020 7:41 PM, Nicolas Cellier via Cuis-dev wrote:
>
>
>
> Le mar. 12 mai 2020 à 00:37, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> a écrit :
>
>>
>>
>> Le lun. 11 mai 2020 à 23:26, Phil B <pbpublist at gmail.com> a écrit :
>>
>>> Nicolas,
>>>
>>> On Mon, May 11, 2020 at 5:02 PM Nicolas Cellier via Cuis-dev <
>>> cuis-dev at lists.cuis.st> wrote:
>>>
>>>>
>>>>
>>>> Le lun. 11 mai 2020 à 22:58, Luciano Notarfrancesco via Cuis-dev <
>>>> cuis-dev at lists.cuis.st> a écrit :
>>>>
>>>>>
>>>>>
>>>>> On Tue, 12 May 2020 at 3:44 AM, Nicolas Cellier via Cuis-dev <
>>>>> cuis-dev at lists.cuis.st> wrote:
>>>>>
>>>>>> Can you represent empty ranges?
>>>>>>
>>>>>> For example,
>>>>>> (5,5) could be empty (marking a position before or after 5th
>>>>>> character - your choice)
>>>>>>
>>>>>
>>> Definitely.  That's why start<=end.  Needed for things like errors where
>>> you might only essentially know the position something occurred at but need
>>> to return a range for whatever reason.
>>>
>>>
>>>> (5,6) a one character range (from left to right)
>>>>>>
>>>>>
>>> Yep.
>>>
>>>
>>>> (5,4) too (from right to left).
>>>>>>
>>>>>
>>> My thinking was that this could get swapped during instance creation.
>>> If end<start, then swap. (i.e. only for source code ranges would start<=end
>>> always be the case, the more general range superclass would allow the
>>> inversion)
>>>
>>>
>>>>> Good question. Kind of looks like a pathological case, do you really
>>>>> need that? Is it for the cursor position?
>>>>>
>>>>> For example if we want to use that Range in Text selection, then yes.
>>>>
>>>
>>> While the text could be selected from end to start, would anything be
>>> lost by flipping the positions around in the range created?
>>>
>>>
>> Oups, sorry to repeat, my intention was this to be in public discussion,
>> but I'm bad with reply, reply all ..
>>
>> As you noted, backward ranges like (5,4) have an interest for interactive
>> selection: the start is the pivot point, and the end gives the direction
>> (we are extending selection toward left or right around the pivot).
>> Peserving the pivot is an advantage when you later extend/shrink the
>> selection with cursor keys for example...
>>
>> Of course, this can be (and is) the responsibility of specialized editor,
>> but I have the feeling that Range serves this purpose well without too much
>> complexification...
>>
>> Currently most models (Browser, Debugger, etc...) are using Interval for
>> contentsSelection which does not sound good.
>> What if you want to have more control on the direction of the selection?
>> Recently, there was a hack in Squeak which reverted the pcRange in
>> Debugger so as to show the beginning of selected text rather than the end
>> for the case when the window is small. That would not work in Cuis due to
>> cleaner Interval implementation, and that did not work either in a Squeak
>> after I cleaned the Interval too :(
>> Not sure if it is the right fix, but backward Range would fit...
>>
>> Correction: that would work in Cuis thanks to negative count, I did not
> notice this before...
>
>
>>>>
>>>>>> Le lun. 11 mai 2020 à 01:22, Phil B via Cuis-dev <
>>>>>> cuis-dev at lists.cuis.st> a écrit :
>>>>>>
>>>>>>> Luciano,
>>>>>>>
>>>>>>> Since the vast majority of ranges I'd be working with are
>>>>>>> programmatically created, #.. wouldn't really help me (i.e. Range #from:to:
>>>>>>> would be fine and consistent with Interval in meaning) but I'm not opposed
>>>>>>> to it if it would help you.  However, I would not be in favor of
>>>>>>> overloading #, since that seems confusing given other implementors of #,.
>>>>>>>
>>>>>>
>>>>> Yeah, I wouldn’t want to overload #, and my suggestion about #..
>>>>> mainly was about allowing it as a binary operator that might be nice to
>>>>> have available for whatever people decide to use it. #from:to: looks nice
>>>>> enough, tho.
>>>>> --
>>>>> Cuis-dev mailing list
>>>>> Cuis-dev at lists.cuis.st
>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>
>>>> --
>>>> Cuis-dev mailing list
>>>> Cuis-dev at lists.cuis.st
>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>
>>>
>
> --
> Juan Vuletichwww.cuis-smalltalk.orghttps://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Devhttps://github.com/jvuletichhttps://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200518/8dc8718a/attachment.htm>