<div dir="ltr">Yes, definitely many places should be passing #f as that second argument. I've started a pass to audit them, thanks!<div><br></div><div>But the behavior of this particular example still seems wrong to me. The streak-interrupt behavior doesn't seem right ever for shift movement. (Similarly for "forgetting" esc;y, assuming that that also counts as a streak.)</div>
<div><br></div><div>Robby</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Sep 14, 2013 at 6:03 PM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The notion of "streaks" is exposed explicitly by `begin-edit-sequence`<br>
through it's second optional argument.<br>
<br>
In other words, the behavior illustrated below looks right to me, while<br>
passing `#f` as the second argument to `begin-edit-sequence` gives the<br>
behavior that I think you want.<br>
<br>
So, are the bugs then related to calls to `begin-edit-sequence` that<br>
should pass #f for the `end-streaks?` argument?<br>
<div><div class="h5"><br>
At Sat, 14 Sep 2013 15:00:55 -0500, Robby Findler wrote:<br>
> A little more progress: it turns out that simply turning on and turning off<br>
> an edit-sequence in a text% object clears some internal state in a text%<br>
> object (the extend-streak? field) and, when the search bars are open, more<br>
> edit sequences are flying around. That seems wrong to me (that starting and<br>
> ending an edit-sequence would clear this state), but I'm not sure if the<br>
> answer can be as simple as avoiding this state-clearing action or not.<br>
> Anyways, here's some simple code that demonstrates how far I've gotten.<br>
><br>
><br>
> #lang racket/base<br>
> (require rackunit racket/class racket/gui/base)<br>
><br>
> (check-equal? (let ()<br>
>                 (define t (new text%))<br>
>                 (send t insert "abcdef")<br>
>                 (send t set-position 3 3)<br>
>                 (send t move-position 'right #t)<br>
>                 (send t move-position 'left #t)<br>
>                 (list (send t get-start-position)<br>
>                       (send t get-end-position)))<br>
>               (list 3 3))<br>
><br>
><br>
> (check-equal? (let ()<br>
>                 (define t (new text%))<br>
>                 (send t insert "abcdef")<br>
>                 (send t set-position 3 3)<br>
>                 (send t move-position 'right #t)<br>
>                 (send t begin-edit-sequence)<br>
>                 (send t end-edit-sequence)<br>
>                 (send t move-position 'left #t)<br>
>                 (list (send t get-start-position)<br>
>                       (send t get-end-position)))<br>
>               (list 3 3))<br>
><br>
> Robby<br>
><br>
><br>
><br>
> On Sat, Sep 14, 2013 at 12:43 PM, Neil Toronto <<a href="mailto:neil.toronto@gmail.com">neil.toronto@gmail.com</a>>wrote:<br>
><br>
> > Yes! You figured it out! This has been bugging me for months.<br>
> ><br>
> > Here's more info, in case it helps. In addition to SHIFT+Left,<br>
> > SHIFT+Right, SHIFT+Up and SHIFT+Down always expanding the selection when<br>
> > Replace is shown, so does SHIFT-End, and all the SHIFT+ALT arrow combos and<br>
> > SHIFT+CTRL combos. SHIFT-Home only works when the selection doesn't span<br>
> > multiple lines.<br>
> ><br>
> > If the Search box is empty, selection works as expected. (That is, getting<br>
> > in this always-expanding-selection or caret-position-forgetting state<br>
> > requires the Replace box to be shown and the Search box to have text in<br>
> > it.) If the Search box has text in it, it doesn't matter whether it's<br>
> > found. I'm guessing there's some caret-wrangling code for the search bar<br>
> > that causes the editor to forget the caret position while selecting.<br>
> ><br>
> > Selection in the REPL also seems to be affected by Search and Replace in<br>
> > exactly the same way. (I haven't tested it thoroughly.)<br>
> ><br>
> > We should have Eli test this because he's had the same problem. IIRC, he<br>
> > uses Linux, and so do I: I've seen this on Ubuntu 12.04 and 13.04.<br>
> ><br>
> > Neil ⊥<br>
> ><br>
> ><br>
> > On 09/14/2013 08:20 AM, bhrgunatha wrote:<br>
> ><br>
> >> After lots of head scratching and experimenting I have a consistent cause.<br>
> >><br>
> >> It seems like the Search and Replace bar causes some problem.<br>
> >> It is only happening when the Replace text box is visible.<br>
> >><br>
> >> This weird behaviour disappears if the I click the Hide Replace button<br>
> >> or choose Hide Replace from the Edit menu.<br>
> >><br>
> >> I've also noticed that S:C:R stops working after the Replace text box<br>
> >> and buttons have disappeared. That is I can't Hide, then Re show the<br>
> >> Replace text box.<br>
> >><br>
> >> I hope that helps you fix the problem, but I'm pretty happy now I know<br>
> >> how to get the correct operation back again.<br>
> >><br>
> >> Thanks,<br>
> >> Bhrgunatha<br>
> >><br>
> >><br>
> >> On 14/09/13 20:04, Robby Findler wrote:<br>
> >><br>
> >>> This sounds like a bug in the implementation of the shift-left and<br>
> >>> shift-right keybindings.<br>
> >>><br>
> >>> If you can give some kind of a step by step procedure to get into the<br>
> >>> bad state, then I think we can probably fix it.<br>
> >>><br>
> >>> Robby<br>
> >>><br>
> >>><br>
> >>><br>
> >>> On Sat, Sep 14, 2013 at 6:16 AM, bhrgunatha <<a href="mailto:bhrgunatha@hotmail.com">bhrgunatha@hotmail.com</a><br>
</div></div><div><div class="h5">> >>> <mailto:<a href="mailto:bhrgunatha@hotmail.com">bhrgunatha@hotmail.com</a>**>> wrote:<br>
> >>><br>
> >>>     I'm having a problem editing programs using DrRacket. This happened<br>
> >>>     once before but went away after re-installing. [1].<br>
> >>><br>
> >>>     I'm having the same issue again. Basically the behaviour of text<br>
> >>>     selection is changes while I open and edit different files running a<br>
> >>>     single instance of DrRacket.<br>
> >>><br>
> >>>     If I select some text and then press SHIFT+Left instead of altering<br>
> >>>     the selection based on the current cursor position, the selection is<br>
> >>>     extended left from the beginning of the text currently selected.<br>
> >>><br>
> >>>     Similarly for SHIFT+Right - it extends the text selection one<br>
> >>>     character to the right from the end of the selection rather than the<br>
> >>>     current cursor position. Same for SHIFT+Down, SHIFT+Up.<br>
> >>><br>
> >>>     Is there some key binding or setting in DrRacket that controls the<br>
> >>>     way text selection is handled that I am accidentally hitting?<br>
> >>><br>
> >>>     It doesn't happen in any other editor - it's specific to DrRacket.<br>
> >>><br>
> >>>     If I quit DrRacket and re-open it normal operation continues for a<br>
> >>>     while again. I don't know if it's a bug or some setting in DrRacket<br>
> >>>     that I am unaware of.<br>
> >>><br>
> >>>     My current specs are:<br>
> >>>     Arch Linux 64 bit:<br>
> >>>     Linux 3.10.10-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux<br>
> >>><br>
> >>>     DrRacket 5.3.6.<br>
> >>>     (This is a version I compiled myself - but it's the same using the<br>
> >>>     Arch binary package - racket 5.3.6-1)<br>
> >>><br>
> >>>     Can someone offer any advice?<br>
> >>><br>
> >>>     Bhrgunatha<br>
> >>><br>
> >>>     [1]<br>
> >>><br>
</div></div>> >>> <a href="http://article.gmane.org/__**gmane.comp.lang.racket.user/__**" target="_blank">http://article.gmane.org/__**gmane.comp.lang.racket.user/__**</a><br>
> >>><br>
> 17034/match=bhrgunatha<<a href="http://article.gmane.org/__gmane.comp.lang.racket.user/_" target="_blank">http://article.gmane.org/__gmane.comp.lang.racket.user/_</a><br>
> _17034/match=bhrgunatha><br>
> >>><br>
> >>><br>
> >>> <<a href="http://article.gmane.org/**gmane.comp.lang.racket.user/**" target="_blank">http://article.gmane.org/**gmane.comp.lang.racket.user/**</a><br>
> >>><br>
> 17034/match=bhrgunatha<<a href="http://article.gmane.org/gmane.comp.lang.racket.user/170" target="_blank">http://article.gmane.org/gmane.comp.lang.racket.user/170</a><br>
<div class="im">> 34/match=bhrgunatha><br>
> >>> ><br>
> >>><br>
> >>>     ____________________<br>
> >>>       Racket Users list:<br>
> >>><br>
</div>> <a href="http://lists.racket-lang.org/_**_users" target="_blank">http://lists.racket-lang.org/_**_users</a><<a href="http://lists.racket-lang.org/__users" target="_blank">http://lists.racket-lang.org/__users</a>><br>

> >>><br>
> <<a href="http://lists.racket-lang.org/**users" target="_blank">http://lists.racket-lang.org/**users</a><<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a>><br>

> >>> ><br>
> >>><br>
> >>><br>
> >>><br>
> >> ____________________<br>
> >>   Racket Users list:<br>
> >>   <a href="http://lists.racket-lang.org/**users" target="_blank">http://lists.racket-lang.org/**users</a><<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a>><br>

> >><br>
> ><br>
> > ____________________<br>
> >  Racket Users list:<br>
> >  <a href="http://lists.racket-lang.org/**users" target="_blank">http://lists.racket-lang.org/**users</a> <<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a>><br>

<div class="HOEnZb"><div class="h5">> ><br>
> ____________________<br>
>   Racket Users list:<br>
>   <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</div></div></blockquote></div><br></div>