Re: Key bindings - Supporting updates
But separating vi_leoSettings.leo from leo_settings.leo - and having it work "just like" relationship of myleoSettings.le w.r.t. leoSettings.leo would work to have: - vi_leoSettings.leo be the "official" bindings / code /modes / etc. - centralized complexity; - allow "official" and supported (standard) extensions to settings (what TL raised as an issue); - allow "me" (normal user) to override key bindings, without mucking with all the complexity by using myvi_leoSettings.leo This pattern has elegance. In sum - I think TL has riased a valid point - as did Edward. This captures concerns of both, while setting up a useful settings extension pattern. Regards, Yarko On Jun 19, 9:58 am, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > On Wed, Jun 18, 2008 at 12:38 PM, TL <[EMAIL PROTECTED]> wrote: > > > Copying a set of key bindings from leoSettings.leo to > > myLeoSettings.leo to enable them means that users must be made aware > > when updates to those key bindings are made to the trunk and so they > > can copy them again to their myLeoSettings.leo file. Not an ideal > > situation. > > True, but the problem isn't that serious, and the proposed solution really > just pushes the problem back one level. I think myLeoSettings.leo suffices. > > > > > Is there any chance that a set of key bindings (like the Vim set) > > could remain in the leoSettings.leo file and be enabled/disabled by > > using an @bool command in the myLeoSettings.leo file to set a > > configuration variable as is done with other Leo configurations? > > I don't think this is a great idea: people will customize the vim settings > as they like, and would not necessarily approve of updated vim settings. In > other words, this "solution" might cause more problems than it solves. > myLeoSettings.leo gives control to the user where it belongs. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Vi problems: Prioritized
> it should be possible to define the needed commands using @command nodes. Any documentation on @command nodes? I can't find any. Thanks, TL --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: @file-nosent surprise
On Thu, Jun 19, 2008 at 10:11 AM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > On Wed, Jun 18, 2008 at 3:49 PM, Kent Tenney <[EMAIL PROTECTED]> wrote: >> >> I just created a node >> @file-nosent buildout/README.txt >> (README.txt is a rst file) >> >> the file buildout/README.txt exists, I expected it to >> be loaded into the body of the @file-nosent node, > > It is your expectations, not Leo, that are faulty. Leo can never read > @nosent nodes: Why not? I would like Leo to just place the file contents into the node in the case of @nosent for an existing file. > you use @auto to read nodes not containing sentinels. Can I supress the chunking of the file? (I want the entire file in the body) >> >> but the file on disk was overwritten by the empty body >> when I saved the Leo file. > > This is as expected. It's not clear to me why @file and @auto can originate on the file system, but @nosent cannot. As a user, I'm having trouble grasping the principles which determine behaviour of nodes which engage the filesystem. Thanks, Kent > >> I then selected >> File -> Read/Write -> Read @file nodes >> and was told the selected tree contained no @file nodes > > That's because there are no @file nodes. OK, I thought @file-nosent was a variation on @file, like a descendant, would inherit @file characteristics, but not inject sentinels. >> >> I then changed >> @file-nosent >> to >> @file buildout/README.txt >> >> and got >> >> reading: @file buildout/README.txt >> Bad @+leo sentinel in: buildout/README.txt >> can not read 3.x derived file buildout/README.txt >> you may upgrade these file using Leo 4.0 through 4.4.x >> exception executing command >> >> >> File "/home/ktenney/lib/bzr/leo-editor/leo/core/leoAtFile.py", line >> 614, in readOpenFile >>at.completeLastDirectives(lines,lastLines) >> UnboundLocalError: local variable 'lastLines' referenced before assignment > > This fix is on the trunk. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Thu, Jun 19, 2008 at 10:03 AM, Terry Brown <[EMAIL PROTECTED]> wrote: > > On Thu, 19 Jun 2008 09:53:55 -0500 > "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > > > It is rare to have more than a dozen children > > Leo can be used for many different tasks, certainly one focus is > writing code, and in that case you're probably right, but other > applications like cataloging various things, or overlaying a > filesystem, can easily end up with 2-300 children on a node. That may > be an indication that the underlying system is badly organized, but > then again, perhaps you're trying to use leo to analyze / fix its > organization. I agree. My comment wasn't particularly edifying. > > It's kind of amusing that back links on vnodes vanish just before a use > for them is found :-) but not a big deal, even if there are 1000 > children on a node, making and reversing a list shouldn't be too memory > consumptive. Reversing's fast and positions are small. Reversing a list of even 10,000 elements will be fast enough because it happens at essentially C speed (the language C, not the speed of light :-) I have found that one of Python's great advantages for me is that I don't worry about performance until there is a for-real problem. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: @file-nosent surprise
On Wed, Jun 18, 2008 at 3:49 PM, Kent Tenney <[EMAIL PROTECTED]> wrote: > > I just created a node > @file-nosent buildout/README.txt > (README.txt is a rst file) > > the file buildout/README.txt exists, I expected it to > be loaded into the body of the @file-nosent node, It is your expectations, not Leo, that are faulty. Leo can never read @nosent nodes: you use @auto to read nodes not containing sentinels. > > but the file on disk was overwritten by the empty body > when I saved the Leo file. This is as expected. I then selected > File -> Read/Write -> Read @file nodes > and was told the selected tree contained no @file nodes That's because there are no @file nodes. > > I then changed > @file-nosent > to > @file buildout/README.txt > > and got > > reading: @file buildout/README.txt > Bad @+leo sentinel in: buildout/README.txt > can not read 3.x derived file buildout/README.txt > you may upgrade these file using Leo 4.0 through 4.4.x > exception executing command > > > File "/home/ktenney/lib/bzr/leo-editor/leo/core/leoAtFile.py", line > 614, in readOpenFile >at.completeLastDirectives(lines,lastLines) > UnboundLocalError: local variable 'lastLines' referenced before assignment This fix is on the trunk. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Thu, 19 Jun 2008 09:53:55 -0500 "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > It is rare to have more than a dozen children Leo can be used for many different tasks, certainly one focus is writing code, and in that case you're probably right, but other applications like cataloging various things, or overlaying a filesystem, can easily end up with 2-300 children on a node. That may be an indication that the underlying system is badly organized, but then again, perhaps you're trying to use leo to analyze / fix its organization. It's kind of amusing that back links on vnodes vanish just before a use for them is found :-) but not a big deal, even if there are 1000 children on a node, making and reversing a list shouldn't be too memory consumptive. Reversing's fast and positions are small. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: New key settings inventions/conventions
On Wed, Jun 18, 2008 at 12:20 PM, TL <[EMAIL PROTECTED]> wrote: > > I now have some local code which binds keys to the do-nothing > command. For example, "do-nothing !tree = Ctrl-a". It seems to have > an advantage over using the "! kill" approach in that it retains > support for targeting the outline or the body pane and it doesn't > require knowledge of the key's previous bound function. I like the idea, but... > > Am I missing something? there may be problems with Leo complaining about redefined bindings. But otoh, maybe the simplest solution would be to suppress such complaints when binding to do-nothing. That would indeed make !kill unnecessary. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Key bindings - Supporting updates
On Wed, Jun 18, 2008 at 12:38 PM, TL <[EMAIL PROTECTED]> wrote: > > Copying a set of key bindings from leoSettings.leo to > myLeoSettings.leo to enable them means that users must be made aware > when updates to those key bindings are made to the trunk and so they > can copy them again to their myLeoSettings.leo file. Not an ideal > situation. True, but the problem isn't that serious, and the proposed solution really just pushes the problem back one level. I think myLeoSettings.leo suffices. > > > Is there any chance that a set of key bindings (like the Vim set) > could remain in the leoSettings.leo file and be enabled/disabled by > using an @bool command in the myLeoSettings.leo file to set a > configuration variable as is done with other Leo configurations? I don't think this is a great idea: people will customize the vim settings as they like, and would not necessarily approve of updated vim settings. In other words, this "solution" might cause more problems than it solves. myLeoSettings.leo gives control to the user where it belongs. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Thu, Jun 19, 2008 at 9:29 AM, Terry Brown <[EMAIL PROTECTED]> wrote: > > On Thu, 19 Jun 2008 09:26:42 -0500 > Terry Brown <[EMAIL PROTECTED]> wrote: > > > Perhaps there's no need to make a list and reverse it, seeing vnodes > > have back links (I think) it's cheap to iterate children first to > > last. > Vnodes used to have back links, but they don't any more. This whole discussion has the feel of being overly concerned with performance. It is rare to have more than a dozen children, so even slow code should be plenty fast enough. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Thu, Jun 19, 2008 at 9:26 AM, Terry Brown <[EMAIL PROTECTED]> wrote: > > My approach relies on making a list of nodes and reversing it so you > know that you're not deleting the ground you're standing on, or will be > standing on. Yes, this will probably work. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: request to add plugin to leoPluginsRef
On Tue, Jun 17, 2008 at 5:24 AM, bobjack <[EMAIL PROTECTED]> wrote: > > Could [rClickBasePluginClasses] be added to leoPluginsRef.leo please? > > I did add it myself but, whether by accident or design, it go removed. Done. It was actually in leoPluginsRef.leo (it caused a conflict with my addition), but I reverted to my version and all seems well. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Thu, 19 Jun 2008 09:26:42 -0500 Terry Brown <[EMAIL PROTECTED]> wrote: > Perhaps there's no need to make a list and reverse it, seeing vnodes > have back links (I think) it's cheap to iterate children first to > last. Um, last to first, I meant. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Thu, 19 Jun 2008 08:47:02 -0500 "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > This should work because p's position doesn't change when it's > children are deleted. The general case is even harder. One might > have to iterate repeatedly over the entire outline. Hmm, I can see where an outline with a couple of thousand nodes could be really unwieldy that way. My approach relies on making a list of nodes and reversing it so you know that you're not deleting the ground you're standing on, or will be standing on. I think you could write a generator based on a recursive iterator which would yield nodes in a sort of last child first order... but of course I'm not sure how it would interact with clones. I guess they shouldn't be a problem. Perhaps rather than a new iterator intended just for deleting, something like p.deleteChildren(cond) and p.deleteDescendents(cond) where cond is a callable taking one argument, a position, and returning True for False (delete or don't). So deleteChildren and deleteDescendents would be responsible for iterating in a safe way. Of course you want to take advantage of the efficiency of deleting a whole subtree first, rather than deleting a whole bunch of individual nodes in a subtree only to find that the whole tree also needs deleting. Perhaps there's no need to make a list and reverse it, seeing vnodes have back links (I think) it's cheap to iterate children first to last. I'll experiment and see what I come up with. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Vi problems: Prioritized
On Wed, Jun 18, 2008 at 9:31 AM, TL <[EMAIL PROTECTED]> wrote:
>
> > beginning of line => 0 [zero] doesn't work.
> >
> > Notes in vi bindings say "0 not used because if bound it won't be
> > inserted during insert/editing mode".
>
> Binding to the numbers 0 thru 9 are not supported.
I don't think this is correct. It should be possible to bind any Leo
command to Key-0 through Key-9, though I haven't tested this.
What is not supported at present is binding Key-n to a function that
remembers that 'n' was pressed.
> > "dw" (delete word" deletes to the next word in VI,
> > but not in Leo.
>
> Vi uses "dw" to go to the first character that is not alpha-numeric or
> an underscore. Vi uses dW to go to the first blank character. Leo's
> vi emulation uses Leo's forward-word command which has it's own
> rules. This is also true for the "w" and "W" commands any vi command
> that takes a {motion} argument such as "cw" and "cW". The same
> situation exists for going back a word ("b" and "B") or to the end of
> a word ("e" and "E").
>
> I shouldn't be difficult to create functions in Leo to support these
> vi operations.
I agree. And it should be possible to define the needed commands using
@command nodes.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---
Re: writing an unreadable file...
On Wed, Jun 18, 2008 at 3:18 PM, Terry Brown <[EMAIL PROTECTED]> wrote: > > I got some odd characters in a filename into leo, it saved the file fine, > but wouldn't > read it: Thanks for this report. It should be possible to fix this cleanly. I'll do so immediately: it must be part of the b1 release. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tkinter key woes
On Wed, Jun 18, 2008 at 8:35 AM, Edward K. Ream <[EMAIL PROTECTED]> wrote: > > At present, it appears that plain-key bindings may interfere with > previous control-key bindings. Don't know that this is actually a Tk > problem: the code is amazingly complex, and so it may be my fault. As I stated in another reply on this thread, it is now clear that Leo is at fault, which is excellent news. Indeed, when mixing EKR and vim bindings no entry gets made in k.bindingsDict for ctrl-s, which means ctrl-s does not show up in the show-bindings command. More importantly, no entry is made in k.masterGuiBindingsDict, which means that no 'stroke' is passed to k.masterKeyHandler (in other words, only the generic binding fires). As I write this, I realize that I should create a new branch in order to explore possible solutions. The code is just at the limit of my ability to understand it, so changes are far from risk free. Moreover, several different fixes are possible, and I would rather not experiment on the trunk. And I realized yesterday that some new invention is needed to handle menu accelerators. Iirc, the menu code never actually makes key bindings, which means we could use multi-character hints (accelerators) for vim commands. For example ': q ' for the quit command. The code that creates these hints/accelerators is fantastically complicated (for historical reasons), but it would be useful to allow @menu and @item nodes to specify the accelerators (say for vim bindings). So this is another reason to make a separate branch. In short, vim bindings kinda work, but much more work is needed to have them work smoothly. I probably will release b1 in a day or so. There are many good things that should be released asap. I'll then turn my attention to all the vim-related nits. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: Tkinter key woes
On Wed, Jun 18, 2008 at 10:30 AM, TL <[EMAIL PROTECTED]> wrote: > > > At present, I do not recommend using the vim bindings. > > The bindings themselves are fine: the problem is elsewhere-- > > either Leo or Tk. At present, it appears that plain-key > > bindings may interfere with previous control-key bindings. > > I haven't seen a problem with the mapping of keys using the "! tree" > and "! body" directives. What problem have you seen with the vim > emulation that suggests that it should not be used? Let me repeat. There are no real problems with the vim bindings themselves. There is a problem with mixing the EKR bindings with the vim problems. In particular, no "master gui" binding gets made for ctrl-s. This is clearly a Leo problem, which is good news. Feel free to use the vim bindings by themselves, and be aware that some of the mode bindings in vim bindings interfere with the corresponding EKR bindings. > > The current vi emulation doesn't try to or need to determine what key > was pressed. Why is the "Tk key event" problem being associated with > the vi emulation? For the reason given above: due to a bug in Leo, ctrl-s gets suppressed (in some cases). > > > If your looking for a solution to the "repeat previous command" using > the '.' key problem, I suggest you avoid the Tk package, by tracking > the last executed "repeatable" @mode node instead of tracking the last > pressed "repeatable" key. Those @mode nodes that are repeatable could > call a function that saves the @mode label that a second function, > bound to the '.' key, accesses and invokes with each '.' key press. This is a separate issue. There is no way to "avoid the Tk package". That is, I assume that k.masterKeyHandler will be called for *all* keystrokes. There are two completely separate problems: 1. How to ensure that a "master key binding" gets bound to all keys so that k.masterKeyHandler always gets called and 2. How to implement the dot command in k.masterKeyHandler (or its helpers, probably k.masterCommandHandler.) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: neatest way to eliminate nodes
On Wed, Jun 18, 2008 at 3:48 PM, Terry Brown <[EMAIL PROTECTED]>
wrote:
>
> Whoops, I now find my second approach doesn't work, so back to the
> original question, what's the neatest way to remove nodes matching a
> criteria?
The only good answer is: carefully. The problem is that deleting a node
invalidates positions.
So my untested guess for how to do this is:
while True:
if << node matches criterion >>
<< delete the node >>
else:
break
In your example, this would translate to:
p = c.currentPosition()
c.beginUpdate()
try:
while True:
for child in p.children_iter():
if child.headString().startswith('*'):
c.setChanged(True)
g.es(child.headString())
child.doDelete()
break # inhibit 'else' clause of the 'for' loop.
else: break
finally:
c.endUpdate()
This should work because p's position doesn't change when it's children are
deleted. The general case is even harder. One might have to iterate
repeatedly over the entire outline.
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/leo-editor?hl=en
-~--~~~~--~~--~--~---
Re: I have trashed the trunk.
On Thu, Jun 19, 2008 at 7:00 AM, bobjack <[EMAIL PROTECTED]> wrote: > > I'm sorry I appear to have trashed the trunk. > > Guess I'm having a bad hair day :( > In the future, be sure to run all unit tests before any push. Having all unit tests pass guarantees that a) Leo will most likely continue to work and b) you have done your due diligence. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: registerCommand bug, bobjack's big boo boo
On Thu, Jun 19, 2008 at 4:20 AM, bobjack <[EMAIL PROTECTED]> wrote: > > I apologize profusely for this very serious error which must have > caused a lot of problems and unnecessary hard work for Edward and > others. Don't worry about it. I doubt this had much effect on the work I am doing. 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: at_folder plugin
This wot I wrote is rubbish. Sorry I go my wires crosssed. Oh well guess I need a holiday, whers my fishhing rod. :) On Jun 19, 10:29 am, bobjack <[EMAIL PROTECTED]> wrote: > No this is not so Edward. The wrappers also convert separators in > strings as I said which os.path does not, I don't have the code to > hand but I'll put a pointer to the relevant part later. > > @path has to handle partial strings from the user which have embedded > separators. > > On Jun 18, 12:51 pm, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > > > > > This discussion of g.os_path_x vs. os.path_x is off the mark. > > > The g.os_path_x wrappers exists for only one reason: to handle unicode > > filenames properly. In all other respects g.os_path_x and os.path_x are > > identical. Indeed, the g.os_path_x methods call the os.path methods. > > > Edward- Hide quoted text - > > - Show quoted text - --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: registerCommand bug, bobjack's big boo boo
I have changed wrap=True to wrap=False and fixed the crasher which was only in my own plugin anyway. Hopefully the only effect now will be that some problems that we have been experiencing will have disappeared. It is possible that in an attempt to fix apparent bugs arising out of this, other bugs will have been introduced. Once again, I appologise for any disruption and extra work I have caused by introducing this bug. Bob On Jun 19, 10:20 am, bobjack <[EMAIL PROTECTED]> wrote: > I am ashamed to say that I have made a very big and very stupid > mistake. When I added the c.universallCallback wrapper (appart from > mis-spelling universal) I added a wrap=True argument to > k.registerCommand so it would wrap func in c.universalCallback when so > requested. This should of course have been wrap=False. > > The result is that ALL commands registerd with k.registerCommand are > wrapped and so will not recieve the correct event argument. > > I apologize profusely for this very serious error which must have > caused a lot of problems and uneccessary hard work for Edward and > others. > > I will of course do my very best to help resolve the situation. > Unfortunately simply replacing wrap=True with wrap=False causes > crashes. I will continue to investigate the problem. > > Bob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: I have trashed the trunk.
Think I've fixed it now. On Jun 19, 1:00 pm, bobjack <[EMAIL PROTECTED]> wrote: > I'm sorry I appear to have trashed the trunk. > > Guess I'm having a bad hair day :( > > Bob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
I have trashed the trunk.
I'm sorry I appear to have trashed the trunk. Guess I'm having a bad hair day :( Bob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
Re: at_folder plugin
No this is not so Edward. The wrappers also convert separators in strings as I said which os.path does not, I don't have the code to hand but I'll put a pointer to the relevant part later. @path has to handle partial strings from the user which have embedded separators. On Jun 18, 12:51 pm, "Edward K. Ream" <[EMAIL PROTECTED]> wrote: > This discussion of g.os_path_x vs. os.path_x is off the mark. > > The g.os_path_x wrappers exists for only one reason: to handle unicode > filenames properly. In all other respects g.os_path_x and os.path_x are > identical. Indeed, the g.os_path_x methods call the os.path methods. > > 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
registerCommand bug, bobjack's big boo boo
I am ashamed to say that I have made a very big and very stupid mistake. When I added the c.universallCallback wrapper (appart from mis-spelling universal) I added a wrap=True argument to k.registerCommand so it would wrap func in c.universalCallback when so requested. This should of course have been wrap=False. The result is that ALL commands registerd with k.registerCommand are wrapped and so will not recieve the correct event argument. I apologize profusely for this very serious error which must have caused a lot of problems and uneccessary hard work for Edward and others. I will of course do my very best to help resolve the situation. Unfortunately simply replacing wrap=True with wrap=False causes crashes. I will continue to investigate the problem. Bob --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en -~--~~~~--~~--~--~---
