GNU bug report logs - #43298
27.1; Do font locking for Python 3, not 2

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 43298 in the body.
You can then email your comments to 43298 AT debbugs.gnu.org in the normal way.

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

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

From: Per Starbäck <starback <at> cl.lingfil.uu.se>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Do font locking for Python 3, not 2
Date: Wed, 09 Sep 2020 20:36:17 +0200

In GNU Emacs 27.1:

	$ emacs -Q -f /tmp/new.py
        for RET print RET len RET

"print" gets the same colour as "for", that is as a keyword.
I think it should get the same as "len", that is as a builtin
function.

Python.el has a section

          ;; Python 2:
          "print" "exec"

because in Python 2 these two were keywords. But in Python 3 they are built-in
functions.

I think it's overkill to try to determine if the buffer contains Python 2 or 3
and highlight them differently. Using the same fontlocking is good enough,
since it's not a big problem to get these in the wrong colour.
But now when Python 2 is officially discontinued I think it's time to
let it follow Python 3 and get the small inconvenience when editing old
code and not when editing current code.

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#43298: 27.1; Do font locking for Python 3, not 2
Date: Thu, 10 Sep 2020 19:23:18 +0200

This is one of my long-standing pet peeves, thanks for filing an issue
about it.  FWIW here is how I thought I'd go about fixing this Whenever
I'd Find The Time™ (… needless to say, if anyone wants to beat me to it,
there'll be no hard feelings):

1. Add fontification tests for the current fontification.
   (Because I expected the overall patch to be quite big, and I figured
   it'd be easier to get it merged if it came with a bunch of
   non-regression tests.)

2. Create 3 sets of font-lock settings in python.el: -2, -3, and
   -undecided (= whatever the current settings do).

3. Add a variable to control which settings to use (settable through
   Customize or through file/directory-local variables).

4. Add heuristics to pick the "right" style by default (e.g. look for a
   shebang).


On the one hand, I agree that Emacs should be py3k-compliant by now
out-of-the-box.  On the other hand, I'd bet there are a lot of poor
souls out there who will be stuck maintaining Python 2 code for a few
more years.  Messing with font-lock without giving them an escape hatch
sounds like some form of double-jeopardy…

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

From: Stefan Kangas <stefan <at> marxist.se>
To: Per Starbäck <starback <at> cl.lingfil.uu.se>
Cc: 43298 <at> debbugs.gnu.org
Subject: Re: bug#43298: 27.1; Do font locking for Python 3, not 2
Date: Mon, 11 Oct 2021 06:25:26 -0700

close 43298 29.1
thanks

Per Starbäck <starback <at> cl.lingfil.uu.se> writes:

> In GNU Emacs 27.1:
>
> 	$ emacs -Q -f /tmp/new.py
>         for RET print RET len RET
>
> "print" gets the same colour as "for", that is as a keyword.
> I think it should get the same as "len", that is as a builtin
> function.
>
> Python.el has a section
>
>           ;; Python 2:
>           "print" "exec"
>
> because in Python 2 these two were keywords. But in Python 3 they are built-in
> functions.

Thanks for the bug report!  Your reasoning makes sense to me, so I have
now fixed this on master (commit 9f9c9f934a).  This change will be in
Emacs 29.

Feel free to verify that this fix works for you, but for now I'm closing this
bug report.  If you see anything that is wrong, please reply to this
email (use "Reply to all" in your email client) and we can reopen the
bug report.

> I think it's overkill to try to determine if the buffer contains Python 2 or 3
> and highlight them differently. Using the same fontlocking is good enough,
> since it's not a big problem to get these in the wrong colour.
> But now when Python 2 is officially discontinued I think it's time to
> let it follow Python 3 and get the small inconvenience when editing old
> code and not when editing current code.

Agreed.

Previous Next

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