Sorry, I hadn't properly explained my motivation:
Continuation lines are processed at an early stage, along with continuation sections and comments. This stage builds a line of code from one or more physical lines, preparing it for the later stages which handle hotkeys, function declarations, commands, expressions, etc. It seems to me that the implementation can either be complicated, duplicating much of the work done by the later stages in order to give the most consistent and sensible results; or (as it is now) simple and fast, giving adequate results in the majority of cases.
At the point continuation lines are processed, no "tokens" exist, only strings of characters. The current parser wasn’t designed from the start with expressions in mind, as they were introduced later. Redesigning it to tokenize everything at an early stage (or the only stage) would give the best results and would give benefits in other areas, but hardly seems justified.
"Fixing" only */ is simple:
Code:
if ((*next_buf == ':' || *next_buf == '+' || *next_buf == '-') && next_buf[1] == *next_buf
|| (*next_buf == '.' || *next_buf == '?') && !IS_SPACE_OR_TAB_OR_NBSP(next_buf[1])
&& next_buf[1] != '='
|| (*next_buf == '*' && next_buf[1] == '/')
|| !strchr(CONTINUATION_LINE_SYMBOLS, *next_buf)) // Line doesn't start with a continuation char.
break; // Leave is_continuation_line set to its default of false.
Quote:
And ; within a string should not begin a comment. It should be treated as a literal semicolon.
The documentation only states that the comment flag must have a space or tab to its left - there's nothing excluding it as a comment flag in a literal string. If you were to say
"treating the comment flag as part of the string would be more useful and intuitive", I'd agree; but I disagree with your statement in principle (->
"should").
Code:
MsgBox % "Hello ; This line begins the string
, World!" ; and this line ends it.
MsgBox Hello ; This line begins the string
, World! ; and this line ends it.
Jamie wrote:
... just like they do in every other language.
polyethene wrote:
Every other language is the same, AutoHotkey should be no different.
I tend to ignore such suggestions when they aren't backed up with any actual reasoning, like why it is that way in other languages. If the reason is obvious (as for "foo ; bar"), there is no need to mention other languages and no added value in doing so. Similarity to any or all other languages is not a goal of AutoHotkey.
I understand that sometimes similarity to other languages can be a benefit, but the similarity itself isn't a reason - the users'
familiarity with it is.
Jamie wrote:
I believe that to defend existing behavior as "correct" through mental contortions does a disservice to AHK, because it inhibits opportunities for improvement.
Wasting time developing solutions for inconsequential "problems" inhibits opportunities for improvement
where it actually matters.
polyethene wrote:
[Ignoring unpaired */] also serves a practical purpose
I agree.
Quote:
Perhaps for added clarity the documentation could be reworded to "the same is true for all other expression operator symbols".
"Symbol" isn't perfectly accurate, unfortunately.
Code:
MsgBox This is part of the message...
and so is this.
Edit: Just because I like wasting time
, making the following change to script.cpp is sufficient for causing */ at the beginning of a line to be entirely ignored if there wasn't a /*.
Code:
if (in_comment_section)
{
if (!_tcsncmp(next_buf, _T("*/"), 2))
{
...
}
else if (in_comment_section)
continue;
}
else if (!in_continuation_section && !_tcsncmp(next_buf, _T("/*"), 2))
{
in_comment_section = true;
continue;
}
Does IronAhk ignore unpaired */?
Login
Register
FAQ
Search
