Sublime Forum

20091114 Beta

#21

Perfect. Thanks.

Sweet.

Personally, I’ll probably just ctrl+c, ctrl+i, ctrl+v (cut, find, paste) to get it in.

For reference, both Visual Studio and emacs work in the same way. VS stops the incremental search mode and retains the selection. Emacs ‘isearch-forward’ does the same; hitting enter sets the mark at the start of the selection and the point at the end, and quits the incremental search mode. My preference (just so I don’t have to switch mental models) is for ST to work the same.

Next match.

last text, but with it highlighted so I can overtype it immediately.

0 Likes
#22

I believe Sublime already does this but with some annoyances I wanted to toss out there. The bracket matching and such works inside the find panel. When I try to do a new a find and overtype whatever I was last searching for with an open parenthesis for instance, it encases what was already there in parentheses which can be annoying.

Unrelated to overtype, but also related to bracket matching in the find / replace panels is with regex. A lot of the time I go to enter capture groups or literal parentheses and if I’m already in a capture group the bracket handling likes to eat them if I’m trying to type the same bracket next to each other. So I find myself having to double tap the key often to get it to insert one.

An option to disable bracket matching in the find / replace panels would be great.

0 Likes
#23

Just checked. Last beta where wrapping was working is 20091029. All next betas (20091108, 20091113, 20091115) has this regression.

0 Likes
#24

[quote=“sublimator”]The bindings were each set up with
specifically to avoid this problem.[/quote]

Ah, I see that now… it seems that after the changes to regex key bindings a few betas ago, that context isn’t enough. The basic rules, as they’re implemented are:

  • A sequence key binding must have all its contexts match every step of the way.
  • However, if multiple sequence key bindings share the same prefix, then as long as one of them has its contexts match for the current input, then all bindings get to stay in contention.

So for the input “b,tab”, when the initial b is typed, the normal HTML binding has its contexts match, so both it and the zenHTML binding remain in contention, then when tab is pressed, the selection has been overwritten with “b”, and is thus empty, so the zenHTML binding is now allowed to proceed.

The correct behaviour here is fairly clear, but implementing it going to be fairly complex… anyway, I’ve added it to the todo list.

0 Likes
#25

If this problem will be resolved without temporary hacks, then I am ready to wait, that would not waste your time on temporary solutions :wink:

0 Likes
#26

this is the binding I’m using;

  <binding key="ctrl+shift+i" command="findUnderPrev">
    <context name="isPanelVisible" value="true"/>
  </binding>
0 Likes
#27

[quote=“jps”]

[quote=“sublimator”]The bindings were each set up with
specifically to avoid this problem.[/quote]

Ah, I see that now… it seems that after the changes to regex key bindings a few betas ago, that context isn’t enough. The basic rules, as they’re implemented are:

  • A sequence key binding must have all its contexts match every step of the way.
  • However, if multiple sequence key bindings share the same prefix, then as long as one of them has its contexts match for the current input, then all bindings get to stay in contention.

So for the input “b,tab”, when the initial b is typed, the normal HTML binding has its contexts match, so both it and the zenHTML binding remain in contention, then when tab is pressed, the selection has been overwritten with “b”, and is thus empty, so the zenHTML binding is now allowed to proceed.

The correct behaviour here is fairly clear, but implementing it going to be fairly complex… anyway, I’ve added it to the todo list.[/quote]

Any news?
:frowning:

0 Likes