[9fans] question re acme and plumber

[9fans] question re acme and plumber

[James A. Robinson]

If I add a plumber rule for javac output:

type is text
data matches '\[ERROR\] ([.a-zA-Z¡-�0-9_/\-]+\.java):\[([0-9]+),[0-9]+\] .*'
arg isfile $1
data set $file
attr add addr=$2
plumb to edit
plumb client $editor

I can sweep a line (short of its trailing newline):

[ERROR] /Users/jimr/proj/github/src/github.com/.../Cpio.java:[151,31]
';' expected

in acme using button 3 and open up Cpio.java:151.  Is there any way
for me to just button 3 click within the text of the filename to get
the same behavior?

Also I had hoped I could do something like

attr add addr=$2'-+#'$3

(assuming I captured the 2nd number in the data matches line), but it
turns out Java is producing a 'column number', which means a tab is +8
column positions.  My only thought upon discovering that was that I'd
have to write some custom program to pick out the $1:$2 and evaluate
it to determine what the actual character count was.  Anyone have a
better suggestion?  The sam(1) addressing appeared to, very sensibly
imo, limit itself to talking about lines, character counts, and
regular expressions...

Jim

Re: [9fans] question re acme and plumber

[Martin Kühl]

On Wed, 10 Jul 2019 at 18:48, James A. Robinson <jim.robinson@gmail.com> wrote:
> in acme using button 3 and open up Cpio.java:151.  Is there any way
> for me to just button 3 click within the text of the filename to get
> the same behavior?

I believe when you 3 a single position
acme selects the "word" around that position and sends that to plumber,
and it's pretty lenient about word characters but doesn't consider spaces.

It might work if you adjust your rule to read

    data matches '([.a-zA-Z¡-�0-9_/\-]+\.java):\[([0-9]+),[0-9]+\]'

but I'm not sure if it considers square brackets word boundaries.

HTH,
Martin

Re: [9fans] question re acme and plumber

[James A. Robinson]

Thank you.  I did try using the shorter match for just the filename,
but while that works fine in terms of sending it via plumb(1) acme
doesn't seem to know what to do with it when I click within the line.

Acme only processes it if I sweep the entire match.  So that's what
led me to expand the plumber rule so I could select the bulk of the
line (it's easier for me to select).

Looking at src/cmd/acme/look.c I see that look3 has a section
discussing sending a whitespace delimited section to the plumber,
but it is guarded by a check of (plumbsendfd >= 0), and I see the
initialization of plumbsendfd in my copy of acme.c is commented
out.

I'm going to see how my copy differs from the latest, maybe that
will give me a clue as to what's changing in this area of the
code.

Jim

Re: [9fans] question re acme and plumber

[James A. Robinson]

Well, I can see this is getting called:

look.c:187: if(m->ndata<messagesize-1024 &&
plumbsendtofid(plumbsendfid, m) >= 0){

and the m->data is the full line, including the trailing
".java:[<lineno>,<colno>]" data.

So it's certainly appears to be sending the data to the plumber.
But I don't get the same behavior from acme as when I send the
same text I see in m->data to plumb(1) directly on the command
line.

Jim

Re: [9fans] question re acme and plumber

[Ole-Hjalmar Kristensen]

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

I think the text that is selected and sent by button 3 is hard-coded in
acme, so the square brackets acts as delimiters. If you click on the text
to the left of the brackets, the plumber will not see the brackets or
what's inside them. If you sweep and select yourself, the whole selection
goes to the plumber.

tor. 11. jul. 2019, 23.30 skrev James A. Robinson <jim.robinson@gmail.com>:

> Well, I can see this is getting called:
>
> look.c:187: if(m->ndata<messagesize-1024 &&
> plumbsendtofid(plumbsendfid, m) >= 0){
>
> and the m->data is the full line, including the trailing
> ".java:[<lineno>,<colno>]" data.
>
> So it's certainly appears to be sending the data to the plumber.
> But I don't get the same behavior from acme as when I send the
> same text I see in m->data to plumb(1) directly on the command
> line.
>
> Jim
>
>

[-- Attachment #2: Type: text/html, Size: 1204 bytes --]

Re: [9fans] question re acme and plumber

[James A. Robinson]

Thanks, I stopped digging after that and just added a shell script
wrapper to reformat the lines in question ¯\_(ツ)_/¯

$ cat ~/bin/mvn
#!/bin/sh
/usr/local/bin/mvn "$@" | sed 's!\.java:\[\([0-9]*\),[0-9]*\]!.java:\1!g';

On Wed, Jul 24, 2019 at 2:19 PM Ole-Hjalmar Kristensen
<ole.hjalmar.kristensen@gmail.com> wrote:
>
> I think the text that is selected and sent by button 3 is hard-coded in acme, so the square brackets acts as delimiters. If you click on the text to the left of the brackets, the plumber will not see the brackets or what's inside them. If you sweep and select yourself, the whole selection goes to the plumber.
>
> tor. 11. jul. 2019, 23.30 skrev James A. Robinson <jim.robinson@gmail.com>:
>>
>> Well, I can see this is getting called:
>>
>> look.c:187: if(m->ndata<messagesize-1024 &&
>> plumbsendtofid(plumbsendfid, m) >= 0){
>>
>> and the m->data is the full line, including the trailing
>> ".java:[<lineno>,<colno>]" data.
>>
>> So it's certainly appears to be sending the data to the plumber.
>> But I don't get the same behavior from acme as when I send the
>> same text I see in m->data to plumb(1) directly on the command
>> line.
>>
>> Jim
>>