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

[Nicolas Cellier]

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
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200512/fc7d753f/attachment.htm>