argumentum

..that's the problem. Jon is mostly unavailable. Jos is presenting an option that does not include him. The whole issue is with Jon's lack of delegation, and if you follow the history of AutoIt's development, that lack of delegation is perfectly understandable. The SVN is not publicly readable, hence my requesting of permission to even think of any changes. Mind you that am a new addition and haven't been here long enough to know exactly how to go about changing the way it is been all this time. But for me to "man up" and ask Jon for something it will have to be clear and concise and, not solely dependent on one forum user, because that user may die ( or something ). So it should be something that does not risk degradation due to so-and-so is not here. Something that can be automated as much as possible and the team that runs the GitHub not be able to screw with this site's repo ( SVN ). All this with the assumption that Jon does not have the time with the hectic pace of GitHub. On the other hand, he does not code UDFs, he's just for AutoIt3 binary, the UDFs is MVP area, so far. I don't know what "picture of reality" will better serve the community, and that is something that Jon would have to thinker with ( along a drink and soft music I guess ) And this is as far as I can contribute as far as ideas, I think. Know nothing of GitHub and don't have the time to take it on my shoulders ( upon myself ) to run it and be the sole maintainer. @Jon, have a read of this thread and whenever you find the time, share your 2 cents.

Ok, @WildByDesign, long time a go, there was a post called WinAPIEx UDF that was later integrated in the standard UDFs. How about we do our community effort of an unofficial UDFs ( like "WinAPIEx UDF" was at one point ) but hosted in GitHub, and take it from there ?.

Ok, power to the people ! , but, who is going to make the bridge between SVN and GitHub ( not you, ok ). But has to be an already MVP to access the SVN. All in all, we are brainstorming a proposal for Jon to say yay or nay. On the other hand, going all GitHub would open up for expanding the standard UDFs, but it would certainly be more hectic, ..and would need approval 🤔 ? I guess I did it again. But is not to bug anyone. Is to bring ideas to the "think tank". Since I can not state what we are going to do, how things are going to work from now on, and am afraid of unintended consequences, ...bringing a bunch of doubt and assumed limitations, clarifies things. Like your "we can GitHub it" was a surprise for me.

Since the GitHub would require a single person to attend to it ( I guess, I don't have much experience with it ), packing the UDFs when they are not "in between" updates, and that is mainly you, JPM, mLipok, water, etc., making a post announcing a, semi-annual update or whenever there are changes, would be better than just clone to GitHub. The idea of using GitHub is good, but not as a clone, rather as "here is a zipped update", would avoid the control issues that arise from people screwing the UDFs. This site is just as good to collaborate without going all GitHub. What do you think @Jos ?

A zip file is not a great compressor but the most flexible packer for use from WinXP to Win11. Bandwidth is worse but flexibility is better. On that: thinking ahead on what that implementation would need ... . Would be nice if the release.inf ( to give it a name ) was compatible with that unrelated project to future proof the possibility of the integration of both, by the community driven updater. And as you can see, I too tend to over engineer / over think stuff. There is no need for the release.inf to be compatible ( but it'd be nice ) If the release.inf file is a good standard, anyone can make a package manager based on the release.inf standard. So getting that release.inf well thought out ( by those with experience with that type of software, I've never used one ) is important, I believe. Not important to this project but again, it'd be nice to think ahead. Look at the code of the 2 scripts already there. Then we follow the same criteria for this updater. ... I just wanted a separator here When texting my kids a question, if they don't respond within a few minutes, I text: "yes,no,maybe" like in, answer !. Since I don't pay much attention to emotional damage 🤷‍♂️, at times I don't filter myself adequately, or even close. Or just no filter. ...because I process stuff different ( maybe ) and things are "right to the point", is my default trend of thought. My mind works on a "if, then, else" in a loop, to the point that there are so many if,then,elses that I get overwhelmed, and go right to the end result of my if,then.elses, hence a stern yes/no/maybe. I mean no harshness. The avatar I use is the best I found to show myself in a picture 😅

on that front, evaluating a JSON or INI or something, to hold the distro's info would be beneficial for a standardized updater that would keep in mind "what if" we integrated it an all-in-one in the future and/or common interaction, as a standard. Ok, I too have to go, catch some ZZZzzz

You know that in "\AutoIt3\Extras\AutoUpdateIt\" there are 2 scripts to update AutoIt and SQLite. Maybe we can ask for a UDFs update script and place the UDF.ZIP file somewhere on this site and that would not require any changes for the current installer nor wait for a next release to get what we wanna see. Just an idea

@SOLVE-SMART, I see the confused emoji. You should know that I have you in the highest regards. All you do is well done and you have an amicable demeanor, yet I answered with an abrupt but clear answer. And that is because asking for what the OP is presenting is a "no-go", "not gonna happen" kind of situation. So, how can we rescue the proposition ?, a compromise. Don't go overboard with the request. Lets see if the independent UDF portion can be updated more often. If that takes off and becomes a reality, then expanding it to some of the UDFs from the WiKi ?, maybe ?. But for now, focusing on distributing the standard UDFs more often is a goal that merits attention. And even that has a strong opposition in my view. So, baby steps. In any case, a package manager for GitHub hosted projects is a simple thing compared to the private ( until full release ) of the standard distribution UDFs. I say that we focus on that if we expect any attention. My 2 cents. Am a forum user just like you in regards to this.

Ok that did solve the long list of unrelated variables but also took away other new interesting features. Any way to separate the type of autocomplete ?, variables vs. functions ? .... but I'd like to keep the variables of the includes that are not UDFs ...so, a way to exclude via an exclude list of variables to not present as part of the list of variables 😅 Goodness, am a pain. I should have asked these questions a year ago when you were actively working on it. Edit: @Jos please put the baseball bat down and don't hit me. It is as it is, and if I participated earlier ... it wouldn't be so frustrating for you dealing with these questions so late in the game.

The site getting hammered..., is just that. But is mostly the DB engine having trouble keeping up with request. Like a DDoS on the DB. But just reading files should not be a problem. GitHub hosting the SVN may not be accepted because it all works "like a well oiled machine" as is. All the scripts that are made for SVN .... moving to GitHub will not happen. I don't see that happening. Building the help file, zipping the UDFs and uploading to this site can be done in under 30 minutes ( that given the automation would be 5 to 10 min. of total human work ), so that is not like "OMG, what a pain" when Jon finds the time once the UDFs are finished**. **We are all working independently without a central coordination. We take "something" and work on it when we have the time. All we'd have to do (MVPs), is to make a post in the MVP area and ask for status, and if the status is "am good" for everyone, then that is a good moment to distribute the \includes\ folder ( with a newly compiled help file ). But, that is my opinion and not anything that the MVPs are aware of because so far, am the only one on this thread, and there is no thread discussing what we are cooking here on this thread elsewhere. When we get something reasonable here on this thread, then there is something to bring up in MVP chat 🤔 To recap: This site is fine for the UDFs distro. The copy of the files to GitHub is going to be a very hard sell ( to not say impossible ). Also, AutoIt is not open source. And I don't know what legality would apply if going to M$ owned GitHub. That as disregarding as we may be of how international software legalities work, if kept inhouse, there is no risk of future confrontation due to, ??? something.

@genius257, I see the sad emoji. And there is nothing I can do about that strict "no" to the notion of a broader use of the installer Actually, just this notion of making an on-line installer, separating the AutoIt3 stuff from the UDFs, is something that is not wanted from the higher ups as it takes a whole lot of work to keep up. Convincing them ( am part of them, but not them all, nor the last word ), is going to take a well thought out plan. Something that would invite to invest into changing the way things are, that as you could imagine, is set in stone. So, we either stay on track in regards of what can be done in regards to having the UDFs updated more often, or sincerely forget that anything will change. If the idea we come to, is sound, and makes Jon's life easier, and the consensus in the MVPs agree, then maybe, just maybe, we can have it.

oh !, but I do use your script. Is the best there is. Just awesome. The problem is in that while coding I press "$i" and the list from every include makes it cumbersome to select those in the script, hence my request.

No. And your insistence ruins even the slightest possibility of any change to the current installer.

One thing is to install/update AutoIt and it's UDFs, and another outside of my thinking mind, is to use this site and it's product ( AutoIt3 ) to piggyback custom user UDFs, as if this site would vouch for them. And I read that npm had their issues with stuff. My idea is in regards to AutoIt's core components and UDFs. No other UDFs should be included. And don't get me wrong, I'd love to include a whole lot of awesome UDFs that are around but, is not the idea. At least that is something that I would not agree to if I was the owner of this site and project.

ok, did that. The hidden pic above is what am complaining about. How can I declare to only include the variables is the current script ?