scriptFile.py warning
I disabled the following setting in leoSettings.leo: @@string script_file_path = ../test/scriptFile.py I also change the default script file to ~/.leo/scriptFile.py. This was required to make the ctrl+b work with the debian package. It's a bad idea to write relative to leo load dir, because it's a read only directory if leo is installed (debian package, setup.py) as opposed to just being run locally. I guess this is one of the @settings that should probably be removed altogether; if a user wants to break his leo installation, he should at least be required to edit the source code to do that ;-) -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: scriptFile.py warning
On Wed, Jun 24, 2009 at 3:10 AM, Ville M. Vainio vivai...@gmail.com wrote: I disabled the following setting in leoSettings.leo: @@string script_file_path = ../test/scriptFile.py I also changed the default script file to ~/.leo/scriptFile.py. This was required to make the ctrl+b work with the debian package. It's a bad idea to write relative to leo load dir, because it's a read only directory if leo is installed (debian package, setup.py) as opposed to just being run locally. True. I guess this is one of the @settings that should probably be removed altogether; if a user wants to break his leo installation, he should at least be required to edit the source code to do that ;-) No. One should only need to change the default of the setting. There is nothing improper about letting users choose where to write files. The explanation of the setting (in the body text of the @string node) can discuss the pros and cons. Please restore the setting. It's fine to change the default location to the .leo directory. 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: scriptFile.py warning
On Wed, Jun 24, 2009 at 4:08 PM, Edward K. Reamedream...@gmail.com wrote: I disabled the following setting in leoSettings.leo: @@string script_file_path = ../test/scriptFile.py Please restore the setting. It's fine to change the default location to the .leo directory. The setting is still there, I just prepended the @ to disable it. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: @shadow and what should I put under version control
On Mon, Jun 22, 2009 at 7:32 PM, Lucas Thode ljth...@gmail.com wrote: What do you do about nodes and structure that is shared among multiple @thin trees in that scenario? Also, what about things that should be kept with the code, but are not part of the code itself? (Leo's clones provide a nice facility for associating code and high-level documentation such as business requirements.) I have often said that at most one @thin tree should be responsible for each clone. For example, in leoPy.leo, the actual source files own (not an official term) each node, while almost all clones end up in @thin leoProjects.txt. This file uses @all to allow clones to be included without regard to whether, for example, section definition nodes are actually referenced. I think of this as not so much a technical issue, but a management issue. Just as two human managers are unlikely to agree to shared responsibility for a piece of code, so too it is likely to be unwise to have two source files share cloned nodes. I consider it bad (management) style. YMMV. 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: scriptFile.py warning
On Wed, Jun 24, 2009 at 8:10 AM, Ville M. Vainio vivai...@gmail.com wrote: On Wed, Jun 24, 2009 at 4:08 PM, Edward K. Reamedream...@gmail.com wrote: I disabled the following setting in leoSettings.leo: @@string script_file_path = ../test/scriptFile.py Please restore the setting. It's fine to change the default location to the .leo directory. The setting is still there, I just prepended the @ to disable it. Am I correct in assuming the code still supports the setting? 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: scriptFile.py warning
On Wed, Jun 24, 2009 at 4:14 PM, Edward K. Reamedream...@gmail.com wrote: The setting is still there, I just prepended the @ to disable it. Am I correct in assuming the code still supports the setting? Yes you are. I only changed the path used when the setting is not available. -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: Leo 4.6 beta 2 released
On Tue, Jun 23, 2009 at 7:55 PM, Graham Chiu compkar...@gmail.com wrote: Except that now I am getting structure comments appearing in my tangled code even with the @silent directive before my @root directive eg: I now see amongst my tangled code # Rebol Header (1 of 3) I didn't see this with 4.5.1 final which is what I have been using. Hmm. I don't recall changing anything significant in the tangle code for a long time, and I have essentially no memory of the details of the code. There doesn't seem to be a relevant setting in leoSettings.leo. So let's look at the code in leoTangle.py Tangle pass 2 does the output. put_section looks like the place where the comment will be written. Yes, I see a section called put the section name in a comment . It is called like this: if self.print_mode != silent: Put the section name in a comment Lets look again at where print_mode is set. Now we are getting somewhere. It is inited to verbose in an init section. Let's look further. By happy chance, I see print_mode_changed in tangle.scanAllDirectives. This is the answer: I rewrote scanAllDirectives, and the init of print_mode got deleted. I'll fix this for the next release. I'll probably have to dig back through the archives to discover how users set it. Or maybe read the docs :-) 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: scriptFile.py warning
On Wed, Jun 24, 2009 at 8:16 AM, Ville M. Vainio vivai...@gmail.com wrote: Am I correct in assuming the code still supports the setting? Yes you are. I only changed the path used when the setting is not available. I just merged your code. I approve of what you have done, namely making home/.leo the default place for writing this file. I'll recommit after adding a comment to the disabled setting node explaining the situation. 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: Leo 4.6 beta 2 released
On Wed, Jun 24, 2009 at 3:55 AM, Graham Chiucompkar...@gmail.com wrote: Except that now I am getting structure comments appearing in my tangled code even with the @silent directive before my @root directive Out of curiosity - why are you using @root tangling instead of @nosent? -- Ville M. Vainio http://tinyurl.com/vainio --~--~-~--~~~---~--~~ 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: scriptFile.py warning
On Wed, Jun 24, 2009 at 8:43 AM, Edward K. Ream edream...@gmail.com wrote: Am I correct in assuming the code still supports the setting? Yes you are. I only changed the path used when the setting is not available. I just merged your code. I approve of what you have done, namely making home/.leo the default place for writing this file. I'll recommit after adding a comment to the disabled setting node explaining the situation. Done at the trunk at rev 2087. 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: Leo 4.6 beta 2 released
On Wed, Jun 24, 2009 at 8:43 AM, Ville M. Vainio vivai...@gmail.com wrote: Out of curiosity - why are you using @root tangling instead of @nosent? @root combined with @unit is significantly more flexible than @thin. Anyway, please don't talk Graham out of using @root until all bugs are fixed :-) 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: @shadow and what should I put under version control
On Tue, Jun 23, 2009 at 10:55 PM, thyrsus sschae...@acm.org wrote: I do a good bit of clones getting expanded into multiple locations, and it works well for me. Important things to remember: * If you're using @thin, it means the .leo file is thin, and the derived file is fat. Okiedokie, I'll move the doc-bits in question out of the .leo file into derived files. :) * If you've got nodes cloned into multiple @thin or @file locations, and their contents gets changed outside of Leo, then the last version encountered during the reading of the derived files wins. Not a huge deal, the clone nodes are shared boilerplate and won't get touched for much of anything. * If the sentinels are damaged outside of Leo, Leo can sometimes get confused -- more often with @file than with @thin. I'm just going to make Leo a requirement for editing the code. ;) * Unless your versioning system is extremely short of disk space, tell your versioning system that the .leo file is a binary. Trying to do reconciliations between XML files is close to impossible except in the very most trivial cases. I've only done it successfully twice; you're almost always better off abandoning your changes, checking out from a known coherent version, and redoing the work from there. Good idea. Good luck, - Stephen quote snipped --~--~-~--~~~---~--~~ 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: @shadow and what should I put under version control
On Wed, Jun 24, 2009 at 8:13 AM, Edward K. Ream edream...@gmail.com wrote: On Mon, Jun 22, 2009 at 7:32 PM, Lucas Thode ljth...@gmail.com wrote: What do you do about nodes and structure that is shared among multiple @thin trees in that scenario? Also, what about things that should be kept with the code, but are not part of the code itself? (Leo's clones provide a nice facility for associating code and high-level documentation such as business requirements.) I have often said that at most one @thin tree should be responsible for each clone. For example, in leoPy.leo, the actual source files own (not an official term) each node, while almost all clones end up in @thin leoProjects.txt. This file uses @all to allow clones to be included without regard to whether, for example, section definition nodes are actually referenced. I think of this as not so much a technical issue, but a management issue. Just as two human managers are unlikely to agree to shared responsibility for a piece of code, so too it is likely to be unwise to have two source files share cloned nodes. I consider it bad (management) style. YMMV. Edward These shared clone nodes are just boilerplate, really. So, it's not a big deal in this case; for actual code, I agree with you. --Lucas --~--~-~--~~~---~--~~ 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: scriptFile.py warning
On Wed, 24 Jun 2009 08:43:05 -0500 Edward K. Ream edream...@gmail.com wrote: I just merged your code. I approve of what you have done, namely making home/.leo the default place for writing this file. I'll recommit after adding a comment to the disabled setting node explaining the situation. I noticed spell check writing to a file in the leo install dir (plugins) yesterday also. When you add a word - not sure if it's added elsewhere as well. 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: Puzzle re the line-oriented qt colorizer
The puzzle I spent all yesterday trying to get colorizing for Python and C to work. Several minor bugs were confusing matters, but as I stamped out the simple bugs it began to dawn on me that there is a tricky puzzle involved in handling languages like C and PHP that use jEdit delegates. The more I think of the puzzle, the more interesting it becomes. Consider this (strange!) C code (contained at present in test.leo):: @language c #define WIPEOUT 0 /* * comment line 1. * comment line 2 */ #include eeprom.h What's so strange about this, you ask? Well, C preprocessor directives stop at the end of the line, but wait, the C comment starts in the preprocessor line and continues three more lines! The jEdit pattern matcher handles this by colorizing the line:: #define WIPEOUT 0 /* with a so-called delegate. That is, the top-level pattern matcher discovers the line above, and then calls the c::cpp delegate to colorize it. Typically, the delegate just colorizes everything blue (regardless of whether it looks like a C construct. However the c::cpp delegate extends the preprocessor line in order to colorize complete comments in red. This colorizing is important, as it indicates that comments are indeed comments, even if they start in a preprocessor line! Already, I think you can start to see problems in a line-oriented environment. But before you jump to conclusions about possible solutions to this puzzle, consider this example:: #define /* a comment */ WIPEOUT 0 Thought experiments and other mental tools Trust me, this is a worthy puzzle. I'm not going to go into all the (foolish) ideas I tried yesterday. Suffice it to say, no trivial solutions have any chance. It might be, however, that some clever change in point of view will allow some small (but probably tricky) code to handle all the cases. As a thought experiment, we could consider rewriting (all) the jEdit language description files so that they don't use delegates. We don't want to do that, but notice that if we did rewrite the rules **and left the meaning of the jEdit patterns unchanged**, we could, in fact, use all the *old* jEdit pattern matches (including in threading_colorizer.py) unchanged. OTOH, it's not at all clear how to get rid of delegates even if we were free to do so! Let me try to explain the essence of the problem. If Leo is to use the language descriptions in the leo/modes directory, the pattern matchers must conform to the assumptions embodied in those language descriptions. But those descriptions are stated in terms of general patterns, not line-oriented patterns. Without delegates, the restarter methods properly change the frame of reference from general strings to lines. But in the presence of delegates, it becomes much harder to encapsulate the state of what is, in effect, a call stack of pointers into strings that can cross line boundaries. As stated above, we are free, as a thought experiment, to consider rewriting the language description files. The obvious idea is to recast all the colorizers in terms of line-oriented rules. If we could do that, we might be able to see the Aha that will enable the change of reference of the **unchanged** pattern matchers to a line-oriented code. But to repeat, it's not so clear how to do even this. Look again at the original example:: @language c #define WIPEOUT 0 /* * comment line 1. * comment line 2 */ #include eeprom.h The top-level pattern matcher discovers:: #define WIPEOUT 0 /* What on earth are we to do with this? I suppose we could invent a new kind of matcher that stops at /* or the end-of-line, whichever comes first. This hack would work for this *particular* example. The pattern matcher would color in blue everything up to the /*. The top-level pattern for comment-lines would then fire. This hack is unsatisfying because it doesn't provide any *general* insight about how to deal with delegates. Still, it proves that a solution is feasible, provided we extend threading_colorizer.py (and, if we care, the old qt colorizer code) to handle the new kind of pattern matcher. We have an existence proof that at least the c::cpp delegate can be eliminated. Or does it? Oh my. What state do we enter after handling the C comment? In the first example, we must enter the default C state. In the second example, we must re-enter the preprocessor state. The only difference is whether the C comment extends beyond the end of the line! Maybe now you can see how tricky this all is. That's all for now. I was hoping that writing this would spur some new ideas. It may happen, but not yet :-) Your comments and thoughts are always welcome. Edward --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups leo-editor group. To post to this group,
Re: Puzzle re the line-oriented qt colorizer
On Jun 24, 10:45 am, Edward K. Ream edream...@gmail.com wrote: That's all for now. I was hoping that writing this would spur some new ideas. It may happen, but not yet :-) My guess is that the solution will be some encoding of some kind of call stack into colorizer state. Details blurry. EKR --~--~-~--~~~---~--~~ 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: Puzzle re the line-oriented qt colorizer
On Jun 24, 10:48 am, Edward K. Ream edream...@gmail.com wrote: My guess is that the solution will be some encoding of some kind of call stack into colorizer state. Details blurry. You could call this an extension of the idea of lambda binding. We bind calling context, not just arguments. I love these kinds of puzzles. Fun and useful. EKR --~--~-~--~~~---~--~~ 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: Puzzle re the line-oriented qt colorizer
On Jun 24, 10:50 am, Edward K. Ream edream...@gmail.com wrote: You could call this an extension of the idea of lambda binding. We bind calling context, not just arguments. I love these kinds of puzzles. Fun and useful. But this is not going to be trivial, even if the code finally is small. It's not at all clear how to simulate jEdit processing on a text that crosses lines in a context in which only one line of text is ever available. In other words, we don't have a complete call to encapsulate. It may be that some more experimentation will be needed to understand the essence of what is happening. One more thing. There are some simple-yet-horrid hacks in the present code. Look for ### in the new code. Removing these hacks will cause the main example to fail. EKR --~--~-~--~~~---~--~~ 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: Puzzle re the line-oriented qt colorizer
On Jun 24, 10:48 am, Edward K. Ream edream...@gmail.com wrote: That's all for now. I was hoping that writing this would spur some new ideas. It may happen, but not yet :-) My guess is that the solution will be some encoding of some kind of call stack into colorizer state. Details blurry. The PHP colorizer and its delegates is likely to be an even better test of any new ideas. 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: Puzzle re the line-oriented qt colorizer
On Wed, Jun 24, 2009 at 10:45 AM, Edward K. Ream edream...@gmail.comwrote: That's all for now. I was hoping that writing this would spur some new ideas. It may happen, but not yet :-) I'm beginning to get the sense that supporting delegates directly might not be too hard. It's related to the mental trick that created the Aha of using restarters: namely, just pretend that a simple, straightforward solution exists, and then look for it :-) In this case, we can tell whether a delegate extends past the present line by having it return len(s) + 1 when it has started matching a cross-line pattern. In that case, we remain in the *delegated* stated. Otherwise, we continue in the *delegator* (caller) state. For example, the difference between: #define WIPEOUT 0 /* * comment line 1. and #define /* comment */ WIPEOUT 0 is that the delegate returns len(s) + 1 in the first case and n len(s) in the second. It might work. Another way of thinking of this is that no matter what is happening, we are really only colorizing the current line. It should be simply a matter of keeping track of what colorizing state we are in, and passing that state to qt at the end of the line :-) 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: Leo 4.6 beta 2 released
On Tue, Jun 23, 2009 at 7:55 PM, Graham Chiu compkar...@gmail.com wrote: Except that now I am getting structure comments appearing in my tangled code even with the @silent directive before my @root directive eg: I now see amongst my tangled code # Rebol Header (1 of 3) I didn't see this with 4.5.1 final which is what I have been using. Fixed on the trunk at rev 2089. All unit tests pass, including three new or improved unit tests. In fact there was a unit test of c.tangleCommands.scanAllDirectives, but naturally it did not think to test the print_mode ivar. 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: What to do about the windows installer?
Edward K. Ream wrote: Problems with the windows installer persist. The 'make' button in dist.leo creates the installer's exe with a pretty gross hack: appending the .zip file to an already-existing .exe file. I don't know whether this hack contributes to the problems users are having. The hack uses the Python 2.5 version of the original .exe file, and the make button ensures that dist.leo was opened using Python 2.5. I do know that these installer problems are tiresome, and they often create more trouble for users than the installer is worth. I also know that I'm not qualified to fix installer problems. Anyone have any idea what to do about this mess? Python went with msi - which is what I would do. Indeed, I was so disgusted by the leo installer for windows that I intended to do this, but somehow have not got around to doing it partly because to make a solution compatible with leo's license, I would have to learn msilib.py - which I need to do anyway, but have not yet done. --~--~-~--~~~---~--~~ 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: @shadow and what should I put under version control
thyrsus wrote: * If you've got nodes cloned into multiple @thin or @file locations, and their contents gets changed outside of Leo, then the last version encountered during the reading of the derived files wins. This is a bug, in that it is guaranteed to surprise: What happened to my changes, cries the user, having long forgotten that the node was cloned into some obscure place for some reason no longer very relevant, perhaps to document a bug long ago fixed and forgotten. The version whose file has the most recent change date should win. --~--~-~--~~~---~--~~ 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: @shadow and what should I put under version control
Edward K. Ream wrote: I have often said that at most one @thin tree should be responsible for each clone. doubtless, but there is nothing to mark or record a clone as which @thin tree is the right one for editing it, should one edit it outside of leo, or, as is quite likely, someone else edit it outside of leo. --~--~-~--~~~---~--~~ 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: What to do about the windows installer?
On Wed, Jun 24, 2009 at 4:45 PM, James A. Donald jam...@echeque.com wrote: Indeed, I was so disgusted by the leo installer for windows that I intended to do this, but somehow have not got around to doing it partly because to make a solution compatible with leo's license, I would have to learn msilib.py - which I need to do anyway, but have not yet done. Hope you can do something for Leo soon. It would be a big help. 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: Leo 4.6 beta 2 released
Thanks .. works now. On Thu, Jun 25, 2009 at 6:31 AM, Edward K. Reamedream...@gmail.com wrote: On Tue, Jun 23, 2009 at 7:55 PM, Graham Chiu compkar...@gmail.com wrote: Except that now I am getting structure comments appearing in my tangled code even with the @silent directive before my @root directive eg: I now see amongst my tangled code # Rebol Header (1 of 3) I didn't see this with 4.5.1 final which is what I have been using. Fixed on the trunk at rev 2089. All unit tests pass, including three new or improved unit tests. In fact there was a unit test of c.tangleCommands.scanAllDirectives, but naturally it did not think to test the print_mode ivar. -- Graham Chiu --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
