Re: Script @prelude
On Fri, Feb 4, 2011 at 4:09 PM, Ville M. Vainio vivai...@gmail.com wrote: Interesting rule of thumb. Otoh, exec(g.findTestScript,...) exists by default. Indeed. I wonder if we could accomplish the same with less objectionable syntax... I tried to simplify this further, but how to do that? The exec statement is executed for its effects in the *present* namespace. Thus, it won't do to put the exec in a function/method, unless it is possible to transfer the effects of the exec into the *callers* namespace. I do not know any way to do that, even if (as I attempted to do) the wrapper method compares the before and after snapshots of the local namespace. Clear? In short, I think using a top-level exec is in fact the simplest and clearest way. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Script @prelude
On Sun, 13 Feb 2011 10:03:16 -0600 Edward K. Ream edream...@gmail.com wrote: I tried to simplify this further, but how to do that? The exec statement is executed for its effects in the *present* namespace. Thus, it won't do to put the exec in a function/method, unless it is possible to transfer the effects of the exec into the *callers* namespace. I do not know any way to do that, even if (as I attempted to do) the wrapper method compares the before and after snapshots of the local namespace. Clear? In short, I think using a top-level exec is in fact the simplest and clearest way. I just started using that pattern, mostly because this discussion reminded me of it, it's very handy. I think Ville's suggestion was just aesthetic, although it has the advantage of not needing to remember the exec() call at the start of each node which needs it (they'd all be descendants / later siblings of the @prelude). Implementation wise, I think @prelude would avoid exec() and just prepend the @prelude nodes' text to the script that's assembled for execution in the same part of the process which handles @others etc. Cheers -Terry -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Script @prelude
On Thu, Feb 3, 2011 at 4:41 PM, Ville M. Vainio vivai...@gmail.com wrote: - What if you scanned up the tree when pressing ctrl+b, and if one ancestor had @prelude in it, it would be evaluated as part of the script, before the code in current node? Possible. But this could be called a special case of:: exec(g.findTestScript(c,'@common my common code')) I like the exec way better. Of course, you are free to implement @prelude in many ways if you prefer. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Script @prelude
On Fri, Feb 4, 2011 at 4:54 PM, Edward K. Ream edream...@gmail.com wrote: - What if you scanned up the tree when pressing ctrl+b, and if one ancestor had @prelude in it, it would be evaluated as part of the script, before the code in current node? Possible. But this could be called a special case of:: exec(g.findTestScript(c,'@common my common code')) I like the exec way better. Of course, you are free to implement @prelude in many ways if you prefer. The implementation is not a problem. I can also add my own button / command, but I'm thinking of having this as standard feature. Leo is infinitely scriptable, so there is no doubt there are many ways to do this :). I'm thinking that perhaps we should have execute-script-rich (or something equivalent) that would provide a more advanced execution, and have that bound by default to some key. (Yes, this is the old argument about good defaults vs. customizeability. In my books, if a feature is not available by default or just by enabling a plugin, it doesn't exist) -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Script @prelude
On Fri, Feb 4, 2011 at 9:06 AM, Ville M. Vainio vivai...@gmail.com wrote: In my books, if a feature is not available by default or just by enabling a plugin, it doesn't exist) Interesting rule of thumb. Otoh, exec(g.findTestScript,...) exists by default. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
Re: Script @prelude
On Fri, Feb 4, 2011 at 6:04 PM, Edward K. Ream edream...@gmail.com wrote: In my books, if a feature is not available by default or just by enabling a plugin, it doesn't exist) Interesting rule of thumb. Otoh, exec(g.findTestScript,...) exists by default. Indeed. I wonder if we could accomplish the same with less objectionable syntax... -- Ville M. Vainio @@ Forum Nokia -- You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group, send email to leo-editor@googlegroups.com. To unsubscribe from this group, send email to leo-editor+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
