Yeah, there are a number of variables that seem to be reset on edit-sequences. Another one that may or may not be related to this same variable is when esc;y works.
Robby On Sat, Sep 14, 2013 at 4:03 PM, Neil Toronto <[email protected]>wrote: > I appreciate your work on this, and also how tiny the test case is. :) > > If it helps - and it may just confirm your theories - I've noticed that > when the bad behavior happens, CTRL-Z undoes single keystrokes. > > > On 09/14/2013 02:00 PM, 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] >> <mailto:[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]**> >> <mailto:[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/__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/** >> 17034/match=bhrgunatha<http://article.gmane.org/gmane.comp.lang.racket.user/17034/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> >> > >> >> >> <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> >> >> <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> >> <http://lists.racket-lang.org/**users<http://lists.racket-lang.org/users> >> > >> >> >> >
____________________ Racket Users list: http://lists.racket-lang.org/users
