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.

In reply to Re^2: ParseRecdescent and pattern matching problem by graff
in thread ParseRecdescent and pattern matching problem by hak0983

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.