In fasmw Esc closes the current file (and whole program only when it was the last file).

This is important to me as well because I don't use the standard includes for windows. Although I haven't seen any conflict yet.


Ideas in no specific order of importance:

Some FASM directives are context specific - the options to format, for example. Can these be supported in a context sensitive way? Should the "include" in "jMP iNclUDe" really be highlighted as a directive?

Some instructions are also used to calculate values and receive incorrect highlighting: ...here SHL gets highlighted as an instruction when clearly it is like * or + in this context.

Data directives should be in a separate category, imho. My reasoning has always been to distinguish things which create output from those which alter internal state of the assembler. This includes: d*, r*, and possibly align. There are other directives which create output, but only in an indirect manner.

Sizable (bigger) compiler output window, or output to new document.

I hope I don't sound like too much of a WIMP when I say this, but I have been spoiled by highlighted code: I find it easier to read, and faster to browse. I would go as far as to say I can code longer with diverse code to look at - tired eyes are less likely to wander. Thank you for taking on the task of extending FASMW - it is a pleasure to use.

Yes. Because it is impossible to have the label "iNclUDe"

It works fine for me: ...I see, it is kind of like a warning to user.

Touché.

And if your code really looks like that then you deserve all the false highlighting you get.

I can easily see myself doing something like "PE64:" or "readable:" label. Luckily, FASM provides a specific compile time error in response to this kind of thing. Sometimes I don't even think when labeling.

In fasm it may get improved in future, as I already consider making all the formatter-specific symbols parsed only inside the formatter's directives (like "format", "section" or "data"), and hence they would no longer be disallowed as labels.

In fact, I just did it.

Here comes the list of formatter keywords that are no longer disallowed as labels, because they are now recognized in specific context only:

Note that "data" is still disallowed as label, because it is also the name of directive.

And the directives that create context where those formatter symbols are recognized are:
Note that this means you still cannot define segment name "code", even though you can create such label.
Also there are some special cases: the "public" directive allows "static" keyword before the label name (and this also means you cannon make the label named "static" public). And "at" or "align" operators in the "format" or "section" definitions are followed by the numerical expressions where formatter symbols are not expected.

Oh. Looks like another forced update to fasmarm is needed.

If you need any assistance, just ask.

Tomasz, will you integrate wink features?

Of course not. As I said earlier I treat it as an enchanced community-developed fork, just what the Fresh was.

Do you think ouadji or someone else will claim money compensation?

They can do it if they want. fasm's license allows a commercial product to be created on its base; so you can create your own fasm version and sell it, if you find people willing to pay for it.