I like how PhpED uses contexts for syntax highlighting, only highlighting the language that has the cursor. However, it'd be great if, when a file only has a single language, the IDE would always highlight. For example, if I have a file that contains nothing but PHP blocks and whitespace, I'd like the IDE to keep the PHP highlighted even when the cursor is outside those PHP blocks - this might happen, for instance when you open a PHP file and the cursor is positioned after the closing ?>.

Thanks.

Actually this would be nice. I tend to turn off dynamic highlighting because of the issue when opening up HTML only or PHP only files.

I'm afraid of big performance penalty.
Say, you have a file like nusoap.php and cursor is placed on such space between the blocks. Highlighter would need to scan up to the last block end to make sure that there are only spaces between php and must do it each time you move cursor.

Isn't there any state information that could be used to help out, rather than doing a full scan each time? Tidbits like a flag set that indicates which languages are in a file, the offsets of each language block, a block delimiter stack, and the offset of the insertion point would all be helpful in determining how to do the highlighting. In other words, assuming that the editor isn't doing a full parse with every character typed, but is instead doing a full parse on file open then just updating states after that, I don't see why this would entail a noticeable performance penalty. How is this so different than, say, checking to see if the insertion point has moved next to a brace and then balancing it, or adjusting highlighting when you type "?>"?

Of course, I know nothing about how the IDE is implemented internally, but looking at the black box with an Expert Black Box Eye, this seems to be pretty easy.

well, say you have list of blocks with start-end points, stack of delimiters with their positions and so forth.
Now say you entered just one space in the file beginning. Could you imagine how many things should be updated or even re-parsed in this case?

But what are you doing now? You have to either be maintaining state information and updating it as the user makes changes, or you're rescanning the whole document and doing everything from scratch with every keystroke. I would assume you're maintaining quite a bit of state information, since modern editors keep track of quite a lot that's happening - and programming editors even more - and doing it all from scratch every time would be painful.