GNU bug report logs - #64198
Feature request: compile.el's "Find this in" prompt should be hookable.

Previous Next

Full log

Message #14 received at 64198 <at> debbugs.gnu.org (full text, mbox):

From: Björn Bidar <bjorn.bidar <at> thaodan.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dave Abrahams <dave <at> boostpro.com>, 64198 <at> debbugs.gnu.org
Subject: Re: bug#64198: Feature request: compile.el's "Find this in" prompt
 should be hookable.
Date: Thu, 22 Jun 2023 00:52:36 +0300

Eli Zaretskii <eliz <at> gnu.org> writes:

>> When a file can't be found via the path given in a diagnostic, I'd
>> like to be able to override the prompt that emacs gives to locate
>> the file.  compilation-parse-errors-filename-function happens too
>> early, while the buffer is being initially parsed.  A similar
>> compilation-locate-file-function would be great.  If there's
>> interest I could try to develop a patch.
>
> Before discussing patches, could you please describe your situation?
> Specifically, how does it happen that neither the compilation
> directory plus the file name shown by the diagnostics nor the search
> of compilation-search-path succeed to locate the file?  And what would
> the hook function you suggest adding do to resolve this, i.e. how
> would it know where to look for the file?

I'm not the original requester but for cross compilation this could be
useful. E.g I compile Sailfish OS RPM packages with mb2 which runs
rpmbuild in scratchbox2.

The patches in the output come from the command line output that is the
same as if it was ran outside of the cross compilation target however it
should resolve through the target rather than the host unless it is
sourced from the very same package that I compile right now.

E.g. /usr/include/stdio.h should be resolved to ->
/srv/mer/sailfishos-devel-aarch64/usr/include.

When building with open build service the situation is very similar.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.