You are releasing tomorrowās build today!!!
Confirmed crashes fixed here. Cheers!
You are releasing tomorrowās build today!!!
Confirmed crashes fixed here. Cheers!
Luckily, itās already the 15th here in Sydney, so I wonāt have to power on the time machine
Forgot to mention: Ctrl+Enter in the final panel will insert a newline. The find panel can now be resized to show more lines, if required.
New find panel is great! http://forums.disenteria.ru/style_emoticons/default/up.gif
How about multi line in replace panel? http://forums.disenteria.ru/style_emoticons/default/mol.gif
Hmā¦ Wrapping selection with tag+tab now not working (HTML).
For example, select some text, type tag and press tab, should have:
<strong>Some text</strong>
But now have only this:
<strong></strong>
I am the only one who have this problem? http://forums.disenteria.ru/style_emoticons/default/fingal.gif http://forums.disenteria.ru/style_emoticons/default/upset.gif
[quote=āilyaā]
I am the only one who have this problem? http://forums.disenteria.ru/style_emoticons/default/fingal.gif http://forums.disenteria.ru/style_emoticons/default/upset.gif[/quote]
i can confirm that.
Hi, Jon. I have a few points;
First, I like the new panel. It seems more coherent to collapse them into one. I only ever used incremental search anyway. I also like the visual style of the outlines; itās nice to see whatās coming. Is it possible to change the colours here? They are a little hard to see with my colour scheme and Iād like to highlight them a little more. The tmTheme files support a customisable āselectionā property, like this
<dict>
<key>settings</key>
<dict>
<key>selection</key>
<string>#0000dddd</string>
</dict>
</dict>
Is there one for these āpre-foundā regions?
Second, Iāve got ctrl+i burned into my brain now, though, and itās the same mapping I use in Visual Studio, so Iām trying to re-establish the the old mappings. Iām almost there, but havenāt found the perfect match yet. For those who want to copy, this seems to be working pretty well for me;
<binding key="ctrl+i" command="showPanel find"/>
<binding key="ctrl+i" command="findUnder">
<context name="isPanelVisible" value="true"/>
</binding>
Only problem is the āisPanelVisibleā context seems a bit broad, and will work if youāve got, say, the replace panel open. The context
<context name="option" value="isFindWidget"/>
Doesnāt work as I expected, because when you do the find, the focus moves into the main window and I think the isFindWidget option is set to false; this means that hitting ctrl+i over and over does this;
find window/next match/find window/next match
rather than
find window/next match/next match/next match
Third, Iām guessing the find/replace panel is going to be updated to be incremental too? The ability to see whatās going to get found/replaced would be really nice.
Lastly, (I promise,) is the question of what appears in the panel when you open it. The current behaviour seems to be to fill it with the current selection. I donāt know if itās always been like that, but thinking about it now I wonder if it might be nicer to leave it with whatever it had in there last time. Itās worth noting that when I have a regex in the box (say, ālā¦ā) and that happens to have selected the word ālikeā, when I re-open the panel it is now searching for the literal ālikeā and not my original pattern ālā¦ā. This can destroy possibly hard-crafted patterns, so Iād prefer that panel to keep whatever content it had before.
Thatāll teach you to ask for feedback.
First up, the easy ones:
re: what slurping up the selected text when opening the find panel, I think youāre right, thatās generally the wrong thing to do. I think having a separate key binding to copy the current selection into the find buffer would be better.
imo, there are a few situations where the find panel behaviour is debatable:
Changing key bindings alone canāt cover these options properly, so Iāll likely make them explicitly configurable. What the defaults should be is still up in the air though.
I suspect this will be the zen coding plugin, tag+tab will work out of the box with a clean packages directory.
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.
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.
Just checked. Last beta where wrapping was working is 20091029. All next betas (20091108, 20091113, 20091115) has this regression.
[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:
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.
If this problem will be resolved without temporary hacks, then I am ready to wait, that would not waste your time on temporary solutions
this is the binding Iām using;
<binding key="ctrl+shift+i" command="findUnderPrev">
<context name="isPanelVisible" value="true"/>
</binding>
[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:
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?