Page 1 of 1
Matching other than brackets
Posted: Fri Nov 21, 2003 2:43 pm
by daddyone
Hi,
I find the bracket matching feature extremely useful. But I would really like to have the ability of matching more then one-character sets. Specifically I would like to match if/end if and begin/end.
/Michael Ringbo
Posted: Thu Nov 27, 2003 6:47 am
by CyberSlug
This is possible by recording a macro for a regular expression search....
Here's an example for begin-end:
CREATING THE MACRO:
1) Open a document that contains begin-end blocks of code.
2) Highlight the "end" keyword.
3) Press the Macro record button.
4) Click Search, Find
5) Type in ^[[:blank:]]*begin$
Note: Do not include the ^ and $ if other text may be on the same line with the begin keyword.
6) Make "regular expression" box checked, and also check the "Up" box.
7) Click the Find Next button. The match should now be highlighted.
8) Close the find dialog window, and stop the macro recording.
USING THE MACRO:
After you type an end keyword, highlight it and run the macro from the macro menu. You can also assign a keyboard shortcut to run the macro.
Hope that helps
P.S. Now I realize why TextPad really needs editable macros!
Posted: Thu Nov 27, 2003 8:28 am
by daddyone
Hmmmm....
I haven't tried your suggestion out, but I doubt it would be able to do the right match in scenarios like this:
begin
bla-bla-bla
begin
bla-bla-bla
end;
end;
I guess your solution would find the nearest "begin" when matching from the last "end;". Isn't it so?
/Michael
Posted: Thu Nov 27, 2003 10:15 pm
by CyberSlug
I can't believe I overlooked that!
Anyway, I do agree this feature should be added to TextPad. Can anyone think of workarounds for the time being?
Posted: Thu Nov 27, 2003 10:56 pm
by MudGuard
This is much more complicated than it looks at first:
Imagine the following code:
Code: Select all
begin
/* this is the begin */
var a = "now this is another begin, isn't it?";
var b = 2; //to begin with, set b to the value of 2
var begin = 17; //now we have another begin...
some other stuff
end
Posted: Fri Nov 28, 2003 2:21 am
by Bob Hansen
Can anyone think of workarounds for the time being?
How about something like this?
Run macro to:
1.. Temporarily replace left brackets "
[" with another character "
~".
2.. Temporarily replace right brackets "
]" with another character "
~~".
3. Temporarily replace RegEx "^[:space:]*begin" with "
[".
4. Temporarily replace Regex "^[:space:]*end if" with "
] if".
5. Temporarily replace Regex "^[:space:]*end" with "
]".
Find Matching brackets (CTRL-M). Work as necessary till done.
Run Macro to:
5. Replace "
] if" with Regex ^[:space:]end if.
5. Replace "
]" with Regex ^[:space:]end.
6. Replace "
[" with Regex ^[:space:]begin.
7. Replace "
~~" with "
]".
8. Replace "
~" with "
[".
Just a concept, please ignore syntaxes, using
" " for clarity only.
Posted: Fri Nov 28, 2003 4:27 am
by talleyrand
No offense, but it seems kludgey. Granted, it is a workaround but even as such, just doesn't feel. Not that I have any better ideas at the moment.
If this is something they integrate into TP, I would think using the class syntax file would be more appropriate. That way it would be more generic and could take advantage of excluding comments and blocks within strings. Fortunately for me, I've mostly moved out of languages that use words for their blocking but I could see the usefulness of it.
Posted: Fri Nov 28, 2003 6:05 am
by CyberSlug
MudGuard wrote:This is much more complicated than it looks at first:
Imagine the following code:
Code: Select all
begin
/* this is the begin */
var a = "now this is another begin, isn't it?";
var b = 2; //to begin with, set b to the value of 2
var begin = 17; //now we have another begin...
some other stuff
end
That's one think I actually did consider in my original suggestion by using the ^ and $ anchor tags in the regular expression.
Would the ctags program maybe be helpful? Otherwise, one could try writing a program that parses the contents of the active buffer, counts the nestings of keywords, and then returns the line number of the matching keyword.....
Posted: Fri Nov 28, 2003 10:49 am
by MudGuard
Except for the single line comment, all other examples may have a line break before the begin (in some programming languages, strings may go across multiple lines), so you still have:
Code: Select all
begin
/* this is the
begin
*/
var a = "now this is another
begin
, isn't it?";
var
begin
= 17;
some other stuff
end
Posted: Fri Nov 28, 2003 12:03 pm
by daddyone
Hi,
I agree that this should be included in the syntax file. It seems to be the only appropriate place in order to cover the different languages.
Regarding the discussion about "begin" in a comment line: We have the same problem with brackets today so this is fairly an argument not to include this functionality.
/Michael
Posted: Fri Nov 28, 2003 3:38 pm
by ramonsky
Just wondering whether or how you could write a syntax file for matching the beginning and end of block in the language
Python. For those who don't know, Python uses neither braces, nor begin/end to delimit blocks. Instead, it uses line-oriented INDENTATION. Basically, if a non-blank line is indented by N spaces and the previous non-blank line was indented by <N spaces then this is the beginning of a block. Similarly, if a non-blank line is indented by N spaces and the following non-blank line was indented by <N spaces then this is the end of a block. Sort of like this
Code: Select all
first block
more stuff in first block
second block
more stuff in second block
third block
more stuff in third block
an extra-long line in the third block which uses a contnuation \
character to continue the logical onto the next physical line
even more stuff in the third block
even more stuff in second block
oh, and blank lines are ignored
yet more stuff in the first block
(:shock: That's not valid Python, obviously).
Jill
Posted: Fri Nov 28, 2003 4:21 pm
by talleyrand
Jill, I think I love you.
I too was thinking how you could do block matching in Python when I posted. It might actually be easier to implement since it'd pretty much be a matter of aligning columns. How to specify that in a generic way (syntax file) has got me stumped.
I had never thought about whether TP matches braces in comments until daddyone pointed it out. Since it does match in those cases, that leads me to believe the brace matching logic is fairly trivial. I think in all honesty to do what we are asking, it'll take a fair amount of work because TP will need to be able to
understand what it's presenting. It'd need to actually parse the file into tokens and analyze them in their context. Anybody know if other editor or IDE does this? It looks like Visual Studio (6.0 or .Net) doesn't allow for it but then again I'm not terribly fluent in using them for code development.
Posted: Fri Nov 28, 2003 4:53 pm
by ramonsky
That's nice. Your place or mine? 8)
Panicke ye nott. I think TP will not need to parse things into tokens. It's much simpler than that. TP already knows what is a comment and what is not, or it wouldn't be able to paint them a different color. I seem to remember there's a separate thread somewhere about using the color information (strictly speaking, the category information from which a character derives its color) in Find and Replace. Using that same information to avoid looking for matching brackets and things in comments seems just as plausible, without having to do any nasty parsing beyond what is done already.
At least, I think so.
Jill.
Posted: Wed Dec 10, 2003 10:30 am
by daddyone
I really can't see the big deal.
Using the syntax file we could have an entry like this:
KeywordMatch = ["begin" "end;"] ["loop" "end loop;"] ["if" "end if;"]
where each of the []-sections define a pair of keywords for matching. Of course it should be possible to costumize the list in order to add or remove pairs of keywords. In the list shown here I included the semicolons in order to prevent matches between (for example) "begin" and "end loop;"
/Michael