On Sun, Sep 15, 2013 at 8:39 AM, Matthew Flatt wrote:
> I don't remember my rationale in detail, but I think it was something
> like: a sequence may reflect something the user requested, in which
> case it should always interrupt whatever else the user was doing, or
> the sequence is not due to a
I don't remember my rationale in detail, but I think it was something
like: a sequence may reflect something the user requested, in which
case it should always interrupt whatever else the user was doing, or
the sequence is not due to a user action, in which case it shouldn't
interrupt the user's ac
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, ass
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
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 wrote:
> I appreciate your work on this, and also how tiny the test case is. :
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
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
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. S
On Sat, Sep 14, 2013 at 09:47:29AM -0700, Wayne Iba wrote:
> I've noticed a similar, perhaps related, issue. I'm using emacs bindings
> and when the find/replace bar is showing, I am unable to place the mark
> with ctrl-space and then move the cursor to select a region. The
> shift-arrows work fo
I've noticed a similar, perhaps related, issue. I'm using emacs bindings
and when the find/replace bar is showing, I am unable to place the mark
with ctrl-space and then move the cursor to select a region. The
shift-arrows work for selecting a region, but the place-the-mark-and-move
does not.
My
That doesn't seem to be it for me. Could it be that switching back and
forth causes you to go into the bad mode? That is, if you do this:
- open the find/replace window
- click to set the focus to the definitions window
- type left and then right (without the shift key down)
- shift-left twice
- s
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
My key bindings use Ctrl+F to open Find/replace and to return to the
definitions window. I use that to open find and to return to definitions
all the time (not mouse clicks.)
Your key sequence works correctly, but only when the Replace text box,
Replace and Skip buttons are hidden.
Once they
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 wrote:
> I'm having a problem ed
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 sele
15 matches
Mail list logo
