[Top][All Lists]

[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:


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 "", 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:

color green "(\{|\}|\(|\)|\;|\]|\[|\\|<|>|!|=|&|\+|-|\*|%|/|\?:|\^|\|)"
color green "(\{|\}|\(|\)|\;|\]|\[|`|\\|\$|<|>|!|=|&|\|)"
color brightmagenta "(\(|\)|\[|\]|\{|\})"

color green "[{}():;|`$<>!=&\\]" "(\]|\[)"
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

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

>> color red ""(\\.|[^"\])*"|'(\\.|[^'\])*'"
> Okay.  You've tested this, right?  Your strings in Lua scripts
> still get colored correctly?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]