GNU bug report logs - #79397
29.3; ffap-latex-mode should be modified after upstream kpsewhich update

Previous Next

Full log

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

From: Leo Stein <leo.stein <at> gmail.com>
To: Arash Esbati <arash <at> gnu.org>
Cc: 79397 <at> debbugs.gnu.org
Subject: Re: bug#79397: 29.3; ffap-latex-mode should be modified after
 upstream kpsewhich update
Date: Sat, 13 Sep 2025 14:55:35 -0500

[Message part 1 (text/plain, inline)]

Dear Arash,

Let me give you a working example. Create a .tex file which will be a
beamer presentation, and write that you are going to use some theme, e.g.

> \usetheme{CambridgeUS}

Now with the old behavior of kpsewhich, you could ffap on CambridgeUS, and
it would offer to open

/path/to/texlive/2025/texmf-dist/tex/latex/beamer/beamerthemeCambridgeUS.sty

I captured the invocation of call-process by adding advice, and the
invocation of kpsewhich would have been equivalent to

> kpsewhich "CambridgeUS.sty" "CambridgeUS.cls" "CambridgeUS.ltx"
> "CambridgeUS.tex" "CambridgeUS" "beamerthemeCambridgeUS.sty"
> "beamercolorthemeCambridgeUS.sty" "beamerfontthemeCambridgeUS.sty"
> "beamerinnerthemeCambridgeUS.sty" "beamerouterthemeCambridgeUS.sty"
> "CambridgeUS.ldf"

If you run this from a terminal, with the new kpsewhich, you will see that
there are a bunch of blank lines both before and after the correct path.
All of the non-matching paths (e.g. CambridgeUS.sty) result in blank lines.

The reason you didn't find any issue with hyperref is because the first
argument to kpsewhich happened to actually exist in the tex tree.

Hope that explains why this is needed!
Best
Leo

PS Of course you might not want to edit a system-installed beamer theme,
but maybe it's a user-installed one in TEXMFLOCAL; but the overarching
point is that the current ffap code with latest kpsewhich will only work if
the first argument happens to be the correct one.

On Sat, Sep 13, 2025 at 2:27 PM Arash Esbati <arash <at> gnu.org> wrote:

> Leo Stein <leo.stein <at> gmail.com> writes:
>
> > ffap-latex-mode in ffap.el uses the executable kpsewhich if available.
> > Before a recent change to kpsewhich, the executable would report
> > possible paths, one per line, with no blank lines. Following svn
> > revision 73462 in texlive's tree (which is included in TeX Live 2025;
> > see lines 959-966 at
> >
> https://svn.tug.org:8369/texlive/trunk/Build/source/texk/kpathsea/kpsewhich.c?r1=69416&r2=73462
> ),
> > the new behavior of kpsewhich is to output a blank line for each
> > input file which was not found.
> >
> > The behavior in ffap-latex-mode is to simply take the first line from
> > the temp buffer that recieves the output. Previously, this would either
> > be a valid path, or the buffer would be empty. With the new behavior,
> > the buffer could be non-empty, with various blank lines, and the first
> > valid path might follow after some blank lines.
>
> My apologies if my comment is off, I'm not a `ffap' user.  But can you
> please show an example in which way the change in kpsewhich breaks the
> functionality of `ffap'?  I started with "emacs -Q", opened a .tex file
> and inserted
>
>   \usepackage{hyperref}
>
> then I put the cursor somewhere on "hyperref" and did 'M-x ffap RET'.
> Emacs offers to open hyperref.sty from
>
>   /path/to/texlive/2025/texmf-dist/tex/latex/hyperref/hyperref.sty
>
> which seems to be TRT.  Now I do the same exercise with:
>
>   \usepackage{hyperrefs}
>
> and Emacs asks for completion in the minibuffer since kpsewhich didn't
> find hyperrefs.sty (which was expected).  Am I missing something?
>
> Best, Arash
>

[Message part 2 (text/html, inline)]

Previous Next

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