unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#43298: 27.1; Do font locking for Python 3, not 2
@ 2020-09-09 18:36 Per Starbäck
  2020-09-10 17:23 ` Kévin Le Gouguec
  2021-10-11 13:25 ` Stefan Kangas
  0 siblings, 2 replies; 3+ messages in thread
From: Per Starbäck @ 2020-09-09 18:36 UTC (permalink / raw)
  To: 43298

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.





^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#43298: 27.1; Do font locking for Python 3, not 2
  2020-09-09 18:36 bug#43298: 27.1; Do font locking for Python 3, not 2 Per Starbäck
@ 2020-09-10 17:23 ` Kévin Le Gouguec
  2021-10-11 13:25 ` Stefan Kangas
  1 sibling, 0 replies; 3+ messages in thread
From: Kévin Le Gouguec @ 2020-09-10 17:23 UTC (permalink / raw)
  To: 43298

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…






^ permalink raw reply	[flat|nested] 3+ messages in thread

* bug#43298: 27.1; Do font locking for Python 3, not 2
  2020-09-09 18:36 bug#43298: 27.1; Do font locking for Python 3, not 2 Per Starbäck
  2020-09-10 17:23 ` Kévin Le Gouguec
@ 2021-10-11 13:25 ` Stefan Kangas
  1 sibling, 0 replies; 3+ messages in thread
From: Stefan Kangas @ 2021-10-11 13:25 UTC (permalink / raw)
  To: Per Starbäck; +Cc: 43298

close 43298 29.1
thanks

Per Starbäck <starback@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.





^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-11 13:25 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-09-09 18:36 bug#43298: 27.1; Do font locking for Python 3, not 2 Per Starbäck
2020-09-10 17:23 ` Kévin Le Gouguec
2021-10-11 13:25 ` Stefan Kangas

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).