POLL: Should autoCompletion updater go in CollectionInterface, ConfigUpdater, or both?
-
One of the improvements I had thought of for my CollectionInterface plugin was to be able to automatically create or update the autoCompletion list for any downloaded UDL. (It wouldn’t be a fancy one with function-parameter completion: it would just look through the keywords in the UDL, and any keyword that didn’t already have an entry in the autoCompletion could be added.)
But when I started thinking about the implementation, I began to wonder whether CollectionInterface was really the right place, or whether it would go better in the ConfigUpdater plugin, or whether it should be available in both.
- CollectionInterface
- PRO: Adding the autoCompletion when downloding the UDL would be convenient for the user, just like you can already download the autoCompletion if it exists in the Collection when downloading the UDL
- CON: It seems somewhat “out of scope” for a plugin whose sole purpose is to facilitate downloading and installing the files that are found in the Collection: if the autoCompletion isn’t already in the Collection for a given UDL, does it really make sense to create it? Or should the CollectionInterface be focused solely on what’s in the Collection?
- ConfigUpdater
- PRO: it would simplify the process, since you could run the autoCompletion update command once, and have it create or update all the autoCompletion files, whether for already-existing UDL, recently-installed UDL, or even some or all of the languages in langs.xml
- PRO: it makes more “sense” to me to create/update config files in the plugin named “ConfigUpdater”
- CON: it would mean that people would need both plugins installed to be able to download a UDL from the Collection then create/update a simple autoCompletion file
- Both
- PRO: Someone who uses just one of the two plugins would still get the benefit of the feature
- CON: duplicated code would mean that I’d have to make updates to both plugins anytime a bugfix or feature improvement was made to the autoCompletion-updater in either, and they’d likely get
But I thought that getting input from some regular users of the Community might help me decide which is best. Feel free to answer the poll, respond with text, or both.
- CollectionInterface
-
@PeterJones ,
I had to go to your linked page to better understand what you were saying this feature would entail, and frankly, if it’s creating a new file for non-existing A/C file, that belongs in the purview of the Collection Interface app, when it’s downloading a language without one.Config updater should be just what it says, updates config already existing, not creating new files that didn’t exist. I can see why you might want to do it in Config Updater, if someone d/l a language not in the current list of NPP languages, but should you really be creating something for someone that didn’t want it included? Or maybe they’re testing a language and aren’t ready for that…and then it needs to be updated, how will you or the author know at what level it is? Updater should only be updating approved languages in the NPP library, not for languages that are not part of the controlled system that you have a hard benchmark to test against.
In the long run though, it is your baby, so, take my opinion with a grain of salt. I’ll try to break it for you if it’s got any bugs. :-)
-
I do agree that in the ConfigUpdater, I wouldn’t want to automatically do every UDL and Lang – there are 90+ builtin languages, and a user would probably only want to add one or two, so it would be a separate menu command there, and the user would just select the desired languages. But I can see your point that it goes beyond the scope from “updating” to “creating”, so it’s as much out-of-scope in ConfigUpdater as it is in CollectionInterface.
But if it’s only for UDLs in the CollectionInterface, it just hit me today: rather than cluttering the CollectionInterface plugin with that code (and it would have to include some libraries that aren’t currently in the plugin), and trying to come up with some complicated logic on how to decide when to offer to create AC and when not to… instead, I could just do the processing in the Collection: when someone submits a UDL without an AC file to go with it, an Action in the Collection repo could generate the AC files and automatically add them to the collection – that way, when the Collection Interface plugin is run, it will just see all the AC files available, and not have to do anything fancy on its end – it would avoid the annoying extra prompt to ask if the user wants it created, since the current GUI for the plugin already lets them decide whether or not to include AC during the UDL download. (And that way, I can do the XML/JSON processing in Python rather than C++, which might be easier for me to implement.)
So, for now, I’m going to work on adding the feature to the Collection actions, and just leave both plugins as-is (at least, for now).
-
@PeterJones ,
Logical evaluation. If the file is essentially going to be a skeleton of keywords already in the UDL’s 8 Keywords dialogs for non-existent files, maybe that will prompt some fans that want to flesh out the rest of the A/C file with descriptions and parameters if the file already exists for them to work on, and at that point, they could then resubmit it to the respository for updating.It would make the learning curve a lot easier if there were already a working example without all the bells and whistles to work from. I know it would have been nice for me, if someone had made a skeleton file for me to enhance. :-)
Of course, that would mean my UDL would lose it’s standing of being one of a handful of UDL’s that include that in the package…but…small price to pay for a sense of completeness for the other packages. :-)
-
@Lycan-Thrope said in POLL: Should autoCompletion updater go in CollectionInterface, ConfigUpdater, or both?:
that would mean my UDL would lose it’s standing of being one of a handful of UDL’s that include that in the package
… then you probably don’t want to look at https://github.com/notepad-plus-plus/userDefinedLanguages/tree/master/autoCompletion now. ;-)
Maybe it will help if you think of it like this: It’s now one of the select handful of human-crafted autoCompletions in the Collection, sticking out among the more than 300 auto-generated AC files. :-)
-
@PeterJones ,
Good point. Luckily, it’s still one of a handful of functionList files…at least until you figure out how to mass produce those. :-)
