(cold): You are correct, only Khaled has direct access to the mIRC source. However, even without the source many of us here are intimately familiar with how mIRC works inside and out... both on the surface and behind the scenes. You may have noticed many posts where we've logically deduced and narrowed down the exact cause of a bug, and in some cases pointed out exactly how Khaled ought to fix it. Granted, I've never seen a line of code that Khaled sees, but contrary to what codemastr might tell you, I'm not clueless when it comes to programming and I can easily anticipate what approach and oversights people have made (and will make). It's not difficult to wrap your mind around a scripting engine that you've used every day for the last 5 years.
I know what you're talking about, I even agree, since I often see myself being familiar with it as well. What I'm saying is that this experience is not sufficient to bring up any solid argument about such a system, which one may surely have valid thoughts about, based on what he sees from the results he gets, but still, he doesn't *know*, he didn't *read*, he didn't *code*; he just goes by trials, errors and consequent guesses.
IMO, the "parser" subject and others fall into the above category no matter what, regardless of any deduction anyone brings, whether it seems very reasonable or not. I'm not underestimating your programming knowledge, nor any capacities you may have, but it's all into the "guesses" category. Therefore, for me it seems useless to bring into discussion the unknown mechanisms (again: familiar, similar, predictable at some point, but not always - they're *unknown*) available on mIRC. They're just out of our context, I think Khaled is the one who should even consider their functionality and further downsides.
I mean, everytime someone suggests a non-bloated feature that somehow goes against the current parsing logic we see in mIRC, the whole issue about it <being slower|giving much work|having this and these downsides> appears. Based on what, our benchmarks? On the current performance? On *experience*? How could one <measure|predict> the performance of such a feature if he doesn't know how it would be put along with the huge mIRC source code, tested, developed, organized? He doesn't really know how major things really fit into each other, so what's the point of "stealing" them to his argument which says "this feature shouldn't be added because the parser would suffer"?
Well I'm tired of thinking right now; my straight conclusion for the moment is that, IMHO, instead of virtually messing with mechanisms which functionality we could imagine from our experience, and then going to nowhere with what we see in them, when the subject is actually *suggesting features*, we could just develop our ideas and opinions with arguments we're really fully certain of, and deliver them with all the apparent limits to be analyzed and filtered by the proper person (the author, of course).
And if anyone says "that's just giving more work to K", omg, we (me, at least) can perfectly see he manages his priorities already.
(End of rant, sorry if anything)
