[racket] Strange editor behaviour

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 <neil.toronto at gmail.com>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 <bhrgunatha at hotmail.com
> >>> <mailto:bhrgunatha at hotmail.com**>> 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