[vim/vim] Python syntax highlighting - True, False and None highlighting (Issue #17788)

18 views
Skip to first unread message

dkearns

unread,
Jul 18, 2025, 8:38:21 AM7/18/25
to vim/vim, Subscribed
dkearns created an issue (vim/vim#17788)

Steps to reproduce

If python_no_builtin_highlight is set the boolean literals and None are highlighted as Statement.

Expected behaviour

It would seem to me these should be highlighted as Boolean and Constant respectively. This would be in keeping with the general approach of Vim's syntax files.

@zvezdan

Version of Vim

9.1.1563

Environment

N/A

Logs and stack traces


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788@github.com>

Zvezdan Petkovic

unread,
Jul 18, 2025, 8:22:49 PM7/18/25
to vim/vim, Subscribed
zvezdan left a comment (vim/vim#17788)

@dkearns In Python 3, False, True, and None are keywords: documentation reference.
I already listed them as such in the syntax file.
Since Keyword is linked to Statement in Vim, these keywords also link to that same color.

The problem seems to be that we have maintained the compatibility between Python 2 and 3 for a long time and they remained also listed under pythonBuiltin section because they used to be only constants in Python 2, but not keywords.
They are still listed as constants in Python 3 too, but since they are also keywords, the highlighting should be different.

Considering that we do not need to maintain Python 2 compatibility anymore in the python.vim syntax file, the only remaining action is perhaps that I remove them from the pythonBuiltin section and we always show them as keywords.
What do you think?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788/3091299792@github.com>

dkearns

unread,
Jul 28, 2025, 11:17:37 AM7/28/25
to vim/vim, Subscribed
dkearns left a comment (vim/vim#17788)

Yes, I'd pull them out and match them as

syn keyword pythonBoolean True False
syn keyword pythonNone None
hi link default pythonBoolean Boolean
hi link default pythonNone Constant
" alternatively
" hi link default pythonBoolean Keyword
" hi link default pythonNone Keyword

My view is that their status as reserved words is much less interesting than their function.

The same would seem to apply to NotImplemented, Ellipsis and __debug__


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788/3127711808@github.com>

Zvezdan Petkovic

unread,
Aug 10, 2025, 1:39:04 AM8/10/25
to vim/vim, Subscribed
zvezdan left a comment (vim/vim#17788)

Yes, I'd pull them out and match them as

syn keyword pythonBoolean True False
syn keyword pythonNone None

hi def link pythonBoolean Boolean
hi def link pythonNone Constant
" alternatively
" hi def link pythonBoolean Keyword
" hi def link pythonNone Keyword


My view is that their status as reserved words is much less interesting than their function.

The same would seem to apply to NotImplemented, Ellipsis and __debug__

I don't see a value in too many colors and categories. The rendering can get too busy quite easily.
There are two booleans only and they are obvious.
There's only one None and its purpose is obvious too.
In fact, the syntax highlighting should be a visual queue for mistakes too.
If someone accidentally chooses these as variable names, the Keyword color is a good visual cue that the mistake just happened. Not because of their function, but because they're keywords. Similarly for the builtins.

However, ...

  • I see a value in adding these categories, so that people who want to color them differently, can do that in their customization in ftplugin for example.
  • We need to fix the current error where they are still treated as Python 2 builtins instead of keywords.

So, I would opt for your "alternative" above. The new categories would be linked to Keyword by default, but it leaves space for users to customize the colors.

Does that work for you?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788/3172385522@github.com>

Rob B

unread,
Sep 5, 2025, 8:14:19 AM9/5/25
to vim/vim, Subscribed
f4nb0y left a comment (vim/vim#17788)

@dkearns said:

My view is that their status as reserved words is much less interesting than their function.

I've been thinking the same thing. From the language user's perspective, these are constants regardless of their implementation.

We map pythonString to String and pythonNumber to Number, so it seems reasonable to do the same with Boolean. But if that is too many levels of indirection, we could just do:

" https://docs.python.org/3/library/constants.html
syn keyword pythonConstant    False True None NotImplemented Ellipsis __debug__

hi def link pythonConstant    Constant

And if this is controversial, we could put it under an option?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788/3258138098@github.com>

dkearns

unread,
Sep 5, 2025, 9:01:32 AM9/5/25
to vim/vim, Subscribed
dkearns left a comment (vim/vim#17788)

Sorry I missed your response at the time.

So, I would opt for your "alternative" above. The new categories would be linked to Keyword by default, but it leaves space for users to customize the colors.

Does that work for you?

Sure, that sounds good. Thanks.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788/3258267078@github.com>

Rob B

unread,
Nov 23, 2025, 3:52:05 AM11/23/25
to vim/vim, Subscribed
f4nb0y left a comment (vim/vim#17788)

Hi Folks,

What's the consensus on this?


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issues/17788/3567640587@github.com>

Christian Brabandt

unread,
Jan 26, 2026, 1:55:08 PM (2 days ago) Jan 26
to vim/vim, Subscribed

Closed #17788 as completed via 632fd8b.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/issue/17788/issue_event/22297177869@github.com>

Reply all
Reply to author
Forward
0 new messages