[racket] Strange editor behaviour

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 <mflatt at cs.utah.edu> 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 <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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130914/95646c82/attachment-0001.html>