1. Remove old keywords
2. Move type related keywords from instruction word to type word
3. Add current standard built-in objects as types
4. Add most commonly used web apis as types
5. Remove document properties and methods from window instructions
6. Remove ambiguous properties, methods and events from window instructions
Note: Your copy of langs.xml (and other files in %appdata%) does not automatically update when there are changes to langs.model.xml. If you have been using and upgrading Notepad++ for a long time then your copy of these files may be missing a lot of updates.
There are currently three groups of keywords:
- Instruction word: instre1
- Type word: type1
- Window instruction: instre2
The way I see it:
Instruction words are keywords.
Type words has a mixture of things. Most are global objects that you would use with new, extends, instanceof or have static methods. Some special words would also be in this group depending on your interpretation.
Window instructions are global functions and variables/properties.
These are mostly keywords with the majority also being reserved words.
My first recommendation is to remove the ‘future reserved words in older standards’ keywords. These are no longer keywords and don’t need to be highlighted.
True, false, and null are reserved keywords but they are also type literals. I have moved them from instruction words to type words.
Prototype is not a keyword or instruction but does have special meaning. Since it was also already included in the type words I have removed it from here.
There are a few other words that would be nice to have highlighted in the correct context but the lexer can’t do that. These remain excluded from the list; as, from (import/export statements), get, set (object property getters/setters).
In addition to the type literals I have also added arguments since it is a special identifier in functions.
The object prototype is another special case. I don’t think the methods on the prototype should be highlighted as types and they don’t really belong in the window instructions either. Some people probably want these highlighted so I’m not sure what to do with these.
I’ve added all the standard built-in objects with the exception of the function properties, which have been added to the window instructions, and most of the control abstraction objects, these are experimental or don’t have global objects.
This does raise the question of where the isFinite and isNaN functions should be. Do they belong with the other global functions or are they a special case that belongs here because you need to use them when comparing types?
More types are available through the various Web APIs. This list is large and growing so my aim is to only include types that you commonly use with new, extends, instanceof or has static properties and methods.
First I’ve removed all the document properties and other unknowns. These should never have been in this list and is what made me go down this rabbit hole.
There are a large number of properties, methods and events on the window object, so I think there should be a distinction between global objects and functions vs window properties and methods. The globals are what you would commonly use without the window prefix. The others are either common names or ambiguous depending on context so shouldn’t need to be highlighted because you should have the window prefix (or self, globalThis). I’ve excluded some values that haven’t been implemented by all browsers. I haven’t finalised my own list for this section so there will probably be some debate about what to include.
I’m also interested in hearing from any Node.js developers and what they would like to see.
A few changes for stylers.xml
It also has the option CHARACTER which is single quoted strings. The three strings should be labelled DOUBLE, SINGLE and LITERAL. Looking at the other languages there doesn’t appear to be any consistency between if STRING is at the start or end of the label. I think string should be at the end to match html and css.
Adding my list of keywords gets this post flagged as spam. I will see if I can find another way.
The default langs.model.xml
@Mark-Olson Yes, that is my plan. At the moment I just want some feedback from the community on some of my suggested changes.