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

[Nicolas Cellier]

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...


>>
>>>> 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/a8cb584e/attachment-0001.htm>