bug#57883: closed (compilation-get-file-structure mishandles buffers)

[GNU bug Tracking System]

Your message dated Wed, 10 Jan 2024 15:20:34 -0800
with message-id 
<CADwFkm=W4fCovia5qubbPnU7UacLE0tneG1fDPXR1_eEnB4cXg@mail.gmail.com>
and subject line Re: bug#57883: compilation-get-file-structure mishandles 
buffers
has caused the debbugs.gnu.org bug report #57883,
regarding compilation-get-file-structure mishandles buffers
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
57883: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=57883
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems

--- Begin Message --- Subject: compilation-get-file-structure mishandles buffers Date: Sat, 17 Sep 2022 10:25:25 -0400

As reported on emacs-devel, a bug is present in `compilation-get-file-structure’ when the “file” matched by the `compilation-parse-errors’ is not a file, but a buffer name.  Both filenames and buffer names are explicitly allowed in errors.  From the `compilation-error-regexp-alist’ docstring (emphasis added):

Or FILE can also be a function that returns (FILENAME) or (RELATIVE-FILENAME . DIRNAME). In the former case, FILENAME may be relative or absolute, or it may be a buffer.

Note that this is useful for modes which report errors in text from open buffers, which may have no associated file.   The issue is this line in `compilation-get-file-structure’:

(if (file-name-absolute-p filename)
   (setq filename (concat comint-file-name-prefix filename)))

which signals an 

--- End Message ---

> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: bug#57883: compilation-get-file-structure mishandles buffers
>
>
>
>
> Date: 
>
> Wed, 10 Jan 2024 15:20:34 -0800
>
>
>
>
> reopen 57883
> thanks
>
> JD Smith <jdtsmith@gmail.com> writes:
>
> > Apologies, I had missed this request.  The problem with your version
> > of the code is it doesn’t actually create any error text for
> > parse-errors to match.  Here’s a small tweak to your code to do this.
> > It is still producing the same error in v29.1:
>
> Thanks, so I'm reopening this bug.
>
>
> --- End Message ---