[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,

[erik quanstrom]

Post by dexen deVries
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

[dexen deVries]

Post by erik quanstrom

Post by dexen deVries
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]

Post by erik quanstrom
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);
---

Post by erik quanstrom
r->regex = regcompnl(r->qarg);

thanks for the tip :D

[erik quanstrom]

Post by dexen deVries

Post by erik quanstrom
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().
$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);
---

Post by erik quanstrom
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

[dexen deVries]

Post by erik quanstrom

Post by dexen deVries
$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);
---

Post by erik quanstrom
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.

[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
data matches 'error[ -]'
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

[dexen deVries]

Post by 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
data matches 'error[ -]'
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,

[erik quanstrom]

Post by dexen deVries
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[ -]'
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