Menu
▾
▴
#928 dot character not an operator
First off, I am using Notepad++, the lastest version. With Lua.
The issue is that with keywords such as this and self and any keyword that is not entirely defined, the this.{word} this will become unhighlighed. This applies as far as I can see to any keyword when followed by a .{word} when the {word} is not a defined keyword.
Speaking as a Lua lexer contributor...
"this" is not a Lua keyword. "self" is not a Lua keyword. "self" is an identifier that has special meaning in certain places.
If Notepad++ marks them as such, then I disagree with it. If Notepad++ regard them as special identifiers, then I suggest that Notepad++'s developers contribute a patch to add a new style for such identifiers. Marking them as keywords is plain misleading.
A keyword followed by a ".{word}"? For actual keywords, such a statement is illogical.
This is most certainly can be a lua Keyword, same as self. They happen to the examples I am refering to because in my version of lua they are very important, I fail to see when the example doesn't apply to you, the overall issue no longer exists.
And that is not even the issue at hand, the issue would still exist, because any keyword that is followed by a '.' will cease to become highlighted, which is a problem.
Let me be clear, the issue applies to all lua keywords that are not followed by a .{keyword}
Not that anyone would ever go if. but the feature should exist for this, self etc
Now you mention ".{keyword}", but it was ".{word}" a little while ago. I think some clear examples would be good. Provide a few whole lines of examples. Since _keyword_ followed by a "." and something else is illegal in _normal_ Lua syntax, any modification has to be considered carefully or else normal Lua code highlighting might break just so your modified version works.
If you have modified a language's syntax, please don't expect others to instantly understand what you want. Lots of actual examples and sample code for testing is helpful. Also, supporting non-standard syntax modifications is a slippery slope; I steer well clear of that myself so I won't be motivated to hack on such things.
So having said that, I'll leave this to other Scintilla contributors. IMHO, since you are already capable of making significant modifications to Lua, then your best bet would be to make the fixes yourself, and present it for consideration.
I think I have been confused by your yes ".{word}" no ".{keyword}" rules and so on. So there isn't a really clear problem statement or specification, yet you want someone to get on your case immediately. Note that we do not have any telepathic skills that can immediately grok all the non-standard stuff you need done just so. Also, if there are no volunteers to your cause, then do consider paying for it or getting it coded yourself (LexLua.cxx is only about 360 lines).
Lexer contributors normally need (1) test cases that tests the issue at hand well, (2) the program to test the test cases on, often needed for corner cases. In the case of (2), we would need what you use, since you seem to be asking us to support one single organization. What if you come back with a list of modifications a few months down the line when you have moved to Lua 5.2? Then should we all jump up and fix things for one single organization? Special free support forever? As you can see, volunteers are more apt to contribute if everyone benefits, that is, when dealing with a standard language implementation that most people use. Or, the interested party can contribute and maintain those bits of code.
I think realistically acceptance of such things possible if the modifications have zero impact on standard Lua highlighting. But I only speak for myself as a contributor to the Lua lexer. There are many ways of doing this -- e.g. I'd prefer not to change the normal keyword set but to see this as an "add on" behaviour. Good luck.
I was initially confused by this report too. I think what Chris is after is highlighted identifiers rather than keywords since "self" and "this" aren't in the list of keywords in section 2.1 of the Lua Reference Manual http://www.lua.org/manual/5.1/manual.html
With different lexers people have had different opinions on whether '.' should count as an operator and separate identifiers. For C++, x.y is two identifiers split by an operator and you can highlight either but not the whole of x.y. There have been complaints about this but I think it is correct.
For Lua, the opposite approach was taken and x.y is a single identifier. If anyone does offer a modification, it should preserve the current behaviour unless a property is set.
I am going to try this again. I am not a c++ scripter the custom lua I use while exteremly different was not written by me, it also doesn't change the fact that this is a bug in lua, and that a (x.y) will not have (x) highlighed even if it is a keyword. Forget about this and self, they don't matter because with the bug fixed it will go away.
I do not know why you think I expect people to jump up and do something, that is unreasonable, I am meerly reporting a bug. If I was requesting a feature then I would agree a toggle would be nice, but this is very clearly a bug.
A '.' is an operator in lua though, according to the lastest reference manual, and in c++ the '.' is an operator so people's complaints are unfounded there, but according to the lua documentation the '.' is an operator.
Samples, please. Your use of the "keyword" terminology is confusing all of us. Sample snippets will help clear the confusion. Even better, post some screenshots.
In SciTE, the property file allows multiple identifier (or name) classes ("keyword2" etc. in the property file is a bit misleading because it is Scintilla terminology, not Lua terminology) so SciTE already highlights both "string" and "string.byte" identifier patterns through simple identifier matching.
Also, "string." is not highlighted in SciTE because arguably it can be regarded as incomplete. If whitespace is added in between, "string . byte" fails -- arguably that is bad coding style.
The identifier matching scheme can be extended to suit your particular needs, multiple styles are already available. Notepad++ should be able to do something similar.
This is an example, of lua not seeing . as a operator.
See Attached Image.
In this image you will see {this} and {this.foo}
-{this} by itself is highlighted.
-the {this} in {this.foo} however is not highlighted.
Sorry, forgot to login the last time.
In SciTE, I can put "this" and "this.foo" in the appropriate 'keyword' classes for both to be highlighted. However, this scheme is intended for libraries, where the programmer can have better feedback and can confirm that "this.foo" is in fact a legit function. "self" and "this" are just Lua variable identifiers used in a special way -- hence my insistence at clarifying the issue.
But since "self" and "this" are being used as object references in object-oriented-like Lua code, it would be hard to hard-specify names. So a permissive identifier class that highlights like "foo.<any identifier>" might be useful *only* for this case -- such an identifier class may be too permissive for normal libraries. I suppose too that you are using "self" and "this" in this way only in function bodies (another good reason for asking for actual code snippets).
So, it can either be done as:
(a) an optional property
(b) steal one of keyword class 5-8, might be a bad idea
(c) add a keyword class 9
Anyway, I have already too many items in my backlog, I'll leave this to others.
I should point out that unless Chris give clearer (and complete) examples and use clearer Lua terminology, my guess about his use of identifiers like "this" as object references in object-oriented-like Lua code is just that -- a guess. He talked about 'keywords' (probably Lua identifiers) quite broadly but then give only "self" and "this" as examples -- and these two are likely used only in a specific way. If there is a broader intent, then I will let others do the guessing.
this and self are examples that will effect me.
But the fact remains that '.' is considered an operator by lua, yet it is not treated as one in the Lexer.
But if you wanted to have:
var Math = {}
function Math.Add(x,y)
end
You should be able to add just Math to the keywords and have it highlighted while Add is not. This example would apply if I was making a custom table full of functions, and including it in my script file, but what the actual functions are doesn't matter, just the Math.
When I refer to keywords, I refer to anything in Notepad++ lang.xml under the lua lanuage, anything that goes it there can be highlighted.
Whoever who wants to patch this will need to differentiate:
(1) Lua keywords
(2) identifiers treated as global variables (lots of old functions)
(3) identifiers treated as a library name (what Chris wants)
(4) existing library definitions (e.g. string.byte)
I guess (1,2,4) is existing behaviour. For (3), if "Math.Math" then you might not want the second "Math" highlighted. But what about "foo.Math.bar"? These weird cases need to be decided; the fix might not be trivial.
keyword5-keyword8 are currently user-defined in SciTE. Should we break their behaviour or should we add a keyword9?
Well, I'll leave the questions to whoever who wants to patch this.
I think the motivation for the current behaviour is that Lua code generally contains many calls to the standard libraries like string.gsub and table.concat and it was desired that these be distinguished as a whole. Since people are currently relying upon this, it is not reasonable to change the lexer so that it fails. The Lua lexer has worked this way for many years and this issue is the first complaint about it.
It would be difficult, but not impossible to change the lexer so that '.' can be an operator except when it appears inside a known call. It wold be simpler to have an option that would specify whether '.' is an operator.
If a fix would need to be a special option that is overall fine.