GNU bug report logs - #75526
python.el uses treesit-declare-unavailable-functions despite requiring emacs >v24.4

Previous Next

Full log

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: JD Smith <jdtsmith <at> gmail.com>
Cc: mail <at> daniel-mendler.de, philipk <at> posteo.net, casouri <at> gmail.com,
 monnier <at> iro.umontreal.ca, 75526 <at> debbugs.gnu.org
Subject: Re: bug#75526: python.el uses treesit-declare-unavailable-functions
 despite requiring emacs >v24.4
Date: Sat, 1 Mar 2025 16:58:51 -0800

JD Smith <jdtsmith <at> gmail.com> writes:

> Thanks.  Unfortunately there are now new changes to python.el which again break Emacs < 30.  The file still mentions:
>
>> Package-Requires: ((emacs "24.4")
>
>
> It now uses the Emacs 30 only `derived-mode-add-parents'.  If python.el is going to be developed primarily on master, it should probably be removed from MELPA or at least use compat.  I'll take this up with them.

Hmm, there seem to be several compatibility issues here.  I'm
detailings my findings below.

1. Excluding treesit symbols (see below), these are the symbols that
   python.el itself needs, per version:

    28.1 project-root
    28.1 split-string-shell-command
    27.1 rx-let
    26.1 prog-first-column
    25.1 font-lock-ensure
    25.1 make-process

   Philip, Daniel, WDYT of the feasability of adding support for these
   symbols to compat?  Would it be worth the effort?  See also point 2
   and 3 below.

2. Stefan Monnier added the call to `derived-mode-add-parents', which
   needs Emacs 30.1.

   Stefan, can we avoid making that call?  Perhaps it should be added to
   compat?

3. We also need the below symbols:

    26.1 flymake-make-diagnostic
    26.1 flymake-diag-region
    27.1 project-files
    25.1 project-current

   This could perhaps be fixed by depending on project and flymake.
   Unfortunately, project 1.0 and flymake 0.1 (the earliest versions
   available on GNU ELPA) themselves need Emacs 26.1 and Emacs 26.3.  So
   maybe we should just bump the required version of python.el to Emacs
   26.3?

   Alternatively, perhaps the above could also be added to compat?  I'll
   let Philip and Daniel comment on this too.

4. More complicated to resolve perhaps are these symbols from Emacs 29.1:

    29.1 treesit [require]
    29.1 treesit-buffer-root-node
    29.1 treesit-defun-name
    29.1 treesit-filter-child
    29.1 treesit-font-lock-rules
    29.1 treesit-fontify-with-override
    29.1 treesit-induce-sparse-tree
    29.1 treesit-major-mode-setup
    29.1 treesit-node-at
    29.1 treesit-node-child-by-field-name
    29.1 treesit-node-children
    29.1 treesit-node-end
    29.1 treesit-node-field-name
    29.1 treesit-node-parent
    29.1 treesit-node-prev-sibling
    29.1 treesit-node-start
    29.1 treesit-node-text
    29.1 treesit-node-type
    29.1 treesit-parser-create
    29.1 treesit-ready-p

   Yuan, Philip, Daniel, any ideas for how to handle this compatibility
   issue?

Previous Next

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