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