<div dir="ltr">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.<div> </div><div>Robby</div></div><div class="gmail_extra"> <div class="gmail_quote">On Sat, Sep 14, 2013 at 4:03 PM, Neil Toronto <<a href="mailto:neil.toronto@gmail.com" target="_blank">neil.toronto@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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.<div><div class="h5"> On 09/14/2013 02:00 PM, Robby Findler wrote: </div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"> 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 <<a href="mailto:neil.toronto@gmail.com" target="_blank">neil.toronto@gmail.com</a> </div></div><div><div class="h5"> <mailto:<a href="mailto:neil.toronto@gmail.com" target="_blank">neil.toronto@gmail.com</a>>> 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 <<a href="mailto:bhrgunatha@hotmail.com" target="_blank">bhrgunatha@hotmail.com</a> <mailto:<a href="mailto:bhrgunatha@hotmail.com" target="_blank">bhrgunatha@hotmail.com</a>> </div></div> <mailto:<a href="mailto:bhrgunatha@hotmail.com" target="_blank">bhrgunatha@hotmail.com</a><div><div class="h5"> <mailto:<a href="mailto:bhrgunatha@hotmail.com" target="_blank">bhrgunatha@hotmail.com</a>>__>> 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] </div></div> <a href="http://article.gmane.org/____gmane.comp.lang.racket.user/____17034/match=bhrgunatha" target="_blank">http://article.gmane.org/____gmane.comp.lang.racket.user/____17034/match=bhrgunatha</a> <<a href="http://article.gmane.org/__gmane.comp.lang.racket.user/__17034/match=bhrgunatha" target="_blank">http://article.gmane.org/__gmane.comp.lang.racket.user/__17034/match=bhrgunatha</a>><div class="im"> <<a href="http://article.gmane.org/__gmane.comp.lang.racket.user/__17034/match=bhrgunatha" target="_blank">http://article.gmane.org/__gmane.comp.lang.racket.user/__17034/match=bhrgunatha</a> <<a href="http://article.gmane.org/gmane.comp.lang.racket.user/17034/match=bhrgunatha" target="_blank">http://article.gmane.org/gmane.comp.lang.racket.user/17034/match=bhrgunatha</a>>> ____________________ Racket Users list: </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>><div class="im"> <<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>>> ____________________ Racket Users list: <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>> ____________________ Racket Users list: </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>> </blockquote> </blockquote></div> </div>