24 Sep
2005
24 Sep
'05
10:55 a.m.
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.
24 Sep
24 Sep
12:02 p.m.
New subject: [rev 469] where hass \t gone?
Allan Odgaard <allan(a)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
--
Jo <W:00°04'37" ;
N:47°15'36">
1....'....12.....'....24.....'....36.....'....48.....'....60.....'....72
1:35 p.m.
New subject: [rev 469] where hass \t gone?
On 24/09/2005, at 14.02, José Campos wrote:
Because majority of them really makes no sense. Like vertical tab,
bell a.s.o.
This is the _replace_ string syntax.
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.
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?
Yes, it's in the release notes -- though wrap around was always
possible with regexps.
[1] http://www.geocities.jp/kosako3/oniguruma/doc/RE.txt
2:50 p.m.
New subject: [rev 469] where hass \t gone?
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
--
Kevin Ballard
kevin(a)sb.org
http://www.tildesoft.com
http://kevin.sb.org
3:17 p.m.
New subject: [rev 469] where hass \t gone?
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 :/
26 Sep
26 Sep
5:43 a.m.
New subject: oniguruma is your friend!!!!
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.
27 Sep
27 Sep
3:14 a.m.
New subject: oniguruma is your friend!!!!
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.
3:16 a.m.
New subject: oniguruma is your friend!!!!
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.
4 Nov
4 Nov
6:58 p.m.
New subject: Scopes of DOOM!
On Sep 26, 2005, at 11:14 PM, Allan Odgaard wrote:
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.
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. 
8:44 p.m.
New subject: Scopes of DOOM!
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
5 Nov
5 Nov
9:43 a.m.
New subject: Scopes of DOOM!
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.
5598
days inactive
5640
days old
10 comments
6 participants
participants (6)
-
Allan Odgaard -
Allan Odgaard -
jose.campos+tm＠galacsys.com -
Kevin Ballard -
Soryu -
thomas Aylott