fluentCODE / ScrawlIssues

Issue Tracker for Scrawl by fluentCODE
14 stars 0 forks source link

Ctrl+Arrows don't handle operators well #146

Closed aarondandy closed 9 years ago

aarondandy commented 9 years ago

Take the following example snippet:

Console.WriteLine("Where the hell am I?" + buildDir.FullName);

When traversing this statement using Ctrl+Left or Ctrl+Right I expect the cursor to either ignore the operator or treat it and the next (previous) symbol just like any other. Instead the cursor will land before (after) the whitespace before (after) the identifier after (before) the operator symbol. Try it on this statement using Ctrl+Right and as you go past the + operator and approach the buildDir identifier you will see the issue.

pauljz commented 9 years ago

Yeah, this is a deceptively tough one because there's lots of different ways to decide what a "word" or symbol is for these kinds of actions. Down the road we intend to expose a whole set of definitions of a word for keybinds - to support things like compatibility modes with other editors. For now we just need to pick a fairly sane default.

What we're doing appears to be pretty similar to some editors (e.g. VS, vim) but not others (e.g. Sublime).

To me, it feels pretty good - and I think at worst it means a few extra Ctrl →s. I'd rather have it be a bit too fine-grained, than not fine-grained enough as a default. That sound reasonable?

Definitely willing to entertain a different default though, if folks think there's a more standard behavior across between some of the other editors.

aarondandy commented 9 years ago

Yeah and I don't mind having to press the arrows + ctrl more but the problem is that it totally skipped for example, moving from the left to the right, the front of buildDir. Something about the + prevents the cursor from landing on that identifier, instead it ends up on the space before it.

pauljz commented 9 years ago

Yeah, I see what you mean. I think this is still working as intended though. When you're doing Ctrl → you're advancing to the end of the current word/token, not the start of the next word/token. If the cursor is positioned before some whitespace, it'll first skip the whitespace, then skip to the end of the current word.

Gonna close this one for now. Like I said, down the road we'll have some variants you can configure in the keybinds to make this work differently depending on preference, but for now we gotta just pick a behavior and there doesn't seem to be any consistency between other platforms/editors.