incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Wrobel <darkfl...@gmail.com>
Subject Re: Questions about implementing 'linky' WAVE-275
Date Wed, 01 Feb 2012 13:08:02 GMT
Ah, this comes down to my ignorance of how the wave client works
currently - but it sounds like "EditorUpdateEvent"
is the core problem here.
Can it not be modified to also return what key was last pressed?
Or maybe the link checking can go within this event and the event
itself modified?
(links could then be flagged with annotations upon entry, indeed by
first looking for :\\)

Picking up key presses in gwt is pretty trivial, so this seems more a
client structure issue then anything else.

~~~~~~
Reviews of anything, by anyone;
www.rateoholic.co.uk
Please try out my new site and give feedback :)



On 1 February 2012 01:16, Daniel Danilatos <daniel.danilatos@gmail.com> wrote:
> An idea to solve the speed problem:
>
> There is no "API" for this currently, but it would be fairly straight
> forward to listen to the operation stream coming out of the document, which
> would give you precise, fine-grained knowledge of where changes are
> occurring and what they are. The only issue here is that synchronously
> modifying the operation when there are more operations coming would
> interfere with other code executing and cause crashes; but there is also a
> simple solution, and that is to use *local* annotations[1] to mark the
> regions that have changed. This would probably be a generally useful
> facility, and not just for linking. Then in a batch, asynchronous,
> incremental fashion, you could consume the change markers and do little
> scans around that area for links. To guarantee UI responsiveness (say if a
> big chunk of text is pasted in), only consume a small portion of the change
> annotation(s) at a time, e.g. until say 100ms have elapsed, then defer and
> continue[2].
>
> Alternatively, I was also going to suggest as a very simple,
> works-in-98%-of-cases idea, is just look at where the cursor is in the
> editor update event and search the text in that vicinity only. Use
> DocHelper.getText() and pass it say 200 characters backward and 50 forward
> from the current location (you certainly don't need to stitch the nodes
> together yourself). It seems you've mentioned this idea, did it not work
> well in practice? I would hope it should work for most cases, just fail if
> someone pastes in a really big chunk of text.
>
> Dan
>
> [1] Annotations that apply only to the local document and don't result in
> operations to the server. Because they don't need to be serialized into
> operations, they can take any object as their value, not just Strings, so
> are very useful for all kinds of local metadata. This is how diff
> highlighting is done, e.g. a deleted region is a small annotation at a
> location with the value being the html dom of the deleted content to
> display.
> [2] This strategy is somewhat similar to how the rendering of normal style
> annotations is done, with the help of local annotations to mark regions
> that need "painting": any time a region gets annotated with a style
> annotation, it is marked as "dirty" with a local annotation. These local
> annotations are then consumed asynchronously in an incremental fashion, as
> their regions get re-styled.
>
> On Feb 1, 2012 10:13 AM, "Ali Lown" <ali@lown.me.uk> wrote:
>
>> > Id steer well clear of client side Regexs for something "continuously
>> > checked" like this.
>> I did precisely because I knew it would only end badly.
>>
>> > Why not just remember the last few letters typed?
>> If only that sort of information was available.
>> The API for this sort of thing is the EditorUpdateEvent, which can
>> tell you that a) a change happened and b) the location in the document
>> it happened at.
>> This then requires a loop over the document to stitch together the
>> text up to that point, before it can even be considered for checking.
>>
>> Since the EditorUpdateEvent is rate-limited it is possible for quite
>> large deltas to be applied between calls resulting in large quantities
>> of text needing to be checked.
>>
>> > If its "http:"  then
>> This is fine until we want to check for more than just http. E.g.
>> https or mailto or (any other scheme...). At which stage, we need to
>> (in the worst case) sample the number of letters in the longest
>> scheme. And then a loop over the list of known schemes for each bit we
>> need to check, so it ends up testing things like ('h', 'ht', 'htt',
>> 'http'). Also, we need to ensure we get 'https' without treating it as
>> 'http'. By instead working backwards along the text from the detection
>> of the URI separator ('://') instead.
>>
>> To work backwards, we need to maintain a copy of enough text in the
>> document prior to the separator to ensure we always detect correctly
>> (even across node boundaries, but managing to ignore/reset state on
>> new lines).
>>
>> > set a boolean "probablylink" too true. Then the next time space is
>> > pressed, check inbetween those letters too see if it looks like a
>> > link.
>> Since we are using EditorUpdateEvent, checking for a space will
>> require a loop to re-retrieve the document text up-to the latest
>> change, then looking through all the text upto the new location but
>> beyond the location we set 'probablylink' at, and looking for a space
>> (another loop needed then).
>>
>> > That should go at a decent speed during entry surely?
>> Oh, and this needs to be able to be done within a few milliseconds
>> otherwise the user will get annoyed with the lag.
>>
>> By this stage, the number of loops we need to do every time we receive
>> an EditorUpdateEvent is such that it becomes noticeable after we have
>> a few different links all within a few hundred characters.
>>
>> NB: The algorithm you described is pretty much what I had coded it to
>> try doing. So if you want pull down my code from that review request
>> and feel free to try to improve its efficiency.
>>
>> Network latencies could easily be ~1s, so yes the link would be
>> annotated a bit slower, but the user would be able to continue to type
>> the blip at normal speed, rather than being slowed down by the browser
>> unable to run the JS checks quick enough each time a keypress occurs
>> causing EditorUpdateEvent to fire (since the lag time due to the
>> browser slow-down is now great enough to result in an event being
>> fired every keypress).
>>

Mime
View raw message