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

Previous Next

Package: emacs;

Reported by: Leo Stein <leo.stein <at> gmail.com>

Date: Sat, 6 Sep 2025 19:25:02 UTC

Severity: normal

Found in version 29.3

To reply to this bug, email your comments to 79397 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#79397; Package emacs. (Sat, 06 Sep 2025 19:25:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Leo Stein <leo.stein <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 06 Sep 2025 19:25:02 GMT) Full text and rfc822 format available.

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

From: Leo Stein <leo.stein <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.3;
 ffap-latex-mode should be modified after upstream kpsewhich update
Date: Sat, 6 Sep 2025 14:23:03 -0500
[Message part 1 (text/plain, inline)]
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.

ffap-latex-mode can easily be patched by just removing blank lines from
the temp buffer. However I don't know if that is the idiomatic approach;
please teach me the ways!

Leo

In GNU Emacs 29.3 (build 2, aarch64-apple-darwin23.4.0, NS
 appkit-2487.50 Version 14.4 (Build 23E214)) of 2024-05-13 built on
 macbook-pro.lan
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.6.1

Configured using:
 'configure --disable-dependency-tracking --disable-silent-rules
 --enable-locallisppath=/opt/homebrew/share/emacs/site-lisp
 --infodir=/opt/homebrew/Cellar/emacs-plus <at> 29/29.3/share/info/emacs
 --prefix=/opt/homebrew/Cellar/emacs-plus <at> 29/29.3 --with-xml2
 --with-gnutls --with-native-compilation --without-compress-install
 --without-dbus --without-imagemagick --with-modules --with-rsvg
 --with-ns --disable-ns-self-contained 'CFLAGS=-Os -w -pipe
 -mmacosx-version-min=14
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
 -DFD_SETSIZE=10000 -DDARWIN_UNLIMITED_SELECT'
 'CPPFLAGS=-I/opt/homebrew/opt/zlib/include
 -I/opt/homebrew/opt/jpeg/include -I/opt/homebrew/opt/icu4c/include
 -I/opt/homebrew/opt/sqlite/include -I/opt/homebrew/opt/readline/include
 -isystem/opt/homebrew/include -F/opt/homebrew/Frameworks
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk'
 'LDFLAGS=-L/opt/homebrew/opt/zlib/lib -L/opt/homebrew/opt/jpeg/lib
 -L/opt/homebrew/opt/icu4c/lib -L/opt/homebrew/opt/sqlite/lib
 -L/opt/homebrew/opt/readline/lib -L/opt/homebrew/lib
 -F/opt/homebrew/Frameworks -Wl,-headerpad_max_install_names
 -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk
 -L/opt/homebrew/opt/libgccjit/lib''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: ELisp/l

Minor modes in effect:
  global-git-commit-mode: t
  magit-auto-revert-mode: t
  bug-reference-prog-mode: t
  shell-dirtrack-mode: t
  TeX-PDF-mode: t
  TeX-source-correlate-mode: t
  auto-revert-mode: t
  server-mode: t
  projectile-mode: t
  marginalia-mode: t
  vertico-mode: t
  override-global-mode: t
  which-key-mode: t
  savehist-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  global-display-fill-column-indicator-mode: t
  display-fill-column-indicator-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  column-number-mode: t
  line-number-mode: t
  global-visual-line-mode: t
  visual-line-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/Users/leo/.emacs.d/elpa/emacsql-sqlite-20240415.1535/emacsql-sqlite hides
/Users/leo/.emacs.d/elpa/emacsql-20240819.1559/emacsql-sqlite
/Users/leo/.emacs.d/elpa/git-commit-20240508.2349/git-commit hides
/Users/leo/.emacs.d/elpa/magit-20250401.1753/git-commit
/Users/leo/.emacs.d/elpa/cmake-mode-3.29.3/cmake-mode hides
/opt/homebrew/share/emacs/site-lisp/cmake/cmake-mode
/Users/leo/.emacs.d/elpa/transient-20250401.1655/transient hides
/opt/homebrew/Cellar/emacs-plus <at> 29/29.3/share/emacs/29.3/lisp/transient
/Users/leo/.emacs.d/elpa/bind-key-20230203.2004/bind-key hides
/opt/homebrew/Cellar/emacs-plus <at> 29
/29.3/share/emacs/29.3/lisp/use-package/bind-key

Features:
(shadow sort mail-extr emacsbug misearch multi-isearch cl-print debug
backtrace disp-table whitespace shortdoc help-fns radix-tree vc-hg
vc-bzr vc-src vc-sccs vc-svn vc-cvs vc-rcs log-view magit-extras
emacsql-sqlite-builtin sqlite forge-repos forge-tablist hl-line
forge-topics forge-commands forge-semi forge-bitbucket buck forge-gogs
gogs forge-gitea gtea forge-gitlab glab forge-github ghub-graphql treepy
gsexp ghub url-http url-gw url-auth let-alist forge-forgejo forge-notify
forge-revnote forge-pullreq forge-issue forge-discussion forge-topic
yaml eieio-custom forge-post forge-repo forge forge-core forge-db closql
emacsql-sqlite emacsql-sqlite-common emacsql emacsql-compiler eieio-base
magit-submodule magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
magit-repos magit-apply magit-wip magit-log which-func magit-diff
smerge-mode diff git-commit log-edit pcvs-util add-log magit-core
magit-autorevert magit-margin magit-transient magit-process with-editor
magit-mode transient pp benchmark magit-git magit-base magit-section
cursor-sensor llama google-c-style cc-mode cc-fonts cc-guess cc-menus
cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs vc bug-reference
oc-basic org-element org-persist org-id org-refile avl-tree ol-eww eww
url-queue mm-url ol-rmail ol-mhe ol-irc ol-info ol-gnus nnselect
gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum shr
pixel-fill kinsoku url-file svg gnus-group gnus-undo gnus-start
gnus-dbus dbus xml gnus-cloud nnimap nnmail mail-source utf7 nnoo
gnus-spec gnus-int gnus-range message sendmail yank-media rfc822 mml
mml-sec epa mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047
rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
nnheader gnus-util mail-utils range mm-util mail-prsvr ol-docview
doc-view jka-compr ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi
org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-src
ob-comint org-pcomplete org-list org-footnote org-faces org-entities
ob-emacs-lisp ob-core ob-eval org-cycle org-table ol org-fold
org-fold-core org-keys oc org-loaddefs cal-menu calendar cal-loaddefs
org-version org-compat org-macs view lsp-zig lsp-yang lsp-yaml lsp-xml
lsp-wgsl lsp-volar lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog
lsp-vala lsp-v lsp-typespec tramp-cache time-stamp tramp-sh tramp
tramp-loaddefs trampver tramp-integration tramp-compat parse-time
iso8601 format-spec lsp-typeprof lsp-ttcn3 lsp-ts-query lsp-trunk
lsp-toml lsp-tilt lsp-tex lsp-terraform lsp-svelte lsp-steep lsp-sqls
lsp-sql lsp-sorbet lsp-solidity lsp-solargraph lsp-semgrep lsp-rust
lsp-ruff lsp-ruby-syntax-tree lsp-ruby-lsp lsp-rubocop lsp-roslyn
lsp-roc lsp-rf lsp-remark lsp-racket lsp-r lsp-qml lsp-pyright lsp-pylsp
lsp-pyls lsp-pwsh lsp-purescript lsp-postgres lsp-pls lsp-php
lsp-perlnavigator lsp-perl lsp-openscad lsp-ocaml find-file lsp-nushell
lsp-nix lsp-nim lsp-nginx lsp-nextflow lsp-move lsp-mojo lsp-mint
lsp-meson lsp-mdx lsp-matlab lsp-marksman lsp-markdown lsp-magik
lsp-fennel lsp-lua lsp-lisp lsp-kubernetes-helm lsp-kotlin lsp-json
lsp-jq lsp-javascript lsp-idris lsp-haxe lsp-hack lsp-groovy lsp-graphql
lsp-golangci-lint lsp-glsl lsp-gleam lsp-gdscript lsp-fsharp lsp-futhark
lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elm lsp-elixir
lsp-earthly lsp-dockerfile lsp-dhall lsp-d lsp-cypher lsp-cucumber
lsp-copilot lsp-css lsp-c3 lsp-csharp gnutls lsp-crystal lsp-credo
lsp-cobol lsp-cmake lsp-clojure lsp-clangd dom lsp-bufls lsp-go
lsp-beancount lsp-bash lsp-awk lsp-autotools lsp-astro lsp-asm
lsp-ansible lsp-angular lsp-ada lsp-semantic-tokens lsp-actionscript
lsp-lens lsp-ui lsp-ui-flycheck lsp-ui-imenu derived lsp-ui-peek
lsp-ui-sideline lsp-ui-doc goto-addr lsp-ui-util face-remap lsp-modeline
lsp-headerline lsp-icons lsp-diagnostics flycheck lisp-mnt find-func
lsp-completion lsp-mode lsp-protocol tree-widget wid-edit spinner
network-stream puny nsm markdown-mode color lv inline imenu ht f s ewoc
epg rfc6068 epg-config dash company-oddmuse company-keywords
company-etags etags fileloop generator xref company-gtags
company-dabbrev-code company-dabbrev company-files company-clang
company-capf company-cmake company-semantic company-template
company-bbdb company python treesit flyspell ispell latex-extra
reftex-dcr reftex-auc reftex reftex-loaddefs reftex-vars noutline
outline tex-mode shell pcomplete font-latex latexenc preview latex
latex-flymake flymake-proc flymake tex-ispell tex-style tex crm texmathp
auctex time-date autorevert filenotify vc-git diff-mode vc-dispatcher
server emoji-fontset comp comp-cstr warnings icons cl-extra projectile
project grep compile text-property-search comint ansi-osc ansi-color
ring ibuf-ext ibuffer ibuffer-loaddefs marginalia vertico compat
compat-30 ido edmacro kmacro bind-key finder-inf zenburn-theme which-key
savehist display-line-numbers display-fill-column-indicator desktop
frameset cus-load bibretrieve help-mode easy-mmode dired+ image-dired
image-dired-tags image-dired-external image-dired-util xdg image-mode
exif image-file image-converter dired-x dired-aux dired dired-loaddefs
leo-lib files-x ffap thingatpt advice clang-format-autoloads
cmake-mode-autoloads dired-git-info-autoloads emacsql-sqlite-autoloads
expand-region-autoloads flycheck-autoloads forge-autoloads
closql-autoloads emacsql-autoloads ghub-autoloads git-commit-autoloads
google-c-style-autoloads html-to-markdown-autoloads rx keycast-autoloads
latex-extra-autoloads auctex-autoloads tex-site lsp-pyright-autoloads
lsp-mode-autoloads dash-autoloads magit-autoloads pcase
magit-section-autoloads llama-autoloads marginalia-autoloads
markdown-mode-autoloads projectile-autoloads
reveal-in-osx-finder-autoloads transient-autoloads treepy-autoloads
vertico-autoloads with-editor-autoloads info compat-autoloads
yaml-autoloads yaml-mode-autoloads package browse-url url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/ns-win ns-win
ucs-normalize mule-util term/common-win tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads kqueue cocoa ns lcms2
multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 1457339 450229)
 (symbols 48 65505 7)
 (strings 32 396113 68484)
 (string-bytes 1 11133264)
 (vectors 16 165399)
 (vector-slots 8 3410214 1558301)
 (floats 8 851 1664)
 (intervals 56 3084 2273)
 (buffers 984 54))
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79397; Package emacs. (Sat, 13 Sep 2025 08:49:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Leo Stein <leo.stein <at> gmail.com>
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 11:48:00 +0300
> From: Leo Stein <leo.stein <at> gmail.com>
> Date: Sat, 6 Sep 2025 14:23:03 -0500
> 
> 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.
> 
> ffap-latex-mode can easily be patched by just removing blank lines from
> the temp buffer. However I don't know if that is the idiomatic approach;
> please teach me the ways!

It might be simpler to look for the first non-empty line.

Feel free to suggest a patch along these lines, and thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79397; Package emacs. (Sat, 13 Sep 2025 16:40:02 GMT) Full text and rfc822 format available.

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

From: Leo Stein <leo.stein <at> gmail.com>
To: Eli Zaretskii <eliz <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 11:38:40 -0500
[Message part 1 (text/plain, inline)]
Thanks for the suggestion! That's definitely simpler than removing all
blank lines.

Here is my attempt at a patch from the latest master. I hope I've formatted
the commit message correctly. Note that I included \r along with \n for
possible end-of-line characters to skip, but I don't have a Windows machine
to test this on.

Best
Leo

On Sat, Sep 13, 2025 at 3:48 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Leo Stein <leo.stein <at> gmail.com>
> > Date: Sat, 6 Sep 2025 14:23:03 -0500
> >
> > 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.
> >
> > ffap-latex-mode can easily be patched by just removing blank lines from
> > the temp buffer. However I don't know if that is the idiomatic approach;
> > please teach me the ways!
>
> It might be simpler to look for the first non-empty line.
>
> Feel free to suggest a patch along these lines, and thanks.
>
[Message part 2 (text/html, inline)]
[0001-ffap-latex-mode-upstream-kpsewhich-change-give-first.patch (application/octet-stream, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79397; Package emacs. (Sat, 13 Sep 2025 19:28:01 GMT) Full text and rfc822 format available.

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

From: Arash Esbati <arash <at> gnu.org>
To: Leo Stein <leo.stein <at> gmail.com>
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 21:26:53 +0200
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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79397; Package emacs. (Sat, 13 Sep 2025 19:57:02 GMT) Full text and rfc822 format available.

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)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#79397; Package emacs. (Sat, 13 Sep 2025 20:38:02 GMT) Full text and rfc822 format available.

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

From: Arash Esbati <arash <at> gnu.org>
To: Leo Stein <leo.stein <at> gmail.com>
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 22:36:38 +0200
Leo Stein <leo.stein <at> gmail.com> writes:

> 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.

Thanks for explanation, I now see what's happening.

> 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.

Yes, thanks.  Technically, I didn't read the code of `ffap-latex-mode'
careful enough to see how it uses the value of `ffap-latex-guess-rules'.

Best, Arash




This bug report was last modified today.

Previous Next


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