[vim/vim] python syntax file, support f-string (Issue #14033)
A4-Tacks
Vim syntax file for Python, with support for f-string added
- f-string support
- Fixed shortstring with multiple lines still highlighted
- Update string prefix to Python3.10+ syntax
have contacted the maintainer zpet...@acm.org But there seems to be no response
python.vim.patch
--- /usr/share/vim/vim91/syntax/python.vim 2024-01-03 12:24:01.000000000 +0800 +++ python.vim 2024-02-14 10:15:26.370000000 +0800 @@ -143,17 +143,35 @@ " Triple-quoted strings can contain doctests. syn region pythonString matchgroup=pythonQuotes - \ start=+[uU]\=\z(['"]\)+ end="\z1" skip="\\\\\|\\\z1" + \ start=+[uUbB]\=\z(['"]\)+ end="$\|\z1" skip="\\\\\|\\\z1" \ contains=pythonEscape,@Spell syn region pythonString matchgroup=pythonTripleQuotes - \ start=+[uU]\=\z('''\|"""\)+ end="\z1" keepend + \ start=+[uUbB]\=\z('''\|"""\)+ end="\z1" keepend \ contains=pythonEscape,pythonSpaceError,pythonDoctest,@Spell syn region pythonRawString matchgroup=pythonQuotes - \ start=+[uU]\=[rR]\z(['"]\)+ end="\z1" skip="\\\\\|\\\z1" + \ start=+\%([bB][rR]\=\|[rR][bB]\=\)\z(['"]\)+ + \ end="\z1" skip="\\\\\|\\\z1" \ contains=@Spell syn region pythonRawString matchgroup=pythonTripleQuotes - \ start=+[uU]\=[rR]\z('''\|"""\)+ end="\z1" keepend + \ start=+\%([bB][rR]\=\|[rR][bB]\=\)\z('''\|"""\)+ + \ end="\z1" keepend \ contains=pythonSpaceError,pythonDoctest,@Spell +syn region pythonFString matchgroup=pythonQuotes + \ start=+[fF]\z(['"]\)+ + \ end="\z1" skip="\\\\\|\\\z1" + \ contains=pythonEscape,pythonFStringEscapedBrace,pythonFStringValue,@Spell +syn region pythonFString matchgroup=pythonTripleQuotes + \ start=+[fF]\z('''\|"""\)+ + \ end="\z1" keepend + \ contains=pythonEscape,pythonSpaceError,pythonFStringEscapedBrace,pythonFStringValue,pythonDoctest,@Spell +syn region pythonRawFString matchgroup=pythonQuotes + \ start=+\%([fF][rR]\|[rR][fF]\)\z(['"]\)+ + \ end="\z1" skip="\\\\\|\\\z1" + \ contains=pythonFStringEscapedBrace,pythonFStringValue,@Spell +syn region pythonRawFString matchgroup=pythonTripleQuotes + \ start=+\%([fF][rR]\|[rR][fF]\)\z('''\|"""\)+ + \ end="\z1" keepend + \ contains=pythonSpaceError,pythonFStringEscapedBrace,pythonFStringValue,pythonDoctest,@Spell syn match pythonEscape +\\[abfnrtv'"\\]+ contained syn match pythonEscape "\\\o\{1,3}" contained @@ -161,7 +179,11 @@ syn match pythonEscape "\%(\\u\x\{4}\|\\U\x\{8}\)" contained " Python allows case-insensitive Unicode IDs: http://www.unicode.org/charts/ syn match pythonEscape "\\N{\a\+\%(\s\a\+\)*}" contained -syn match pythonEscape "\\$" +syn match pythonEscape "\\\r\=$" + +syn region pythonFStringValue matchgroup=pythonFStringBrace + \ start=+{+ end=+=\=\%(![rsa]\)\=\%(:[^{}]*\)\=}+ contains=TOP contained excludenl +syn match pythonFStringEscapedBrace "{{\|}}" contained " It is very important to understand all details before changing the " regular expressions below or their order. @@ -312,9 +334,14 @@ hi def link pythonTodo Todo hi def link pythonString String hi def link pythonRawString String +hi def link pythonFString String +hi def link pythonRawFString String hi def link pythonQuotes String hi def link pythonTripleQuotes pythonQuotes hi def link pythonEscape Special +hi def link pythonFStringEscapedBrace Special +hi def link pythonFStringValue Normal +hi def link pythonFStringBrace Include if !exists("python_no_number_highlight") hi def link pythonNumber Number endif
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A4-Tacks
f"result: {value:{width}.{precision}}" seems to be unable to be handled well
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A4-Tacks
f"result: {value:{width}.{precision}}"seems to be unable to be handled well
Modified, hardcoded several layers, maybe enough
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
Thanks. Could you please create a PR?
f"result: {value:{width}.{precision}}"seems to be unable to be handled well
You can add the pythonFStringValue group to its own contains list to simplify matching these nested replacement fields. Then the end pattern can probably be reduced to a closing brace.
Ping @zvezdan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A4-Tacks
Thanks. Could you please create a PR?
f"result: {value:{width}.{precision}}"seems to be unable to be handled wellYou can add the
pythonFStringValuegroup to its owncontainslist to simplify matching these nested replacement fields. Then the end pattern can probably be reduced to a closing brace.Ping @zvezdan
I cannot add it to its own contains list, it should only take effect on the right side of the colon, and the expression needs to be highlighted on the left side
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
have contacted the maintainer (...) But there seems to be no response
@A4-Tacks I found four emails from you in the spam quarantine of my email provider because they were ranked as spam at high-level of probability, due to the following facts:
- several of them sent successively immediately one after another -- raises suspicion
- they had an attachment encoded in base64 with rarely used extension (
.patch) and typetext/x-diff-- could have sent them as plain text instead - sender's name
A4-Tackssounds like a wordAttacks-- why this choice of name/username/nickname? - sender's email address username part is a seemingly random selection of letters and numbers -- why the need to hide the identity?
- the sender's domain 163.com was suspected as a possible source of spam
Each of these issues individually perhaps wouldn't be a problem, but taken together they resulted in your email messages being quarantined by my provider. I review quarantined messages once a week and I see them now. I allowed them to be delivered and carefully opened them (because I didn't trust them either) as raw messages, copied the base64 encoded content of the attachment into a file and then decoded it into an output file. It is indeed the patch similar to the one you have here.
As you can see, I did not ignore your messages, but, rather, you caused the issue by your choice to send the messages as shown above.
Lessons learned:
- My identity is not hidden and if you're sending me a personal message you should not hide your identity either. Our communication remains between us only. It also helps with giving you credit later.
- If you're sending patches, they're text and you can send them as plain text, to avoid spam filters ranking them.
- If the message with attachment didn't receive response, re-sending it repeatedly is not going to help. Assume the spam filter got activated and send a simple message to start the communication. Once we exchange a few messages, the spam filter will also act differently.
- Creating a GitHub issue or PR and tagging me on it as @dkearns did here is perhaps the simplest way and avoids all email spam filter issues. 🙂
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
Ping @zvezdan
Thank you both @dkearns and @A4-Tacks!
I'm currently testing this change, but also a few other options that I worked on and some other people sent. Some of the options are whether the bytes should be treated separately from strings, allowing for separate highlight coloring for people who prefer that, etc. This patch/issue is not making that distinction. Also, getting the contains things right can be tricky. I have an implementation of similar handling already for docstrings and my personal reStructuredText syntax highlighting setup and I'm trying to get the best combination of options and functionality.
In the meantime, I'm inclined to send a simpler PR that would just support f-strings correctly without trying to do any interpretation inside them. That would resolve some other already open issues, as well as partially covering this one. Then, I am testing a setting similar to python_no_doctest_highlight that would allow switching ON/OFF the highlighting and interpretation of the content of f-strings. I believe that such a change would add more flexibility for users with different preferences.
In any case, I am working on this change and will incorporate all valid ideas including the ones from this issue and the corresponding patch. Thank you again and I'll keep you posted about the results of my testing soon.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
I had a quick attempt at this on the back of @A4-Tacks' PR. This patch allows for replacement fields in the format spec and avoids premature termination of the expression by spurious matches for the conversion and format spec delimiters.
IIUC, the following are correctly matched:
# Lib/fractions.py digits = f"{significand:0{point_pos + 1}d}" # Lib/test/test_fstring.py self.assertEqual(f"sadsd {1 + 1 = :{1 + 1:1d}f}", "sadsd 1 + 1 = 2.000000") # example from PEP - 701 f'Useless use of lambdas: { (lambda x: x*2) }'
@zvezdan and @A4-Tacks, this is just intended as a proof-of-concept but if you think this is worth pursuing I can make a PR for consideration as a possible alternative to #14048.
diff --git a/runtime/syntax/python.vim b/runtime/syntax/python.vim index 7aa82f1..33c024e 100644 --- a/runtime/syntax/python.vim +++ b/runtime/syntax/python.vim @@ -143,17 +143,35 @@ syn keyword pythonTodo FIXME NOTE NOTES TODO XXX contained " Triple-quoted strings can contain doctests. syn region pythonString matchgroup=pythonQuotes
- \ start=+[uU]\=\z(['"]\)+ end="\z1" skip="\\\\\|\\\z1" + \ start=+[uUbB]\=\z(['"]\)+ end="$\|\z1" skip="\\\\\|\\\z1" \ contains=pythonEscape,@Spell syn region pythonString matchgroup=pythonTripleQuotes - \ start=+[uU]\=\z('''\|"""\)+ end="\z1" keepend + \ start=+[uUbB]\=\z('''\|"""\)+ end="\z1" keepend \ contains=pythonEscape,pythonSpaceError,pythonDoctest,@Spell syn region pythonRawString matchgroup=pythonQuotes - \ start=+[uU]\=[rR]\z(['"]\)+ end="\z1" skip="\\\\\|\\\z1" + \ start=+\%([bB][rR]\=\|[rR][bB]\=\)\z(['"]\)+
+ \ end="$\|\z1" skip="\\\\\|\\\r\=$\|\\\z1"
\ contains=@Spell
syn region pythonRawString matchgroup=pythonTripleQuotes
- \ start=+[uU]\=[rR]\z('''\|"""\)+ end="\z1" keepend
+ \ start=+\%([bB][rR]\=\|[rR][bB]\=\)\z('''\|"""\)+
+ \ end="\z1" keepend
\ contains=pythonSpaceError,pythonDoctest,@Spell
+syn region pythonFString matchgroup=pythonQuotes
+ \ start=+[fF]\z(['"]\)+
+ \ end="$\|\z1" skip="\\\\\|\\\z1" + \ contains=pythonEscape,pythonFStringEscapedBrace,pythonFStringReplacement,@Spell
+syn region pythonFString matchgroup=pythonTripleQuotes + \ start=+[fF]\z('''\|"""\)+ + \ end="\z1" keepend
+ \ contains=pythonEscape,pythonSpaceError,pythonFStringEscapedBrace,pythonFStringReplacement,pythonDoctest,@Spell+syn region pythonRawFString matchgroup=pythonQuotes + \ start=+\%([fF][rR]\|[rR][fF]\)\z(['"]\)+
+ \ end="$\|\z1" skip="\\\\\|\\\r\=$\|\\\z1" + \ contains=pythonFStringEscapedBrace,pythonFStringReplacement,@Spell
+syn region pythonRawFString matchgroup=pythonTripleQuotes + \ start=+\%([fF][rR]\|[rR][fF]\)\z('''\|"""\)+ + \ end="\z1" keepend
+ \ contains=pythonSpaceError,pythonFStringEscapedBrace,pythonFStringReplacement,pythonDoctest,@Spell
syn match pythonEscape +\\[abfnrtv'"\\]+ contained
syn match pythonEscape "\\\o\{1,3}" contained
@@ -161,7 +179,42 @@ syn match pythonEscape "\\x\x\{2}" contained syn match pythonEscape "\%(\\u\x\{4}\|\\U\x\{8}\)" contained " Python allows case-insensitive Unicode IDs: http://www.unicode.org/charts/
syn match pythonEscape "\\N{\a\+\%(\s\a\+\)*}" contained
-syn match pythonEscape "\\$"
+syn match pythonEscape "\\\r\=$"
+
+syn region pythonFStringReplacement matchgroup=pythonFStringBrace start=+{+ end=+}+ contains=pythonFStringExpression contained + +" Skip contained '[:!='] +" TODO: this should contain @pythonExpression rather than TOP +syn region pythonBrackets start="{" end="}" contained contains=TOP transparent +syn region pythonBrackets start="(" end=")" contained contains=TOP transparent +syn region pythonBrackets start="\[" end="]" contained contains=TOP transparent + +" TODO: contains (yield_expr | star_expressions) +syn cluster pythonExpression contains=pythonNumber,python.*String,pythonBuiltin,pythonBrackets + +syn region pythonFStringExpression + \ start="." + \ end="\ze[=!:}]" + \ contained + \ contains=@pythonExpression + \ nextgroup=pythonFStringEquals,pythonFStringConversion,pythonFStringFormatSpec + +syn match pythonFStringEquals "=" contained nextgroup=pythonFStringConversion,pythonFStringFormatSpec +hi def link pythonFStringEquals Special + +syn match pythonFStringConversion contained "![ars]" nextgroup=pythonFStringFormatSpec +hi def link pythonFStringConversion Special + +syn region pythonFStringFormatSpec + \ matchgroup=Delimiter + \ start=":" + \ matchgroup=NONE + \ end="\ze}" + \ contained + \ contains=pythonFStringReplacement +hi def link pythonFStringFormatSpec Special +
+syn match pythonFStringEscapedBrace "{{\|}}" contained
" It is very important to understand all details before changing the
" regular expressions below or their order.
@@ -312,9 +365,13 @@ hi def link pythonComment Comment
hi def link pythonTodo Todo
hi def link pythonString String
hi def link pythonRawString String
+hi def link pythonFString String +hi def link pythonRawFString String hi def link pythonQuotes String hi def link pythonTripleQuotes pythonQuotes hi def link pythonEscape Special +hi def link pythonFStringEscapedBrace Special
+hi def link pythonFStringBrace Include
if !exists("python_no_number_highlight")
hi def link pythonNumber Number
endif—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A4-Tacks
I had a quick attempt at this on the back of @A4-Tacks' PR. This patch allows for replacement fields in the format spec and avoids premature termination of the expression by spurious matches for the conversion and format spec delimiters.
IIUC, the following are correctly matched:
# Lib/fractions.py digits = f"{significand:0{point_pos + 1}d}" # Lib/test/test_fstring.py self.assertEqual(f"sadsd {1 + 1 = :{1 + 1:1d}f}", "sadsd 1 + 1 = 2.000000") # example from PEP - 701 f'Useless use of lambdas: { (lambda x: x*2) }'
Why is the def abnormal after this? Did I apply the damaged patch?
# Lib/fractions.py digits = f"{significand:0{point_pos + 1}d}" # Lib/test/test_fstring.py self.assertEqual(f"sadsd {1 + 1 = :{1 + 1:1d}f}", "sadsd 1 + 1 = 2.000000") # example from PEP - 701 f'Useless use of lambdas: { (lambda x: x*2) }'
def foo() -> None: pass
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
Why is the def abnormal after this? Did I apply the damaged patch?
Sorry, I only tested against plain f-strings and overlooked the use of contains=ALLBUT,... in a few places throughout the syntax file which includes all contained groups.
pythonAttribute is using ALLBUT so pythonFStringExpression is being included there and matching from assertEqual onwards. You can probably get away with setting python_no_highlight_builtin to disable that for demonstration purposes but it would be better just to test against plain f-strings for now and I'll look at integrating it properly with the existing use of ALLBUT.
@zvezdan, this use of ALLBUT is generally a problem. E.g., self.TODO matches with pythonTodo which is obviously supposed to be contained to comments.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
@dkearns The places where ALLBUT is used were added because they were needed to correctly display syntax in doctests, matrix multiplication, and when an object attribute name matches a builtin name. Any of these ALLBUT lists can and should be extended if needed when adding new features, such as f-strings. Of course, we can also have a separate conversation about the use ALLBUT in general and possible better solutions for the existing usage.
However, the PR associated with this issue is trying to do two things: add f-string support and change a definition of strings to include bytes. I prefer separate changes for separate purpose that can be also separately reverted if needed. Adding a full support for f-strings with all the correct contains lists is tricky by itself and, as I mentioned earlier, might be best done iteratively in separate changes. First a simple support for f-strings to be correctly highlighted as strings. Then more complex contains features.
There are other contributions and options that I'm looking into. Some of them prefer bytes to be a separate highlight category. People also prefer having an option to switch features ON/OFF. I doubt that any of my own or contributed changes, including this PR, will go in directly as is into the syntax file. A combination of them, that I'm working on, sent as smaller separate commits that add features and functionality with increasing usefulness and with switches for their use will be probably the result of this work.
Give me a couple of days to prepare the changes please. Then we can start closing the outstanding issues and PRs as we commit them.
Again, I truly appreciate all the contributions and ideas for improvements from all of you!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
Sure, I just posted my PR for discussion purposes. Feel free to take as much or as little of it as you like.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jgb
Any updates on this one? Would be lovely to have good support for f-string syntax!
I personally still use Vimjas/vim-python-pep8-indent to fix indentation and vim-python/python-syntax for better syntax. It would be great if both syntax and indentation could be brought up to speed on modern python standards.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
I previously stated what I feel should be changed / improved in the comment above.
Several people sent patches and I had a few candidates in my local changes for the syntax file.
I'll try to send a sequence of incremental improvements to the syntax file to bring it up-to-date.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Hi @zvezdan,
I've sent #17548 as a possible first step for this.
-
Does the scope address your previous comments, or should the
pythonFStringFieldchanges be in a separate PR? -
Do you have syntax tests that we can use for regression testing?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Hi @zvezdan,
Do you have time to review #17548 ?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
zvezdan left a comment (vim/vim#14033)Next weekend. I’m writing this from a phone and won’t have a computer available until then.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Hi Folks,
I've closed #17548 in favour of a more structured approach, to support all of the literal string syntaxes in Python 2.7 and 3.*.
I'll send a series of smaller PRs as follows:
- Python 3 bytes and raw bytes
- Restrict Unicode escapes to strings
- Python 2 b-strings (allowed but ignored in 2.7)
- Python 2 u-strings
- Restrict Unicode escapes to u-strings
- Python 3 f-strings
- Python 3 f-string fields
- Python 3 printf string formatting
- Python 2 printf string formatting
We also need tests to ensure that we support as many cases as possible, and existing highlighting is not impacted. @dkearns added a large test to #14057, but some of that appears to be copied from https://github.com/python/cpython/blob/main/Lib/test/test_fstring.py. If we reuse that code, we have to verify the license and copyright. It may be easier to create our own?
Refs:
- https://docs.python.org/2/reference/lexical_analysis.html#string-literals
- https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Mikhail f. Shiryaev
Felixoid left a comment (vim/vim#14033)It's just an opinion here, but Python 2 has been dead for over 5 years. Let the noble rest in peace.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)That's true, but folks are still maintaining legacy Python 2 codebases. Vim itself supported 16-bit MS-DOS until 2007 :-)
As long as we have https://github.com/vim/vim/blob/master/runtime/syntax/python2.vim in the source tree, I'd like to keep it functional. Especially the compatibility features which encourage incremental migration.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)I've opened #17726 for bytes, b-strings and u-strings.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#14033)We also need tests to ensure that we support as many cases as possible, and existing highlighting is not impacted. @dkearns added a large test to #14057, but some of that appears to be copied from https://github.com/python/cpython/blob/main/Lib/test/test_fstring.py. If we reuse that code, we have to verify the license and copyright. It may be easier to create our own?
https://github.com/python/cpython/blob/c7d24b81c376b0cf0b34f861cb18c1b1e4eac27b/LICENSE#L65C1-L67C33
Starting with Python 3.8.6, examples, recipes, and other code in
the documentation are dual licensed under the PSF License Version 2
and the Zero-Clause BSD license.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
dkearns left a comment (vim/vim#14033)As long as we have https://github.com/vim/vim/blob/master/runtime/syntax/python2.vim in the source tree, I'd like to keep it functional. Especially the compatibility features which encourage incremental migration.
Yes, please. There's no reason not to continue maintaining while there's someone willing to do the work.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
zvezdan left a comment (vim/vim#14033)It's just an opinion here, but Python 2 has been dead for over 5 years. Let the noble rest in peace.
I agree with @Felixoid!
I'd like to draw attention to the note in the comment at the top of python2.vim syntax file.
At Bram's request, I added the file as a historical record for the benefit of the remaining Python 2 users, from the last commit that still supported correctly both Python 2 and 3 (up to 3.5).
I wanted to keep only Python 3 support and had a change for the main python.vim syntax file that was breaking the compatibility with Python 2 (it was necessary), but Bram insisted on keeping at least some support for Python 2 users through this file. No further changes were intended to ever be made in that file.
My opinion is that:
- the number of Python 2 users is dwindling
- none of them complained about the
u,b, orrstring highlight rendering since the split of syntax files happened - maintaining a historical record file, such as python2.vim with after the fact corrections has diminishing returns
- instead, Python 2 users should be encouraged to move on from the deprecated and unsupported language version
- to me this is a topic of a language support, not an editor support
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#14033)Thanks. I understand your reasoning and it is causing a bit of a pain to maintain it. However, there are obviously still people that want to make further improvements to python2.vim for one reason or another. So if you do not want to maintain this anymore, you can pass the maintainer role to e.g. @f4nb0y if he wants to make further improvements there.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
zvezdan left a comment (vim/vim#14033)@chrisbra It's OK. If the majority feels we should update, I'm OK with that. There shouldn't be any frequent updates to the python2.vim syntax file after this small highlight correction for Unicode escapes and strings.
We should just address the comments on the latest PR from @f4nb0y, see if he wants to merge the changes I've done in #17735, and add the change to the date of last update and to the note that indicates that there was a change after that last historical record commit.
If @f4nb0y wants to commit only his PR, that's also OK. I can update the comments, note, ..., later.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Thanks @zvezdan - I've addressed your comments in #17729.
The only other change I'm proposing for Python 2 is highlighting b-strings. This prefix was added in PEP 3112 to encourage migration to Python 3.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #14033 as completed via baa781a.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mikhail f. Shiryaev
Felixoid left a comment (vim/vim#14033)I am not sure why the issue is closed, the commit only adds something to the python-2, but not the f-strings
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
Reopened #14033.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Zvezdan Petkovic
zvezdan left a comment (vim/vim#14033)The only other change I'm proposing for Python 2 is highlighting b-strings. This prefix was added in PEP 3112 to encourage migration to Python 3.
@f4nb0y Thanks. I'm OK with that if you want to add it. Bytes were added in Python 2.6. IUC, that would only highlight the letter b together with the string (which is bytes in Python 2), so, it's probably not that important to Python 2 users and is probably rarely used in the existing code. However, if consistency is the goal, we could add it.
Do you want to prepare another PR? I see the tests for bytes are already in the previous PR and the dumps would probably need to be adjusted after the highlighting change.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Done.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
glepnir
Closed #14033 as completed via glepnir/neovim@3eb597c.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
jgb
jgb left a comment (vim/vim#14033)@glepnir this issue is about proper f-string syntax highlighting support, which isn't implemented yet, so I think it's too early to mark this as completed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
glepnir
Reopened #14033.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
glepnir
glepnir left a comment (vim/vim#14033)Weird, I don't touch this issue before. reopend..
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #14033 as completed via b7fc24d.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mikhail f. Shiryaev
Felixoid left a comment (vim/vim#14033)And it's closed again
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#14033)yes, because b7fc24d introduced f-strings for python syntax highlighting
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
A4-Tacks
A4-Tacks left a comment (vim/vim#14033)Is the expression in brace not highlighted?
current:
Screenshot_20250718_043941.jpg (view on web)
expected:
Screenshot_20250718_043926.jpg (view on web)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
chrisbra left a comment (vim/vim#14033)ping @f4nb0y
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)The next PR handles f-string replacement fields.
Working on it now :-)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Opened draft PR #17784
Please confirm that it matches fields and delimiters in all cases, then we can discuss highlighting inside fields.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Mikhail f. Shiryaev
Felixoid left a comment (vim/vim#14033)Thanks. Could you reopen the issues, please?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
dkearns
Reopened #14033.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
glepnir
Closed #14033 as completed via glepnir/neovim@9df9d3a.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
Reopened #14033.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Rob B
f4nb0y left a comment (vim/vim#14033)Hi Folks,
#17962 is the final PR for this issue. Please confirm that it highlights all of your examples inside f-strings, and does not regress highlighting anywhere else.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #14033 as completed via d2b28dd.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.