2010/8/5 Meikel Brandmeyer <m...@kotka.de> > 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? >
This is exactly the scenario, yes. > 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)))) > Yes, np, I took a careful look at your code, and it indeed seems to work. My point was that by providing different interfaces/protocols to different "users", it's more an implementation detail than anything else if they have the same object or not. I don't expect my users to program on types, but on protocols/interfaces. (ok, in this case, i'm my own user, so I have indeed some expectations on me ;) ) > 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. > Yes. Maybe I was generalizing too much the situation. Maybe not :) > > 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. :] > > Hm, well .. let's say not worse than me :) -- 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
