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

Previous Next

Full log

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

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

Stefan Kangas <stefankangas <at> gmail.com> writes:

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

I think that split-string-shell-command, prog-first-column,
font-lock-ensure and possibly make-process could be back-ported, but
rx-let would require modifying a lot of rx which would be out of scope
of Compat.

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

I would rather that Compat doesn't depend on a newer version of flymake
and project.

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

I still haven't familiarised myself with the treesit API, and I don't
know if there is a reasonable way to translate these into fontlock...

Previous Next

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