[9fans] acme + plumber question

[9fans] acme + plumber question

[dexen deVries]

hi list,


certain program† i run in acme produces error messages in form ``$ERROR in 
$FILE on line $LINENO''. i have a plumber rule that opens $FILE in the acme 
window, but i'd like it to also position at line $LINENO. without having to 
perform full mouse sweep :D

the question: is there a sensible way to access text /around/ text plumbed  
from acme (i.e., context), either from plumber rules or from plumber client 
program?


cheers,
-- 
dexen deVries

[[[↓][→]]]

† yep, the PHP CLI runtime

Re: [9fans] acme + plumber question

[erik quanstrom]

> certain program† i run in acme produces error messages in form ``$ERROR in 
> $FILE on line $LINENO''. i have a plumber rule that opens $FILE in the acme 
> window, but i'd like it to also position at line $LINENO. without having to 
> perform full mouse sweep :D
> 
> the question: is there a sensible way to access text /around/ text plumbed  
> from acme (i.e., context), either from plumber rules or from plumber client 
> program?

does it not work to write a plumb rule that parses the whole line?   then
it would possible to double-click at the edges of the line to select the whole
line.

- erik

Re: [9fans] acme + plumber question

[dexen deVries]

On Friday 05 of October 2012 07:49:57 erik quanstrom wrote:
> > certain program† i run in acme produces error messages in form ``$ERROR in
> > $FILE on line $LINENO''. i have a plumber rule that opens $FILE in the
> > acme
> > window, but i'd like it to also position at line $LINENO. without having
> > to
> > perform full mouse sweep :D
> > 
> > the question: is there a sensible way to access text /around/ text plumbed
> > from acme (i.e., context), either from plumber rules or from plumber
> > client
> > program?
> 
> does it not work to write a plumb rule that parses the whole line?   then
> it would possible to double-click at the edges of the line to select the
> whole line.

that would do the trick indeed, except when i select whole line (by double-
click on line edge), it doesn't seem to work with the plumber. either is not 
sent by acme, or it doesn't get matched by the simplest possible rule:

data matches '.*error.*'
type is text
plumb start $TEST_SCRIPT $0

which works a-ok when i manually select text on the line. perhaps plumber 
treats LF character specially?

($TEST_SCRIPT is a small helper to test whether the rule matched)


fwiw, that's p9p acme and plumber.


-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] acme + plumber question

[dexen deVries]

On Friday 05 of October 2012 07:49:57 erik quanstrom wrote:
> does it not work to write a plumb rule that parses the whole line?   then
> it would possible to double-click at the edges of the line to select the
> whole line.

ok, got it working. the important bit is regcompnl() vs. regcomp().


simple problems are simple:

$PLAN9/src/cmd/plumb $ 9 diff -c -n rules.c-orig rules.c
X-rules.c:363 c rules.c:363
<                       r->regex = regcomp(r->qarg);
---                                                                                                                                                                                        
>                       r->regex = regcompnl(r->qarg);                                                                                                                                     


thanks for the tip :D
-- 
dexen deVries

[[[↓][→]]]

Re: [9fans] acme + plumber question

[erik quanstrom]

On Fri Oct  5 08:45:47 EDT 2012, dexen.devries@gmail.com wrote:
> On Friday 05 of October 2012 07:49:57 erik quanstrom wrote:
> > does it not work to write a plumb rule that parses the whole line?   then
> > it would possible to double-click at the edges of the line to select the
> > whole line.
> 
> ok, got it working. the important bit is regcompnl() vs. regcomp().
> 
> 
> simple problems are simple:
> 
> $PLAN9/src/cmd/plumb $ 9 diff -c -n rules.c-orig rules.c
> X-rules.c:363 c rules.c:363
> <                       r->regex = regcomp(r->qarg);
> ---                                                                                                                                                                                        
> >                       r->regex = regcompnl(r->qarg);                                                                                                   

you'll probablly rather put a literal newline in your rule.
you probablly don't want any surprises in other rules that
expect . not to match \n.  ☺

- erik

Re: [9fans] acme + plumber question

[dexen deVries]

On Friday 05 of October 2012 09:04:55 erik quanstrom wrote:
> > $PLAN9/src/cmd/plumb $ 9 diff -c -n rules.c-orig rules.c
> > X-rules.c:363 c rules.c:363
> > <                       r->regex = regcomp(r->qarg);
> > ---
> > 
> > >                       r->regex = regcompnl(r->qarg);
> 
> you'll probablly rather put a literal newline in your rule.
> you probablly don't want any surprises in other rules that
> expect . not to match \n.  ☺

good point.


i've tried in two ways, both failed: data matches='foo
' (literal newline) and data matches='foo\n' (C-style escape sequence). first 
trips plumber's parser, the other doesn't match anything -- perhaps \n is 
taken literaly.


-- 
Mateusz Jan Przybylski,

Re: [9fans] acme + plumber question

[erik quanstrom]

> i've tried in two ways, both failed: data matches='foo
> ' (literal newline) and data matches='foo\n' (C-style escape sequence). first
> trips plumber's parser, the other doesn't match anything -- perhaps \n is
> taken literaly.

it looks like plumber's failure of vision.  regexps don't take escapes like that.
and on the other hand you can't say \ + literal newline, either.  plumber
misparses that.

however, i thought of a really sneaky cheat, that is almost correct.  since
\n is 0a, and we almost never see 09 or 0b (ht and vt), we could build a
sneaky character class to elude the parser:

data	matches	'error[	-\v]'
plumb	start	window

and i've verified this does work on plan 9.  a proper fix would be to
change the string parser in plumber to convert '\' + 'n' to a newline.

(but i do feel dirty.)

- erik

Re: [9fans] acme + plumber question

[erik quanstrom]

> however, i thought of a really sneaky cheat, that is almost correct.  since
> \n is 0a, and we almost never see 09 or 0b (ht and vt), we could build a
> sneaky character class to elude the parser:
>
> data	matches	'error[	-\v]'
> plumb	start	window

i didn't think hard enough about mailers mangling this.  what i had was

data	matches	'error[0x09-0x11]

of course, replace 0x09 and 0x11 with their literal codepoints.

- erik

Re: [9fans] acme + plumber question

[dexen deVries]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Friday 05 of October 2012 10:34:04 erik quanstrom wrote:
> > however, i thought of a really sneaky cheat, that is almost correct. 
> > since
> > \n is 0a, and we almost never see 09 or 0b (ht and vt), we could build a
> > sneaky character class to elude the parser:
> > 
> > data	matches	'error[	-\v]'
> > plumb	start	window
> 
> i didn't think hard enough about mailers mangling this.  what i had was
> 
> data	matches	'error[0x09-0x11]
> 
> of course, replace 0x09 and 0x11 with their literal codepoints.

it's succinct, it works and yes, it went through correctly :D


another possible way -- separate verb for multiline match.


meta -- is it ok to send Git patches as an attachment?


cheers,
-- 
dexen deVries

[[[↓][→]]]

[-- Attachment #2: plumber-multiline.patch --]
[-- Type: text/x-patch, Size: 1434 bytes --]

commit fb99b4872ee3252bea88cf1f187c6cbedeba085b
Author: dexen deVries <dexen.devries@gmail.com>
Date:   Fri Oct 5 16:45:19 2012 +0200

    usability: provide multiline matching in plumber

diff --git a/src/cmd/plumb/match.c b/src/cmd/plumb/match.c
index 5a4cd88..0dcc664 100644
--- a/src/cmd/plumb/match.c
+++ b/src/cmd/plumb/match.c
@@ -283,6 +283,7 @@ matchpat(Plumbmsg *m, Exec *e, Rule *r)
 	case VIsfile:
 		return verbisfile(r->obj, m, r, e, ~DMDIR, DMDIR, &e->file);
 	case VMatches:
+	case VMatchesMultiline:
 		return verbmatches(r->obj, m, r, e);
 	case VSet:
 		verbset(r->obj, m, r, e);
diff --git a/src/cmd/plumb/plumber.h b/src/cmd/plumb/plumber.h
index c8f3081..cd00680 100644
--- a/src/cmd/plumb/plumber.h
+++ b/src/cmd/plumb/plumber.h
@@ -29,6 +29,7 @@ enum
 	VIsdir,
 	VIsfile,
 	VMatches,
+	VMatchesMultiline,
 	VSet,
 	VStart,
 	VTo
diff --git a/src/cmd/plumb/rules.c b/src/cmd/plumb/rules.c
index 4da4bb2..d815db9 100644
--- a/src/cmd/plumb/rules.c
+++ b/src/cmd/plumb/rules.c
@@ -64,6 +64,7 @@ char *verbs[] =
 	"isdir",
 	"isfile",
 	"matches",
+	"matchesmultiline",
 	"set",
 	"start",
 	"to",
@@ -363,6 +364,10 @@ parserule(Rule *r)
 			r->regex = regcomp(r->qarg);
 			return;
 		}
+		if(r->verb == VMatchesMultiline){
+			r->regex = regcompnl(r->qarg);
+			return;
+		}
 		break;
 	case OPlumb:
 		if(r->verb!=VClient && r->verb!=VStart && r->verb!=VTo)