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
wrote:
>
> I think
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
Well, I can see this is getting called:
look.c:187: if(m->ndata= 0){
and the m->data is the full line, including the trailing
".java:[,]" 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
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
On Wed, 10 Jul 2019 at 18:48, James A. Robinson 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
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]
