Scripts vs. macros
I was just wondering: Are scripts (for scripting Leo) macros? Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
On 11/25/2013 5:41 AM, Reinhard Engel wrote: I was just wondering: Are scripts (for scripting Leo) macros? Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? I have two comments on this: 1) There's a Leo plugin (macros.py) which uses the term 'macro' for templated node headings: http://leo-editor.readthedocs.org/en/latest/leo.plugins.html#module-leo.plugins.macros (Though, with Edward's recent tree-abbreviation work, I don't think it's needed!) 2) I find a fundamental difference between Leo scripting and macros in general being that Leo scripts are fully privileged python programs -- meaning they can generally do more, with less fuss, than most macro languages. Though, that said, their most common use case *is* interacting with the Leo API, so often they perform the same actions that macros would. If anything, Leo scripts cover a superset of functionality that traditional macro languages would cover. Just my $0.02. --Jake -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: How much of Tk is still in Leo 4.11?
On Sat, Nov 23, 2013 at 8:10 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: May be the documentation could be simplified by removing references to Tk. Thanks for the suggestion. It's on the list. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. That enough? EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Caution: Rev 6368 contains big changes to find code. Please test.
On Sun, Nov 24, 2013 at 3:15 PM, Edward K. Ream edream...@gmail.com wrote: On Sun, Nov 24, 2013 at 1:33 PM, Brian Theado brian.the...@gmail.comwrote: Is suboutline find working for you? Here's what isn't for me: Don't know. I'll check this out when I am able. There were several bugs. Rev 6370 (for the first time ever) uses a simple scheme to move from node to node and from pane to pane. I'll say more about this when I have time (I'm way busy just now). A little more work is coming, but the new code should handle everything perfectly except wrapped searches. Please report any problem (including old ones) immediately. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: computeLeadingWhitespaceWidth in leoGlobals.py
On Sun, Nov 24, 2013 at 7:53 PM, Terry Brown terry_n_br...@yahoo.comwrote: [Original post] QQQ Some other function: The second one is short and faster than the first. def computeLeadingWhitespaceWidth (s,tab_width): w = 0 for ch in s: if ch == ' ': w += 1 elif ch == '\t': w += (abs(tab_width) - (w % abs(tab_width))) else: break return w def computeLeadingWhitespaceWidth2(s, tab_width): t = s.expandtabs(abs(tab_width)) return len(t) - len(t.lstrip()) I don't know - are such micro-optimizations welcome or just a distraction? Q On Sun, 24 Nov 2013 10:09:53 -0800 (PST) wgw wgwin...@gmail.com wrote: The benefit of optimizations is always hard to measure, unless you, um, measure it. If you know there's a bottleneck that's slowing things down and can target that, that's probably going to help. Optimizing code that's called very infrequently or accounts for a tiny proportion of runtime may not have a noticeable effect. So then it becomes a questions of clarity and safety. In the tab expansion case I guess the simpler version would be clearer - I also guess it wasn't used because str.expandtabs because not everyone's aware of it, I wasn't. The safety thing is a question of what the code does. Changes in optional plugins are usually relatively safe. Changes in core code, particularly load/save have to be approached much more carefully. Where possible unit tests can make changes safer. Let me be a bit more blunt than Terry. The proposed change, though perhaps amusing, is not simply a distraction. It could be extremely bad, for at least the following reasons. 1. Although you claim that the two pieces of code are equivalent, you have not proven your claim. A unit test demonstrating that the two pieces of code are equivalent **for all relevant strings** would be essential. 2. The existing code, though perhaps verbose, expresses an intention. Even if the second piece of code were faster than the first, it doesn't express any intention at all. 3. You seem to have no idea whatever that this is fundamentally important code. If affects Leo's @file read code as well as Leo's import code. Therefore, any change whatever to this code, no matter how innocent it seems (and the new code is far from an innocent-appearing change) could damage existing external files. 4. As Terry says, there is no reason to change this particular piece of code. It is unlikely to be a bottleneck, and even if it were, you would have to show that the new version was faster than the old. In short, this change is, at best, irrelevant. At worst, it could introduce nasty, data-corrupting bugs. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Video links, alternate format...
On Fri, Nov 22, 2013 at 1:00 PM, Matt Wilkie map...@gmail.com wrote: Useful enhancement: post the script for each video as well (as in screen-play script, not computer code). Thanks for this. It's on the list. Scripts would also be helpful for the hearing impaired. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Video: How to install and use mod_http plugin
On Sat, Nov 23, 2013 at 2:47 PM, Fidel N fidelpe...@gmail.com wrote: Hey, this is my first screencast ever and I didnt buy camstasia like Edward hehe.. so just tell me if its clear enough or I should repeat it making more emphasis in any of the steps. Thanks for this. It's on the list to add a link to this from Leo's video page. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
Edward K. Ream wrote: On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard.engel...@googlemail.com mailto:reinhard.engel...@googlemail.com wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. I could be wrong, but I believe that emacs Lisp-based scripts can do all that as well. Miles Fidelman -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
On Monday, November 25, 2013 2:48:31 PM UTC+1, Edward K. Ream wrote: On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard...@googlemail.com javascript: wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. That enough? EKR Well, yes - that's enough. It nicely sums up how powerful scripts/macros in Leo are, because Leo uses Python itself for its macro language. But maybe it's just an (insubstantial) question of semantics. In your seven points, if one would replace 'scripts' by 'macros', the meaning wouldn't change (at leas not for me), and that's what I'm trying to understand. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
On 11/25/2013 9:21 AM, Reinhard Engel wrote: In your seven points, if one would replace 'scripts' by 'macros', the meaning wouldn't change (at leas not for me), and that's what I'm trying to understand. According to Wikipedia: http://en.wikipedia.org/wiki/Macro_(computer_science) A macro (short for macroinstruction, from Greek μακρο- 'long') in computer science is a rule or pattern that specifies how a certain input sequence (often a sequence of characters) should be mapped to a replacement input sequence (also often a sequence of characters) according to a defined procedure. Which to me looks an awful lot like Leo's abbreviations and key-binding code, rather than Leo scripts. But, Leo's keys can be bound to scripts, so... Basically, what I'm trying to say, is that there's little to be gained from conceptual ideas like Macros, Scripts, and Programs. These are all terms that everyone has different ideas of and personal definitions of. Such is our field... --Jake -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
On Mon, Nov 25, 2013 at 8:17 AM, Miles Fidelman mfidel...@meetinghouse.netwrote: Edward K. Ream wrote: On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard.engel...@googlemail.com mailto:reinhard.engel...@googlemail.com wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. I could be wrong, but I believe that emacs Lisp-based scripts can do all that as well. I was referring to VB macros and the like. Obviously, elisp can do more. 1. Emacs org mode provides clumsy access to outline data. 2. elisp has this. 3. org mode uses noweb, which does not have @others. 4. Presumably, this could be simulated in elisp, but it wouldn't be pretty. 5. Ditto. 6. elisp can do this. 7. ditto. Similar remarks apply to vim and vimoutline mode. Org mode is much clumsier to use than Leo. Scripts must be delimited by special markup. So yes, org mode can simulate anything that Leo can do, but these simulations are going to be clumsy, they will take a lot more work than the equivalent in Leo (which is why they haven't, in fact, been done) and the simulations are going to be a lot less convenient for users to use. The net effect: the pace of innovation in the Leo world far exceeds that of the vim/emacs worlds. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: computeLeadingWhitespaceWidth in leoGlobals.py
On Monday, November 25, 2013 3:04:13 PM UTC+1, Edward K. Ream wrote: On Sun, Nov 24, 2013 at 7:53 PM, Terry Brown terry_...@yahoo.comjavascript: wrote: QQQ Some other function: The second one is short and faster than the first. def computeLeadingWhitespaceWidth (s,tab_width): w = 0 for ch in s: if ch == ' ': w += 1 elif ch == '\t': w += (abs(tab_width) - (w % abs(tab_width))) else: break return w def computeLeadingWhitespaceWidth2(s, tab_width): t = s.expandtabs(abs(tab_width)) return len(t) - len(t.lstrip()) I don't know - are such micro-optimizations welcome or just a distraction? Q The proposed change, though perhaps amusing, is not simply a distraction. It could be extremely bad, for at least the following reasons. Well, I didn't propose a change, but just asked (with other words), if this is the place to discuss such topics. Your answer is clear enough. 1. Although you claim that the two pieces of code are equivalent, you have not proven your claim. A unit test demonstrating that the two pieces of code are equivalent **for all relevant strings** would be essential. Yes, you are right. I just used a Python function that expands tabs in strings and applied to the existing function. 2. The existing code, though perhaps verbose, expresses an intention. Even if the second piece of code were faster than the first, it doesn't express any intention at all. I don't understand what you mean by 'not expressing an intention'. For me, the name of the method expresses the intention well enough. 3. You seem to have no idea whatever that this is fundamentally important code. If affects Leo's @file read code as well as Leo's import code. Therefore, any change whatever to this code, no matter how innocent it seems (and the new code is far from an innocent-appearing change) could damage existing external files. That's just a (may I say 'unfair') conjecture. The fact that this code is in the very core shows that it must be important. What this function and its corresponding whitespace handling functions do, probably affects almost every aspect of an outline or of Python code. And as such they must be foolproof and fast. 4. As Terry says, there is no reason to change this particular piece of code. It is unlikely to be a bottleneck, and even if it were, you would have to show that the new version was faster than the old. Well, I did some timings. (If you care, I've attached the file. There even is an enhanced version of the current function, that moves the call to the abs function out of the loop.) The new code is about 40% faster than the old one. If there is a bottleneck, I can't tell; you're the expert. In short, this change is, at best, irrelevant. At worst, it could introduce nasty, data-corrupting bugs. I just try to learn something about the inner workings of Leo. And now I learned that is is not the place to discuss such code details. Thanks for being so blunt. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out. import time def timer(func, *args, **kwargs): repetitions = kwargs.get(repeat, 10) start = time.clock() result = None i = 0 while i repetitions: ret = func(*args) i += 1 elapsed = time.clock() - start print result, elapsed return (elapsed, result) def computeLeadingWhitespaceWidth (s,tab_width): Originial w = 0 for ch in s: if ch == ' ': w += 1 elif ch == '\t': w += (abs(tab_width) - (w % abs(tab_width))) else: break return w def computeLeadingWhitespaceWidth1(s,tab_width): Original enhanced w = 0 tw = abs(tab_width) for ch in s: if ch == ' ': w += 1 elif ch == '\t': w += (tw - (w % tw)) else: break return w def computeLeadingWhitespaceWidth2(s, tab_width): ALternative t = s.expandtabs(abs(tab_width)) return len(t) - len(t.lstrip()) def testWidth(): s = \t \t \t \t Leo\tis\ta\tbrilliant\tprogram. print s.expandtabs(4) timer(computeLeadingWhitespaceWidth, s, -4, repeat=100) timer(computeLeadingWhitespaceWidth1, s, -4, repeat=100) timer(computeLeadingWhitespaceWidth2, s, -4, repeat=100) if __name__ == __main__: testWidth()
Re: Make Commands more accessible
On Sun, Nov 24, 2013 at 4:21 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: The 'Help' menu has the 'Print Commands' command, that opens the separate 'Commands' tab; so far so good. But how do I get to the code corresponding to a command (without using the 'Find' tab)? This is what I do: Search for the name of the command in leoPy.leo. Example; start-search. You will find:: 'start-search': find.startSearch, # 4.11.1. Search for def startSearch. With a little experience, you will be able to guess the correspondence between a command's name and its function. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Renderpane to render directly from images in the web
On Sun, Nov 24, 2013 at 5:41 AM, Fidel N fidelpe...@gmail.com wrote: Hey: I dont know if I am talking about something trivial or not, so here is the idea just in case this is easy to implement and useful for someone else: What if a node with the following header were to render the image in the link in the render pane? @image https://i.chzbgr.com/maxW500/7913429760/hE8084AE2/ It should be doable with relatively little effort. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: mod_http updates
On Sun, Nov 24, 2013 at 7:06 PM, Terry Brown terry_n_br...@yahoo.comwrote: ALL please note - mod_http makes you loaded leo outlines browseable at 127.0.0.1:8130, that was it's original purpose. With Brian's change, it would be only 127.0.0.1, i.e you'd need to be logged in to the machine to see things, prior to that it would be open to anyone who can see port 8130 on your machine, typically your local network only. Thanks for the heads up: works for me. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Number of Leo Files - Best Practices?
On Fri, Nov 22, 2013 at 7:55 AM, Jacob Peck gatesph...@gmail.com wrote: Leo has session support, though I haven't the slightest where the docs are for this. It involves command-line options. Terry/Edward? First thing to do: Alt-X sessiontab Next: F11 (help-for-command) then sestabcrtab (session-create): no docstring available. Hahaha. My bad. It's on the list. Next: look for leoSessions.py Found! Look at SessionManager class. HTH. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Key binding for cloning
On Fri, Nov 22, 2013 at 9:52 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: The Ctrl-` key binding for creating a clone is unsuited for keyboards with a foreign keyboard layout; i.e. it doesn't work with a German keyboard layout. I rebound it to Ctrl-J. That's good. Is there a standard mapping that avoids special characters (`, +,~. !, ?, etc.) for key bindings? No. Just pick the bindings that work best for you. Put them in myLeoSettings.leo. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Date format
On Sun, Nov 24, 2013 at 4:08 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: May I suggest to use the international ISO date format (-MM-DD) as a default for dates. (I know, that I can change this in the my settings.) There are many settings involved with dates. All the datenode settings and: @string headline_time_format_string = %m/%d I would prefer not to change settings unless doing so is required or much more convenient. Changing settings always creates potential compatibility problems with people who use these settings without making them permanent in myLeoSettings.leo. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessibility of settings
On Sun, Nov 24, 2013 at 4:34 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: Why do I get the impression that you don't care for the accessibility i.e. of the settings? Accessibility? You can change font size if you want. The displayed values are the standard rendering of settings. As such, they are useful for debugging. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: FYI: Dead Qt stylesheet link
On Fri, Nov 22, 2013 at 2:30 PM, Reinhard Engel reinhard.engel...@googlemail.com wrote: In the documentation the following link is orphaned: /* Documentation of Qt stylesheets at http://doc.trolltech.com/4.2/stylesheet.html */ This one is valid: http://qt-project.org/doc/qt-4.8/stylesheet.html Good catch. The fix is on the trunk at rev 6371. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: leo.plugins.UNL
On Sat, Nov 23, 2013 at 3:45 PM, Reinhard Engel reinhard.engel...@googlemail.com wrote: The message error importing plugin: leo.plugins.UNL Traceback (most recent call last): File C:\Program Files (x86)\Leo-4.9-final\leo\core \leoPlugins.py, line 550, in loadOnePlugin toplevel = __import__(moduleName) ImportError: No module named UNL is still in source code. The message is there because it is sometimes helpful. This doesn't instill trust! Leo's plugin handler is doing exactly what it should be doing, namely catching the exception, reporting it, and moving on. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Per folder settings - where?
On Sat, Nov 23, 2013 at 9:23 AM, Chris George technat...@gmail.com wrote: Reading through the Customizing Leo document I think what is meant is that I can have a myLeoSettings.leo file in my ~/.leo directory for my overall personal settings, but I can also place a myLeoSettings.leo file in a directory where the file I am working on resides and have those settings take precedence. I think. It could be a lot clearer. I think that's right :-) I suspect few if any use per-folder settings. It's wise to heed the tutorial's remark that settings are really quite a bit too flexible. (There are reasons for some of the arcane flexibility, but new users should ignore them) Just stick to this scheme: - leoSettings.leo in its usual place: leo/config - myLeoSettings in ~ or ~/.leo - (optional) per-file settings in individual .leo files. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: An examplar of great docs for newcomers
On Fri, Nov 22, 2013 at 6:48 PM, Matt Wilkie map...@gmail.com wrote: Soft landings for newcomers has been a hot topic for a few weeks now, and resulted in some great new changes (yay! thanks Edward!). You're welcome. More are coming. I've been spending some time today on a site that I think could provide some inspiration and possible a framework for future Leo docs: https://www.mapbox.com/tilemill/docs/ Hmm. I don't want to install a package before the tutorial tells me what it does... EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: What is a section?
On Fri, Nov 22, 2013 at 6:59 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: In the tutorial 'Programming with Leo', I stumbled over *Essential Terms*: - A *section name* is any text of the form: any text . ( must not appear in “any text”.) - A *section definition node* is any node whose headline starts with a section name. - A *section reference* is a section name that appears in body text. No problem with these definitions. But these terms made me ask: 'But what is a *section* in the first place?' A section could mean any of the following, depending on context: a) the section node itself, b) the contents of the section node or c) the text resulting from the expansion of a section. In practice, these find distinctions don't matter: the section name acts like a macro call; the section node (and potentially its descendents, if the section node contains section references or @others) acts like the macro definition. All will likely become clear if you try using sections. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: viewrendered.py Question
On Fri, Nov 22, 2013 at 11:16 AM, Jacob Peck gatesph...@gmail.com wrote: On 11/22/2013 12:14 PM, Edward K. Ream wrote: vr displays reStructuredText automatically. That's how Leo's help commands work. But it does *not* expand section references, @others, etc., which is what the original message alludes to :) Oh, so *that's* what the original question was asking ;-) It's reasonable to want. In particular, it would solve some problems involving markup defined in a parent node and used in child nodes. vr doesn't see the parent markup when rendering the child. However, I have no plans for any such thing at present. Just a tad busy with other things. EKR -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: viewrendered.py Question
On Fri, Nov 22, 2013 at 6:24 PM, Chris George technat...@gmail.com wrote:
So it works. I open a new window for the vr pane and set it to float above
all other windows. The work flow then becomes:
1. Change content, move nodes around.
2. Move to appropriate place in the @rst tree and run rst3 command in the
mini-buffer.
3. Navigate to the @auto node and refresh from disk.
4. Run vr-update to see the new output in context.
Realtime would be better IMHO. But I am glad that I can do it at all.
You can get pretty much real time by doing this in a script.
Such scripts can be fantastically helpful.
For example, here is the contents of @button make-sphinx in LeoDocs.leo::
@language python
import os
trace = True
g.cls()
c.setComplexCommand('make-sphinx')
if c.isChanged():
c.save()
aList = c.rstCommands.rst3()
if aList:
path = g.os_path_finalize_join(g.app.loadDir,'..','doc','html')
os.chdir(path)
if len(aList) 1: g.execute_shell_commands('make clean',trace=trace)
g.execute_shell_commands('make html',trace=trace)
fn = aList[0].h.strip() if len(aList) == 1 else 'leo_toc.html'
fn =
g.os_path_finalize_join(path,'_build','html',g.os_path_basename(fn))
if g.os_path_exists(fn):
# Don't wait for this command to exit!
g.execute_shell_commands(['%s' % (fn)],trace=trace)
BTW, c.setComplexCommand('make-sphinx') allows me to type Ctrl-P
(repeat-complex-command) to execute this script again.
make-sphinx uses external processes. From your description, you may not
have to do that. In any case, 20 minutes spent writing such a script will
transform your workflow. It did for me.
HTH.
Edward
--
You received this message because you are subscribed to the Google Groups
leo-editor group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/groups/opt_out.
Re: FYI: Link on the Home Page
On Fri, Nov 22, 2013 at 6:42 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: The link 'Leo's Users Guide http://leoeditor.com/leo_toc.html' on Leo's Home Page points to the Documentation TOC, not to the User's Guide. The links should be called Leo's Documentation. I'll fix immediately. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
In my mind Script means something that is written like a program but depends on the host environment, while Macro is something that is generally recorded and later played back (and, if the software is capable, allows editing of said macro in between. A knowledgeable practitioner can dispense with the record phase and just write to begin with). From this standpoint I would say Leo has Scripts but not Macros. What is meaningful to me is does this code snippet require Leo present to work?: Yes -- Script No -- Program -matt On Mon, Nov 25, 2013 at 6:29 AM, Edward K. Ream edream...@gmail.com wrote: On Mon, Nov 25, 2013 at 8:17 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Edward K. Ream wrote: On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard.engel...@googlemail.com mailto:reinhard.engel.de@ googlemail.com wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. I could be wrong, but I believe that emacs Lisp-based scripts can do all that as well. I was referring to VB macros and the like. Obviously, elisp can do more. 1. Emacs org mode provides clumsy access to outline data. 2. elisp has this. 3. org mode uses noweb, which does not have @others. 4. Presumably, this could be simulated in elisp, but it wouldn't be pretty. 5. Ditto. 6. elisp can do this. 7. ditto. Similar remarks apply to vim and vimoutline mode. Org mode is much clumsier to use than Leo. Scripts must be delimited by special markup. So yes, org mode can simulate anything that Leo can do, but these simulations are going to be clumsy, they will take a lot more work than the equivalent in Leo (which is why they haven't, in fact, been done) and the simulations are going to be a lot less convenient for users to use. The net effect: the pace of innovation in the Leo world far exceeds that of the vim/emacs worlds. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: computeLeadingWhitespaceWidth in leoGlobals.py
If there is fault here, it's only that the proposed change didn't/doesn't justify its existence well enough, given the sensitive central position of @file in Leo's functioning. (Reinhard hasn't been around long enough to know that @file is surrounded on all sides by more here be dragons and you might be eaten by a grue than all other parts of Leo, combined.) To my admittedly neophyte eye, the expressed intention of the compute leading whitespace change is clear enough. The significant points are a) there is a significant performance gain (some data for that now provided), and b) that it is provably safe and equivalent to what it replaces (and/or deviations documented and deemed ok). A unit test demonstrating that the two pieces of code are equivalent **for all relevant strings** A corpus of all relevant strings to throw at this function would be useful at this juncture. I tried to find a link to insert here, but am unsure of the right target; perhaps LeoPyref.leo Code Testing? -matt On Mon, Nov 25, 2013 at 9:46 AM, Matt Wilkie map...@gmail.com wrote: On Mon, Nov 25, 2013 at 7:31 AM, Reinhard Engel reinhard.engel...@googlemail.com wrote: And now I learned that is is not the place to discuss such code details. I don't think that is the correct conclusion to draw from the conversation. This is most definitely the place to discuss code and debate the relative merits of proposed approaches and changes. -matt -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: computeLeadingWhitespaceWidth in leoGlobals.py
Thanks Terry for the clarifications: In terms of how to submit a patch for those two reviewed cases, or whatever, creating you own branch on launchpad and generating a merge request is probably the most convenient, for reviewers anyway. That looks like what I was trying to suggest with too little understanding. In other projects, I was told that things had to be submitted formally (like bugs on launchpad) because otherwise it added to the workload of core developers. In any case, for whatever is proposed, it is Edward and core developers who dispose at their convenience, especially for optimizations. (And now I see that everything should have unit tests.) I'm also assuming separate branches on bzr keeps everything safe. (Caveat: the only thing I know about bzr and launchpad is that if type bzr pull at the command line in the proper folder, I get a shiny new Leo!). On Monday, 25 November 2013 09:46:06 UTC-8, Matt Wilkie wrote: On Mon, Nov 25, 2013 at 7:31 AM, Reinhard Engel reinhard...@googlemail.com javascript: wrote: And now I learned that is is not the place to discuss such code details. I don't think that is the correct conclusion to draw from the conversation. This is most definitely the place to discuss code and debate the relative merits of proposed approaches and changes. -matt -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: computeLeadingWhitespaceWidth in leoGlobals.py
On Mon, 25 Nov 2013 10:03:57 -0800 Matt Wilkie map...@gmail.com wrote: To my admittedly neophyte eye, the expressed intention of the compute leading whitespace change is clear enough. Having just coincidentally and independently calculated indentation depth for two-space indented text as level = (len(line)-len(line.lstrip())) / 2 I would have to agree :) (my input was more controlled, so I could make the implied assumptions). The significant points are a) there is a significant performance gain (some data for that now provided), That needs to be measured in actual use though, not standalone. A 100x speed increase in a piece of code that's only responsible for 1% of the time the user spends waiting for 'X' to happen doesn't justify itself based on speed gained. Not sure how much user time expand-tabs consumes in load/save. Cheers -Terry and b) that it is provably safe and equivalent to what it replaces (and/or deviations documented and deemed ok). -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: An examplar of great docs for newcomers
On Mon, Nov 25, 2013 at 8:49 AM, Edward K. Ream edream...@gmail.com wrote: Hmm. I don't want to install a package before the tutorial tells me what it does... aha, even the examplar has a hole! Yes, that page *is* jumping into the middle of something. I suppose this is the proper start page, https://www.mapbox.com/tilemill/. I wasn't suggesting Leo readers install the package. Perhaps a better place to begin, for this conversation, is at not-quite the beginning of Crash Course, https://www.mapbox.com/tilemill/docs/crashcourse/point-data/ I like how it gives it describes it's location in the documentation, If you've found yourself on this page, we're assuming you've: a), b) -matt -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: computeLeadingWhitespaceWidth in leoGlobals.py
1. Although you claim that the two pieces of code are equivalent, you have not proven your claim. A unit test demonstrating that the two pieces of code are equivalent **for all relevant strings** would be essential. This one bugged me. The attached file tests ALL possible combinationes of blanks and tabs to an arbitrary width of leading whitespace (i.e. a width of 16 results in more 28 million tests). One function times the current function, one the new function, and one compares the results of applying both the functions to the same strings. I guess that takes care of **for all relevant strings**; just use a larger width. -- Reinhard -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out. import time def timer(func, *args, **kwargs): repetitions = kwargs.get(repeat, 10) start = time.clock() result = None i = 0 while i repetitions: result = func(*args) i += 1 elapsed = time.clock() - start print Time elapsed:, elapsed return (elapsed, result) def computeLeadingWhitespaceWidth (s,tab_width): Originial w = 0 for ch in s: if ch == ' ': w += 1 elif ch == '\t': w += (abs(tab_width) - (w % abs(tab_width))) else: break return w def computeLeadingWhitespaceWidth1(s,tab_width): Original enhanced w = 0 tw = abs(tab_width) for ch in s: if ch == ' ': w += 1 elif ch == '\t': w += (tw - (w % tw)) else: break return w def computeLeadingWhitespaceWidth2(s, tab_width): Alternative t = s.expandtabs(abs(tab_width)) return len(t) - len(t.lstrip()) def testWidth(): Time the functions with different functions. An arbitrary test string is used. Each test is repeated one million times. s = \t \t \t \t Leo\tis\ta\tbrilliant\tprogram. print s.expandtabs(4) timer(computeLeadingWhitespaceWidth, s, -4, repeat=100) timer(computeLeadingWhitespaceWidth1, s, -4, repeat=100) timer(computeLeadingWhitespaceWidth2, s, -4, repeat=100) def testAllWidth(n): Test all possible combinations of ' ' and '\t' up to n charcaters. n specifies the width of the leading whitespace to be tested. Be careful: The number of tests grows exponentially. def createTestStrings(n): testStrings = [ , \t] for i in range(1, n): t1 = [s + for s in testStrings] t2 = [s + \t for s in testStrings] testStrings = testStrings + t1 testStrings = testStrings + t2 # Add some characters at the end of the string testStrings = [s + abc for s in testStrings] print Tests to be performed:, len(testStrings) return testStrings def timeOld(testStrings): for s in testStrings: w = computeLeadingWhitespaceWidth(s, -4) def timeNew(testStrings): for s in testStrings: w = computeLeadingWhitespaceWidth2(s, -4) def compareResults(testStrings): errors = 0 for s in testStrings: w1 = computeLeadingWhitespaceWidth(s, -4) w2 = computeLeadingWhitespaceWidth2(s, -4) if w1 != w2: errors += 1 print *** error:, s, w1, w2 print Number of differences:, errors print start print Create testStrings... testStrings = createTestStrings(n) print Start timing... print Old function..., timer(timeOld, testStrings, repeat=1) print New function..., timer(timeNew, testStrings, repeat=1) print Compare functions... compareResults(testStrings) print done if __name__ == __main__: #testWidth() testAllWidth(16)
Re: An examplar of great docs for newcomers
On Mon, Nov 25, 2013 at 12:25 PM, Matt Wilkie map...@gmail.com wrote: On Mon, Nov 25, 2013 at 8:49 AM, Edward K. Ream edream...@gmail.comwrote: Hmm. I don't want to install a package before the tutorial tells me what it does... aha, even the examplar has a hole! Yes, that page *is* jumping into the middle of something. I suppose this is the proper start page, https://www.mapbox.com/tilemill/. Whether you're a journalist, web designer, researcher, or seasoned cartographer, TileMill is the design studio you need to create stunning interactive maps. Yes. This page tells me what the tool does. Thanks. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
That's also what I think of for macros and according to the Leo menu Cmd-Macros, Leo has this functionality. Start record, end record, and call macro are all there. On Nov 25, 2013 12:37 PM, Matt Wilkie map...@gmail.com wrote: In my mind Script means something that is written like a program but depends on the host environment, while Macro is something that is generally recorded and later played back (and, if the software is capable, allows editing of said macro in between. A knowledgeable practitioner can dispense with the record phase and just write to begin with). From this standpoint I would say Leo has Scripts but not Macros. What is meaningful to me is does this code snippet require Leo present to work?: Yes -- Script No -- Program -matt On Mon, Nov 25, 2013 at 6:29 AM, Edward K. Ream edream...@gmail.comwrote: On Mon, Nov 25, 2013 at 8:17 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Edward K. Ream wrote: On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard.engel...@googlemail.com mailto:reinhard.engel.de@ googlemail.com wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. I could be wrong, but I believe that emacs Lisp-based scripts can do all that as well. I was referring to VB macros and the like. Obviously, elisp can do more. 1. Emacs org mode provides clumsy access to outline data. 2. elisp has this. 3. org mode uses noweb, which does not have @others. 4. Presumably, this could be simulated in elisp, but it wouldn't be pretty. 5. Ditto. 6. elisp can do this. 7. ditto. Similar remarks apply to vim and vimoutline mode. Org mode is much clumsier to use than Leo. Scripts must be delimited by special markup. So yes, org mode can simulate anything that Leo can do, but these simulations are going to be clumsy, they will take a lot more work than the equivalent in Leo (which is why they haven't, in fact, been done) and the simulations are going to be a lot less convenient for users to use. The net effect: the pace of innovation in the Leo world far exceeds that of the vim/emacs worlds. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
Edward, though I am an org-mode user, I keep an eye on Leo. This is because, as far as I know, org-mode has no mechanism similar to your type of clones. Your clones are elegant. The things you can do with @others are only possible because of your elegant clones, is that fair to say? I hope that I can use clones like that in org-mode one day. Please let me be careful here. I don't wish to step on any toes here, but I'm about to suggest something radical: Could it be that org-mode isn't as clumsy as you think? :) Please consider this evidence: org-mode is easily hundreds of times more popular than Leo. It's also older, bigger, has more developers, and a more active mailing list. There's also an IRC channel. Do you really think that it would have such a dedicated community if it were 'clumsy'? :) As I see it, Leo could look to org-mode as an older brother and a positive role model. (Have you looked at the 8.x exporter framework? It is modular and supports more export formats than Leo, with very consistent results across formats.) As I alluded to, I see the sibling relationship as two way street: there is at least one big, important thing that I think org-mode should learn from Leo. But, it is a hard lesson, and I don't know how to convey it myself. Keep up the good work and happy holidays, --Dave p.s. Regarding the script delimiters, don't .leo files look the same, if you just read the source in a non-Leonine text editor? I know you're busy with Leo, but if you need a break sometime, spend an afternoon looking at org-mode's UI. Here is a short video that shows someone using the UI to work with code blocks http://www.youtube.com/watch?v=lsYdK0C2RvQ (in this case, they aren't running the code or tangling it into a program, they are writing documentation--but those tasks use the same UI). Here is a video that's much longer but happens to address your points 1, 2 and 4 through 7, (note 15:05 for point 4! Few emacs users use @button-type functionality, but it is there!) Incidentally, regarding #3: actually org-babel was inspired by, is compatible with, and supports noweb, but it doesn't depend on it or use it exclusively. You can re-use snippets in multiple places, but not as elegantly as Leo does it with clones. On Monday, November 25, 2013 8:29:55 AM UTC-6, Edward K. Ream wrote: On Mon, Nov 25, 2013 at 8:17 AM, Miles Fidelman mfid...@meetinghouse.netjavascript: wrote: Edward K. Ream wrote: On Mon, Nov 25, 2013 at 4:41 AM, Reinhard Engel reinhard...@googlemail. com javascript: mailto:reinhard...@googlemail.com javascript: wrote: Is there conceptually any difference between scripts in Leo and macros in other languages (not macros in C, but macros i.e. in Microsoft Word, Access or Visual Basic)? Two, no three, no four, no five, no six, no seven differences: 1. Leo scripts have access to outline structure. Most other scripting languages do not. 2. Leo scripts have full access to all of Leo's source code. 3. Leo scripts can be built up from outlines via section references. 4. Leo script can be embedded in @button nodes. 5. Leo scripts can be embedded in @test nodes. 6. Leo scripts can create external files, a special case of: 7. Leo scripts can do anything Python can do. I could be wrong, but I believe that emacs Lisp-based scripts can do all that as well. I was referring to VB macros and the like. Obviously, elisp can do more. 1. Emacs org mode provides clumsy access to outline data. 2. elisp has this. 3. org mode uses noweb, which does not have @others. 4. Presumably, this could be simulated in elisp, but it wouldn't be pretty. 5. Ditto. 6. elisp can do this. 7. ditto. Similar remarks apply to vim and vimoutline mode. Org mode is much clumsier to use than Leo. Scripts must be delimited by special markup. So yes, org mode can simulate anything that Leo can do, but these simulations are going to be clumsy, they will take a lot more work than the equivalent in Leo (which is why they haven't, in fact, been done) and the simulations are going to be a lot less convenient for users to use. The net effect: the pace of innovation in the Leo world far exceeds that of the vim/emacs worlds. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessibility of settings
On Monday, November 25, 2013 7:27:33 PM UTC+1, Matt Wilkie wrote: Why do I get the impression that you don't care for the accessibility i.e. of the settings? ...image snipped... Who wants to read this? I believe you are intending to be helpful, but the general tone of this message and a few others have come across as aggressive and inflammatory. My reaction on reading this comment was why do I get the impression he has zero appreciation for how much work has gone into this project?. Actually that was my second thought, my first one wasn't very flattering or conducive to a healthy conversation. ;-) -matt Got your point, Matt. Thanks for sharing! You made me think, what keeps me with Leo. Frankly, I don't care how much work has gone into this or that product. That's no criterium for quality or usefulness. What keeps me with Leo are mainly three points: First its brillant concept of cloning, the fact that the same data can be used in different places/nodes of an outline, though cloning is not a unique feature of Leo. I.e there is TheBrain, a mind and knowledge mangement software. There cloning is completely transparent. One can graphically link any item with any other item. Alas, it is not open-source and not scriptable. There are free and commercial versions available. Second the possibility to combine this nodes in arbitrary ways to generate external programs and documents. This possibility to combine nodes that flexible is quite unique. Third Leo's brilliant scriptability. Using Python for this purpose was a stroke of genius. Afik, no other IDE can match this flexibility (though I never worked with Emacs). On the other hand is this user interface of Leo, and the way Leo is introduced to prospective programmers. It's no accident that Leo isn't better known despite its great unique features. One would think, programmers should flock, if only they knew about Leo. But no... As if a Ben Shneiderman, a Jacob Nielsen, a Robert C. Martin and a lot of others, who cared and wrote about user interfaces, usability, naming conventions, codesizing and other programming topics, never existed. As if there aren't a lot of great free IDEs like Eclipse, PyCharm, Apple's development tools or Microsoft's Visual Studio are out there, that could be taken for a model. They have solved problems long ago that Leo still is struggling with. There one can study how settings, properties and the like can and should be presented to be easily accessible. Now look at the screenshot in my post. Well, my wording could have been 'softer'. But do you consider this a good solution? Do you really want to read or write a setting like 'atautowarnsaboutleadingwhitespace' (no camel case, not underscore). This doesn't have to be this way. And this wouldn't be this way if somebody just had shown a tiny little bit more concern for the user. This doesn't evoke feelings of 'appreciation'. But this is what you have to struggle with day for day, if you try learn Leo. And if you have to waste your time with one seemingly simple task after the other, you don't think of the greatness but rather along the lines of the first thought you didn't mention... Still, I haven't given up hope. --Reinhard -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Scripts vs. macros
On Mon, Nov 25, 2013 at 2:37 PM, Dave Loyall david.loy...@nebraska.govwrote: Could it be that org-mode isn't as clumsy as you think? Of course it is possible: I'm frequently wrong on many topics. Otoh, the video unintentionally shows just how clumsy org mode is. This video could be called an analog to Leo's rst3 command. Yes, it's cute, but it has little or nothing to do about any of the points I've raised. The video show how to make documents *containing* code snippets; it deals not at all with Leo's core features. Otoh, I'd like to see whether Leo can use a similar chain to in a convert-to-pdf add-on to the rst3 command ;-) To convince me that org mode has Leo's power, you have to show that it has the equivalent of at least the following: - Leo's generators: c.all_positions(), p.subtree(), etc. - A concept of current position, p. - p.insertAs..., p.doDelete, p.moveTo... - p.b, p.h and p.u. - @others and @file. Does org mode provide *any* of the features listed above. Not that I know of. Leo outlines are composed of true Python objects. Leo defines many operations on those objects. Does org mode preprocess text to make such operations fast? If not, org mode operations will be orders of magnitude slower. Please consider this evidence: org-mode is easily hundreds of times more popular than Leo. Not relevant. Emacs has been around a lot longer, so you could say it has a huge captive user base. And heck, all these users actually put up with elisp ;-) It's also older, bigger, has more developers, and a more active mailing list. There's also an IRC channel. Do you really think that it would have such a dedicated community if it were 'clumsy'? :) Yes I do. It's a possibility for you to consider ;-) Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Accessibility of settings
On Mon, Nov 25, 2013 at 5:00 PM, Reinhard Engel reinhard.engel...@googlemail.com wrote: One would think, programmers should flock, if only they knew about Leo. I think screencasts will help. As if a Ben Shneiderman, a Jacob Nielsen, a Robert C. Martin and a lot of others, who cared and wrote about user interfaces, usability, naming conventions, codesizing and other programming topics, never existed . I'm always interested in specific suggestions for improving Leo's code base or user interface. Now look at the screenshot in my post. There are many, many more important things to do. Edward -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
Re: Caution: Rev 6368 contains big changes to find code. Please test.
On Mon, Nov 25, 2013 at 8:52 AM, Edward K. Ream edream...@gmail.com wrote: There were several bugs. Rev 6370 (for the first time ever) uses a simple scheme to move from node to node and from pane to pane. I'll say more about this when I have time (I'm way busy just now). A little more work is coming, but the new code should handle everything perfectly except wrapped searches. Please report any problem (including old ones) immediately. My basic suboutline test case works for me now, thanks. It isn't clear to me once I've searched in one subtree, when/how I can then search in another subtree. With LeoPyRef.leo#Startup node selected, suboutline search for 'data' After the match is found, select the node LeoPyRef.leo#Notes and suboutline search for 'about' For me, no match is found, but when I change to Entire Outline, a match is found within that subtree. Brian -- You received this message because you are subscribed to the Google Groups leo-editor group. To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+unsubscr...@googlegroups.com. To post to this group, send email to leo-editor@googlegroups.com. Visit this group at http://groups.google.com/group/leo-editor. For more options, visit https://groups.google.com/groups/opt_out.
