[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#51549: 29.0.50; flymake error when filename contain '%'
From: |
João Távora |
Subject: |
bug#51549: 29.0.50; flymake error when filename contain '%' |
Date: |
Sat, 6 Nov 2021 09:37:54 +0000 |
Hi Stefan, Ola
Thanks for the report. I don't have much time to look into this but
this looks like the typical problem where a user-provided
string is being passed as the first argument of format/message.
In these cases, one normally makes it so that the first
argument is simply the string "%s" and then the second
argument is that user-provided thing.
Thanks very much for looking into this,
João
On Sat, Nov 6, 2021 at 8:30 AM Stefan Kangas <stefan@marxist.se> wrote:
>
> tags 51549 + confirmed
> thanks
>
> Ola x Nilsson <ola.x.nilsson@axis.com> writes:
>
> > Flymake includes the buffer name in `warning-type-format' (see
> > `flymake--log-1').
> > When the file name - and the buffer name - contain a % character it is
> > very probable that the `format' call in `display-warning' either fails
> > or produce unexpected results.
> >
> > In my case I used a file name arm-trusted-firmware-2.4_%.bbappend with a
> > local flymake backend running a local linter.
> > The local backend uses a process sentinel to process errors and generate
> > flymake diagnostic objects with
> >
> > (flymake-make-diagnostic source beg end type msg)
> >
> > where
> > source is the buffer visiting arm-trusted-firmware-2.4_%.bbappend,
> > bed and end set from `flymake-diag-region'
> > type is :warning
> > and msg is a string with the error message from the linter.
>
> Thanks for the bug report. I can reproduce this using this contrived
> example:
>
> ./src/emacs -Q --eval "(progn (require 'flymake) (find-file
> \"/tmp/foo%sbar.c\") \
> (flymake--log-1 :emergency nil \"foo\"))"
>
> I now see in the *Warnings* buffer:
>
> Emergency [flymake fooflymakebar.c]: foo
>
> The expected output is:
>
> Emergency [flymake foo%sbar.c]: foo
>
> Your analysis of why the problem happens seems correct to me, but I'm
> not sure how to best fix it. João, what do you think?
--
João Távora