My guess is that you have a precedence error in your print statement. Add some parens:

print(defined($parser->startrule($mw2->get ("1.0", "500.0")))
? "NO ERROR\n" : "ERROR");
[download]

Correction: no precedence error in the original.

Although, even if that fixes one problem, it may not be the end of your woes.

You may find the posts in this recent meditation enlightening.

And above all else, read the posting FAQ before you send in your next post.

Which suggestion did you try? The last one?  /[^>]*/

What sort of text are you expecting to deal with? What are some positive and negative examples? Japhy's suggestion probably isn't exactly what you want either, but what you really want is not clear.

To help clarify the discussion, here's a complete, runnable script that allows anything to be typed into the Text widget, and then reports parser results whenever the "Check brackets" button is clicked.

#!/usr/bin/perl

use strict;
use Tk;
use Parse::RecDescent;

my $mw = new MainWindow;
my $mw2 = $mw->Text()->pack();
my $mw3 = $mw->Button(-text=>"Check brackets",
                      -command => [ \&parser, $mw2 ]
                      )->pack();
MainLoop;

sub parser {
    my $txt = shift;
    my $grammar = q {
startrule: open text close { print "\n$item[2] " }

open: "<"

text: /([^>]*)/

close: ">"
};
    my $parser = Parse::RecDescent->new($grammar);
    if ( defined( $parser->startrule( $txt->get( "1.0", "end" )))) {
        print "NO ERROR\n";
    } else {
        print "TEXT COULD NOT BE PARSED\n";
    }
}
[download]

When I run that and type anything that begins with "<" and contains a ">" anywhere afterwards, I get "NO ERROR" along with the portion of the string that matched the "text" part of the rule. So each of the following examples, if entered at the beginning of the Text widget, had "NO ERROR":

<tag>        # example 1

<>           # example 2

<<<<<>       # example 3

  <!@#$%^&*(){}[] |`~'"> # example 4

<outer 
   <nested tag>
       tag> extra text.  # example 5
[download]

All it would take to make any of those test strings return a parse error would be: (1) have anything other than "<" as the first non-whitespace character, or (2) remove every ">".

Maybe when you see what gets matched by "text" in your rule, you'll decide that this isn't really the sort of grammar you want, and you should study the RecDescent man page a little more to figure out the appropriate design for the rules that will match only the strings you really want.

(updated to clarify some of the explanation, and corrected the conditions that lead to a parser error)

One more update: since your callback (and my version of it) is currently written to create a new "parser" object every time it's called, maybe what you want (just for doing development, at least) is another text widget where you can paste in and edit the grammar that you pass to Parse::RecDescent. In that case, be sure to check the return value from Parse::RecDescent->new, so you'll know when your editing yields an unusable grammar.