-
-
Notifications
You must be signed in to change notification settings - Fork 7k
Small change to PdeKeywords to allow new interesting features #4167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Show me code, or it didn't happen http://memegenerator.net/instance/30625023 |
As you already know, the current PdeKeywords class collects everything in a few internal hash maps. In the process, the processKeywordsTxt() function is also discarding the source of each entry. My change started with introducing a base class for PdeKeyworks as well as an interface that it implements. I moved all the storage in the parent class, while the parsing logic remains in PdeKeywords. I have a SketchVariablesQuickAccessComputer (a subclass of an abstract base class extended by all quick access contributors). Quick Access is entirely managed by adding an instance of a QuickAccessField to while configuring Editor. When a keyword is entered, the different providers have a chance to contribute (contributions are ordered by matching quality). SketchVariablesQuickAccessComputer contributes info based on the contents of the sketch (vars/methods...). Without some changes to PdeKwords, the IDE is showing users information from all the libraries. So the new base class re-introduce some of the context information that the current PdeKeywords parser eliminates (putting the code in a base class rather than in PdeKwords is simply a matter of minimizing the visibility of the changes on existing source code - I often use this approach when extending large codebases to avoid across the board renames). With these extra changes, SketchVariablesQuickAccessComputer can limit its output to information pertaining to the current sketch and its dependencies (that includes local libraries in my case, but there is no special code to deal with that case). |
@ffissore I am closing this as I realize it is creating too much distraction from your work. I will track certain items directly on my fork to further reduce the impact on you. When the code is out there, feel free to look/copy/ignore |
The code currently grabs everything it finds and mixes it together. There is nothing wrong with that and until now there probably never even was a case for any alternative heuristic. The availability of a global search opens the door for many useful things to be done with the keywords. This is about improving the structure to store the info such that the search is more intelligent. The work is truly minimal very isolated (i.e. zero risk)
The text was updated successfully, but these errors were encountered: