If python_no_builtin_highlight is set the boolean literals and None are highlighted as Statement.
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.
9.1.1563
N/A
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
@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.![]()
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.![]()
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,Ellipsisand__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, ...
ftplugin for example.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.![]()
@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.![]()
Sorry I missed your response at the time.
So, I would opt for your "alternative" above. The new categories would be linked to
Keywordby 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.![]()
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.![]()
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.![]()