You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Strings containing TeX are now rendered as format strings #5
This is a consequence of us trying to highlight new formatting '{foo}'.format(foo=1), which is quite a common use-case. I'm a little uncomfortable to highlight everything between $ signs as TeX, as $ are quite popular in various templates, and this can potentially cause a lot of false-positives.
More importantly, switching language contexts (at least in Atom) opens possibilities of bigger highlighting failures. I.e. if you have an unclosed { bracket, the TeX syntax won't end where your Python string ends, likely resulting in the rest of the file highlighted incorrectly.
I'll commonly define a format string on one line and then have the .format on a different line, either due to line lengths or to bunching up all the output strings in one place in the file / project. I think it makes sense to use the formatting syntax even when .format doesn't follow the string.
Please see my explanation for this issue. All the problems listed there are relevant for this case as well.
I will be fixing the incorrect highlighting of nested braces, though. This should reduce the amount of visual noise, but it is a little trickier than it sounds since there are ways to legally nest braces in python formatting ('text {0:{fill}{align}16} text') that we currently highlight.
@eric-wieser
Although the highlighter will not switch to TeX syntax within the string, it should no longer generate visual noise in this use case. I've fixed the way we highlight illegal formatting in v0.4.28 (should be updated in Package Control in a bit). The rule of thumb is that once we detect that the format string uses illegal {} syntax, we ignore that type of formatting for the rest of the string (this works in multiline strings too). I'll write more on the motivation in #12.
Activity
1st1 commentedon Oct 20, 2015
This is a consequence of us trying to highlight new formatting
'{foo}'.format(foo=1), which is quite a common use-case. I'm a little uncomfortable to highlight everything between$signs as TeX, as$are quite popular in various templates, and this can potentially cause a lot of false-positives.More importantly, switching language contexts (at least in Atom) opens possibilities of bigger highlighting failures. I.e. if you have an unclosed
{bracket, the TeX syntax won't end where your Python string ends, likely resulting in the rest of the file highlighted incorrectly.eric-wieser commentedon Oct 20, 2015
Perhaps formatting syntax should be only enabled if
.format(no parens) follows the string?DanielOaks commentedon Oct 20, 2015
I'll commonly define a format string on one line and then have the
.formaton a different line, either due to line lengths or to bunching up all the output strings in one place in the file / project. I think it makes sense to use the formatting syntax even when.formatdoesn't follow the string.vpetrovykh commentedon Oct 20, 2015
Please see my explanation for this issue. All the problems listed there are relevant for this case as well.
I will be fixing the incorrect highlighting of nested braces, though. This should reduce the amount of visual noise, but it is a little trickier than it sounds since there are ways to legally nest braces in python formatting (
'text {0:{fill}{align}16} text') that we currently highlight.vpetrovykh commentedon Oct 21, 2015
@eric-wieser
Although the highlighter will not switch to TeX syntax within the string, it should no longer generate visual noise in this use case. I've fixed the way we highlight illegal formatting in v0.4.28 (should be updated in Package Control in a bit). The rule of thumb is that once we detect that the format string uses illegal
{}syntax, we ignore that type of formatting for the rest of the string (this works in multiline strings too). I'll write more on the motivation in #12.