On 24/09/2005, at 8.26, José Campos wrote:
In revision 469, when I try Find : this Replace : \t$0 The resuls is "\tthis" instead of a tabulation as expected before"this"
Is it a new feature? ;-)
heh… I was actually thinking just yesterday, maybe I should add \t to the new replace string syntax :) I'll put it in again for next version.
I didn't keep the escape characters from previous syntax, except \n -- let me know if I need to add others. Also, the new syntax btw also support \l and \u (for changing case only of first letter), where I think the old contains only \L and \U -- I'll update the manual page on this also for next rev.
Allan Odgaard allan@macromates.com wrote:
I didn't keep the escape characters from previous syntax, except \n
Why?
-- let me know if I need to add others.
At least you kept the Character classes?
Also, the new syntax btw also support \l and \u (for changing case only of first letter), where I think the old contains only \L and \U --
\U \u \L or \l do not seem to work correctly in the "find" box (but work in the "replace" box)
And, in the older versions, when "Regular expression" was checked in the "Find options" box, the other choices ("Ignore case" and "Wrap around") were not available. In this version, they are. Is it a feature?
I'll update the manual page on this also for next rev.
OK, nice, because it's quite confusing :)
Thanks a lot
On 24/09/2005, at 14.02, José Campos wrote:
I didn't keep the escape characters from previous syntax, except \n
Why?
Because majority of them really makes no sense. Like vertical tab, bell a.s.o.
-- let me know if I need to add others.
At least you kept the Character classes?
This is the _replace_ string syntax.
Also, the new syntax btw also support \l and \u (for changing case only of first letter), where I think the old contains only \L and \U --
\U \u \L or \l do not seem to work correctly in the "find" box(but work in the "replace" box)
Yes, I was speaking of the replace string syntax. The actual regexp syntax is now that of Oniguruma [1], since that's the library I use -- it means a few things are now gone, like these, but you can use [[:upper:]] and [[:lower:]], conditions (in searches, not replacements), < and > (but there's still \b), (?s) is now (?m), (? R) recursion, but there's the (much better) subexp calls, and probably a few more subtleties.
On the bright side there's also many advantages of Oniguruma, and there was just no way I could find time to fix up my own regexp lib.
And, in the older versions, when "Regular expression" waschecked in the "Find options" box, the other choices ("Ignore case" and "Wrap around") were not available. In this version, they are. Is it a feature?
Yes, it's in the release notes -- though wrap around was always possible with regexps.
I'm wondering how you managed that. You told me that you couldn't use Oniguruma for finding because you were storing each line individually in memory and Oniguruma wanted the entire text to be one contiguous memory block. How'd you get around that?
On Sep 24, 2005, at 9:35 AM, Allan Odgaard wrote:
The actual regexp syntax is now that of Oniguruma [1], since that's the library I use
On 24/09/2005, at 16.50, Kevin Ballard wrote:
I'm wondering how you managed that. You told me that you couldn't use Oniguruma for finding because you were storing each line individually in memory and Oniguruma wanted the entire text to be one contiguous memory block. How'd you get around that?
On-the-fly conversion :/
I love you oniguruma!!!!!
I must be seriously stinking geeky to find the most enjoyment in life (besides obvious things ;) ) from regular expressions, SQL & syntax coloring. That can't be healthy. But, anyway...
Quick snazyness you can now do with your friend oniguruma:
Turn the entire document into a snippet! WOO! Record a macro that searches for: (?<==")[^"]*(?=")|(?<==')[^']*(?=') Save it. Give it a scope of 'meta.tag, declaration.tag' (or more specifically 'text.html meta.tag -source, text.html declaration.tag -source'). Give it a shortcut of option-tab.
SHEBANG! Your HTML is now a giant snippet.
This wasn't possible before because the search regex wasn't compatible with zero-width-positive-lookbehind. But our new friend oniguruma has given us even more super-powers. It's like being superman and someone handing you green lanterns ring. --- I have attached the Macros that I've created HTML Attribute NEXT & PREV, HTML Attribute Value NEXT & PREV. I also made a quick HTML Attribute ADD Snippet & Macro that goes to the end of the current tag and adds a generic html snippet to the end, but i didn't include that one.
SLIGHT PROBLEM: (oh, you knew it was coming) I wanted to implement using the tab key to tab to the next occurrence of the next type of thing you have selected (inside an attribute value tabs to the next attribute value; inside an attribute name tabs to select the next attribute name value pair, etc..)
The two problems are: 1: We need to have dynamic scopes. Taking over the tab key equivalent takes it away from snippets too. If I have a command that runs inside of HTML attribute values. My HTML snippets stop working properly. We need some way of eliminating those commands and such from inside of running snippets. The dynamic.snippet scope you mentioned earlier would be ideal for this situation. You could even have running snippets have a special color. I love being able to do boolean logic with scopes. SWEET!!!
2: Selections carry the scope of the last character selected. I tried to set a macro for next html attribute & next html attribute value. Once you tab to the first html value (EG: name="value") it picks up the scope of the string (the " being the last character in the selection.) Then only the next html attribute value macro (EG: the value in name="value") would fire when hitting the command twice. The workaround I made was to either: A) Change the html attribute value deal to select the space after the closing quote mark (thereby changing the scope of the selection back to html attribute). This didn't work because there is no space to select at the end of an attribute and it was just 'wrong' in my opinion. B) Change the key equivalent of one of them to something else. This is what i've chosen.
I'm not sure if this one is really the wrong behavior or what. It seems logical to pick up the scope of the last character selected. I can't really think of any other way of handling that.
All in all... I am so incredibly delighted... Oh yes. so much.
On 26/09/2005, at 7.43, thomas Aylott wrote:
[...] I have attached the Macros [...]
Would have made it easier for us if they were in a tmbundle :)
[...] I wanted to implement using the tab key to tab to the next occurrence [...] 1: We need to have dynamic scopes. Taking over the tab key equivalent takes it away from snippets too.
Ah yes, I see. While they aren't around the corner (dynamic scopes) I think the case for them is strong.
I also have a slightly related problem: when first going to a placeholder, the entire thing is selected, here I don't want the smart-typing pairs to “wrap selection” when used, since it's unlikely that I want to wrap the default placeholder text, more likely I want to start a string or similar -- though it is less transparent to me exactly how scoping the smart typing (keys) should solve this (after the introduction of dynamic scopes), but it would be nice if they could somehow do it :)
2: Selections carry the scope of the last character selected. [...] I'm not sure if this one is really the wrong behavior or what. It seems logical to pick up the scope of the last character selected. I can't really think of any other way of handling that.
I've had some “concerns” about this myself. I think in most situations when the entire scope of something is selected, the current scope should really not include what's exclusive for the selected text, since with a selection, we perform an operation _on_ the selection, and that is done in the context of being “outside” it.
For example if we select <?php … ?> in HTML and use Toggle Comment, we want it to be commented as HTML, not PHP.
I am however also unsure how to “solve” it. One heuristic could be to look at the scope before and after the selection, and if these are identical, use that. So when we select something entirely, the scope excludes what's special for the stuff we selected. But if OTOH we select a partial string (or similar), the scope will include string.
On 27/09/2005, at 5.14, Allan Odgaard wrote:
I am however also unsure how to “solve” it. One heuristic could be to look at the scope before and after the selection, and if these are identical, use that. So when we select something entirely, the scope excludes what's special for the stuff we selected. But if OTOH we select a partial string (or similar), the scope will include string.
Should say: partially select a string.
On Sep 26, 2005, at 11:14 PM, Allan Odgaard wrote:
2: Selections carry the scope of the last character selected. [...] I'm not sure if this one is really the wrong behavior or what. It seems logical to pick up the scope of the last character selected. I can't really think of any other way of handling that.
I've had some “concerns” about this myself. I think in most situations when the entire scope of something is selected, the current scope should really not include what's exclusive for the selected text, since with a selection, we perform an operation _on_ the selection, and that is done in the context of being “outside” it.
For example if we select <?php … ?> in HTML and use Toggle Comment, we want it to be commented as HTML, not PHP.
I am however also unsure how to “solve” it. One heuristic could be to look at the scope before and after the selection, and if these are identical, use that. So when we select something entirely, the scope excludes what's special for the stuff we selected. But if OTOH we select a partial string (or similar), the scope will include string.
Ok, this doesn't seem to be working out in real life.
i've got some html like this: <b>text</b> the scope for the 'text' when selecting the entire word is coming up as 'declaration.tag.html' also: <tag attribute="Value" attribute="Value" attribute="Value" /> the scope for the ' attribute="Value"' in the middle when selecting from the whitespace to the last quote is coming up as 'string.quoted.double'
we've solved 1 problem and created another. oi.
I don't know what the right logic should be.
i've got some html like this: <b>text</b> the scope for the 'text' when selecting the entire word is coming up as 'declaration.tag.html' also:
<tag attribute="Value" attribute="Value" attribute="Value" /> the scope for the ' attribute="Value"' in the middle when selecting from the whitespace to the last quote is coming up as 'string.quoted.double'
we've solved 1 problem and created another. oi.
I don't know what the right logic should be.
As I see it, the scope is defined by the caret position, not the selection.
Soryu
On 04/11/2005, at 19.58, thomas Aylott wrote:
Ok, this doesn't seem to be working out in real life. [...] we've solved 1 problem and created another. oi.
I don't know what the right logic should be.
I see -- I think a solution would be to look at the scope before/ after the selection, and the scope of the first/last character in the selection, and then use the common prefix of these 4 scopes, as the scope of the selection.
-
Allan Odgaard -
Allan Odgaard -
jose.campos+tm＠galacsys.com -
Kevin Ballard -
Soryu -
thomas Aylott