std.d.lexer requirements

[Dmitry Olshansky]

On 03-Aug-12 02:10, Walter Bright wrote:
> On 8/2/2012 1:41 PM, Jacob Carlborg wrote:
>> On 2012-08-02 21:35, Walter Bright wrote:
>>
>>> A good IDE should do its parsing in a separate thread, so the main user
>>> input thread remains crisp and responsive.
>>>
>>> If the user edits the text while the parsing is in progress, the
>>> background parsing thread simply abandons the current parse and starts
>>> over.
>>
>> It still needs to update the editor view with the correct syntax
>> highlighting
>> which needs to be done in the same thread as the rest of the GUI.
>>
>
> The rendering code should be in yet a third thread.
>
OT:
It never ceases to amaze me how people miss this very simple point:
GUI runs on its own thread and shouldn't ever block on something (save 
for message pump itself, of course). Everything else (including possibly 
slow rendering) done on the side and then result (once ready) swiftly 
indicated on GUI.

Recent Windows 8 talks were in fact nothing new in this regard, but now 
even API is made so that it's harder to do something blocking in GUI thread.


> An editor I wrote years ago had the rendering code in a separate thread
> from user input. You never had to wait to type in commands, the
> rendering would catch up when it could. What was also effective was the
> rendering would abandon a render midstream and restart it if it detected
> that the underlying data had changed in the meantime. This meant that
> the display was never more than one render out of date.
>
> Although the code itself wasn't any faster, it certainly *felt* faster
> with this approach. It made for crisp editing even on a pig slow machine.
>


-- 
Dmitry Olshansky