[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nano-devel] [PATCH] syntax: lua: fix word boundaries on standard li
From: |
Tom Levy |
Subject: |
Re: [Nano-devel] [PATCH] syntax: lua: fix word boundaries on standard library functions |
Date: |
Sun, 31 Dec 2017 15:30:58 +1300 |
Hi Benno,
> Right. I have grepped the syntaxes for "[^"]\\\<" and "\\\>[^"]"
> and have removed the word boundaries that I think are unneeded.
> Commit 1f48ed04.
> diff syntax/pov.nanorc
> -color brightred "^\<(texture)\>"
> +color brightred "^texture\>"
I think the original "^" was misplaced and this should actually be
color brightred "\<texture\>"
I am not familiar with POV-Ray, but I looked at some examples and
"texture" appears to be just like the other keywords:
texture: http://www.povray.org/documentation/3.7.0/r3_4.html#r3_4_6
camera: http://www.povray.org/documentation/3.7.0/r3_4.html#r3_4_2_1_1
I would also keep the redundant parentheses for consistency with the
other declarations, but I think I can predict your response to that ;)
>> a. If I write invalid code such as "io.foo(...)", nano will highlight "io."
>> ...
>
> But then I would use a different color, brightred, to really draw attention.
> Either that, or not color such partial names at all.
I'll send a patch to remove the partial name highlighting. I don't
think we should report missing functions as errors because our list
might become out of date again.
> Ugh. It colors the leading parenthesis too? Ugly.
Actually, another rule overrides the colour of "(" so it looks fine.
>>> ...
>>> # Symbols
>>> color brightmagenta "(\(|\)|\[|\]|\{|\})"
>>
>> The outer parentheses in both regexes are redundant.
>
> True. But I would write it as: [][)(}{].
I actually thought of that, but the "[][" made me cringe. I looked at
the other files and found two different styles:
syntax/awk.nanorc:16:
color green "(\{|\}|\(|\)|\;|\]|\[|\\|<|>|!|=|&|\+|-|\*|%|/|\?:|\^|\|)"
syntax/pov.nanorc:13:
color green "(\{|\}|\(|\)|\;|\]|\[|`|\\|\$|<|>|!|=|&|\|)"
syntax/lua.nanorc:48:
color brightmagenta "(\(|\)|\[|\]|\{|\})"
syntax/sh.nanorc:12:
color green "[{}():;|`$<>!=&\\]" "(\]|\[)"
syntax/gentoo.nanorc:14:
color green "[{}():;|`$<>!=&\\]" "(\]|\[)"
I'll leave lua.nanorc with redundant parentheses for consistency with
AWK and POV. Somebody else can clean them all up if necessary.
>> icolor red "\<[0-9]+(\.[0-9]*)?(e[+-]?[0-9]+)?\>"
>> icolor red "\<\.[0-9]+(e[+-]?[0-9]+)?\>"
>> ...
>
> If not coloring a trailing dot is good enough, then not coloring a
> leading dot is good enough too. Then you can drop the second regex.
I have a bug in the second regex: "\<\." will never match anything
because \< only matches before a word character (the same reason a
trailing dot is not matched). This bug also exists in syntax/go.lua
line 29. The effect is that the leading dot is not highlighted. The
bug can be fixed by replacing \< with \B (empty string not at edge of
word).
The same thing could be done to match a trailing dot, but two regexes
just to match pesky dots seems a bit much. I'll drop the second regex
like you said, but fix go.lua.
>> icolor red "\<0x[0-9a-f]+(\.[0-9a-f]*)?(p[+-]?[0-9]+)?\>"
>> icolor red "\<0x\.[0-9a-f]+(p[+-]?[0-9]+)?\>"
>
> Okay, but the same as for the decimal: just one regex, and no i.
Why avoid icolor? For the first hex regex it saves 11 characters and
makes the regex much more readable. All the letters (x, a-f, p) are
case-insensitive.
>> color red ""(\\.|[^"\])*"|'(\\.|[^'\])*'"
>
> Okay. You've tested this, right? Your strings in Lua scripts
> still get colored correctly?
Yes.
Tom