Matching other than brackets

Ideas for new features

Moderators: AmigoJack, bbadmin, helios, Bob Hansen, MudGuard

Post Reply
User avatar
daddyone
Posts: 10
Joined: Fri Nov 21, 2003 2:13 pm
Location: Denmark

Matching other than brackets

Post 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
User avatar
CyberSlug
Posts: 120
Joined: Sat Oct 04, 2003 3:41 am

Post 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!
User avatar
daddyone
Posts: 10
Joined: Fri Nov 21, 2003 2:13 pm
Location: Denmark

Post 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
User avatar
CyberSlug
Posts: 120
Joined: Sat Oct 04, 2003 3:41 am

Post by CyberSlug »

:oops: 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?
User avatar
MudGuard
Posts: 1295
Joined: Sun Mar 02, 2003 10:15 pm
Location: Munich, Germany
Contact:

Post 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
User avatar
Bob Hansen
Posts: 1516
Joined: Sun Mar 02, 2003 8:15 pm
Location: Salem, NH
Contact:

Post by Bob Hansen »

Can anyone think of workarounds for the time being?
:idea: 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.
Hope this was helpful.............good luck,
Bob
User avatar
talleyrand
Posts: 624
Joined: Mon Jul 21, 2003 6:56 pm
Location: Kansas City, MO, USA
Contact:

Post 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.
I choose to fight with a sack of angry cats.
User avatar
CyberSlug
Posts: 120
Joined: Sat Oct 04, 2003 3:41 am

Post 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.....
User avatar
MudGuard
Posts: 1295
Joined: Sun Mar 02, 2003 10:15 pm
Location: Munich, Germany
Contact:

Post 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 
User avatar
daddyone
Posts: 10
Joined: Fri Nov 21, 2003 2:13 pm
Location: Denmark

Post 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
User avatar
ramonsky
Posts: 88
Joined: Fri Nov 14, 2003 10:54 am

Post 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
Last edited by ramonsky on Thu Dec 11, 2003 4:09 pm, edited 1 time in total.
User avatar
talleyrand
Posts: 624
Joined: Mon Jul 21, 2003 6:56 pm
Location: Kansas City, MO, USA
Contact:

Post 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.
I choose to fight with a sack of angry cats.
User avatar
ramonsky
Posts: 88
Joined: Fri Nov 14, 2003 10:54 am

Post 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.
Last edited by ramonsky on Thu Dec 11, 2003 4:09 pm, edited 1 time in total.
User avatar
daddyone
Posts: 10
Joined: Fri Nov 21, 2003 2:13 pm
Location: Denmark

Post 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
Post Reply