Usually I leave parser idiosyncrasies like these alone because of the work involved in fixing them and the amount of things a parser change could break, but I think this specific issue lends itself to neither case:

Description
When you use $& to split long lines and the beginning of your second line starts with ";" or "/*", mIRC treats both lines as a comment. Consider the code:

Code:
alias test_comments {
  echo -a hello world $&
    ; how are you
  echo -a line 2
}


Observed & Expected Results
You can argue that $& should actually skip the ";" comment line, but lets keep things simple and assume $& never skips lines. In that case, the complete unwravelled line would expectedly be "echo -a hello world ; how are you", but mIRC will only echo "line 2", treating the first one as a comment.

The (Simple) Fix
I imagine mIRC keeps a global switch indicating that a line is a comment or not while parsing it. When mIRC goes to line 2, it treats it as a new line in its lexical context, but uses the same global comment switch (and other parse state info) as the preceeding line.

I propose that the parser simply check that the parse state is empty (nothing has been parsed but spaces) before turning the "line is a comment" switch on, since a comment can only occur before actual text has been registered anyway. Alternatively, mIRC could simply check that there is anything in the "command buffer" waiting to be executed, or even check that it came from a previous line if it keeps such state info. All of these options are relatively simple to implement.

This isn't really a do or die issue, but the above code example could actually have a legitimate use somewhere, so there's no reason to leave this behaviour.

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"