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

[Juan Vuletich]

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 
> <mailto:nicolas.cellier.aka.nice at gmail.com>> a écrit :
>
>
>
>     Le lun. 11 mai 2020 à 23:26, Phil B <pbpublist at gmail.com
>     <mailto: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 <mailto: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
>             <mailto: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
>                 <mailto: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
>                     <mailto: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 <mailto:Cuis-dev at lists.cuis.st>
>                 https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>             -- 
>             Cuis-dev mailing list
>             Cuis-dev at lists.cuis.st <mailto:Cuis-dev at lists.cuis.st>
>             https://lists.cuis.st/mailman/listinfo/cuis-dev
>


-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200518/fbb4e951/attachment-0001.htm>