Hi,
On Aug 5, 2:47 pm, Laurent PETIT <laurent.pe...@gmail.com> wrote:
> Yes, maybe I'm putting too much ... will need to think about it again
I don't want to talk you into something. I just have a different view.
> But I don't understand your usage of the expression "side-effect".
Ok. Why do I think that the future stuff is a "side-effect".
The main concern is to parse the code for augmented user experience
while editing (error markers, etc.). So, when a character is typed the
we parse the code and update eg. an atom. Convenience functions can
now easily access the parsed code. This is step 1.
However parsing things after every entered key does a lot of
unnecessary work. Hence we delay the parsing until it is really
required. This makes general editing faster, but the convenience
functions might become slower due to the parsing which has now to be
done. This is step 2.
Now as a complete nice-to-have convenience thing, we decide to pre-
parse the code in a calm second when the user pauses from typing. Then
the parsing would be done by the time a convenience functionality is
called and the editor doesn't feel sluggish because of too much
(unnecessary) work. On the other hand the pre-parser has to be stopped
if the user continues typing. It is completely independent from the
consumer of the parsed code. (It's just in so far dependent, that it
should parse the code again, when this was already triggered by a
consumer. But this we get for free with the delay). This is step 3.
This is the scenario as I understand it. How would I implement step 3?
I start with the cursor-hold-hook, which is triggered when the user
stops typing. There the future with the sleep gets fired off and
stored in a suitable place.
(def *parsed-code* (atom nil))
(def *pre-parser* (atom nil))
(defn cursor-hold-hook
[]
(reset! *pre-parser*
(future
(Thread/sleep pre-parse-delay)
(reset! *pre-parser* nil)
(force @*parsed-code*))))
Then three things might happen during the sleep:
- Nothing.
- The user enters more text.
- A convenience functionality is invoked.
In the first case, the future does its thing. The code gets pre-
parsed. Everything is fine. In the second case, the force will become
a no-op. So we can just as well leave the future alone. In the third
case, we might want to save the parsing because the user typed more
text. So we modify the char-entered-hook.
(defn char-entered-hook
[]
(when @*pre-parser
(swap! *pre-parser* #(do (when % (future-cancel %)) nil)))
(reset! *parsed-code* (delay (parse-code))))
The real situation in the eclipse editor might be different. So this
might not be applicable. Or it might be a bad idea in the first place.
Anyway: that's how I would do it. It is a pretty straight-forward
translation of how I understand the situation.
> After all I was wrong, it's not a delayed delay I've written.
> How to rename things ?
>
> timed-delay -> ?
> delay.util.Cancellable -> ?
> isCancelled -> ?
> cancel -> ?
timed-delay -> ok
Cancellable -> Timed
isCancelled -> countdown-stopped?
cancel -> stop-countdown
Maybe like this? I dunno. I'm bad at names. :]
Sincerely
Meikel
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
