Re: Vi problems: Prioritized

2008-06-18 Thread yarko
(it's a nit because I did discover in place of [zero], TL bound | to this function, so just something to get used to...) On Jun 18, 12:25 am, yarko [EMAIL PROTECTED] wrote: Another nit - but has to do with key binding machinery, so I'll bring it up: Motion in VI: up-down-left-right work

Re: at_folder plugin

2008-06-18 Thread bobjack
On Jun 17, 3:03 pm, Terry Brown [EMAIL PROTECTED] wrote: On Tue, 17 Jun 2008 08:47:20 -0500 Terry Brown [EMAIL PROTECTED] wrote: os.path is OS aware... but g.os_path_ may be the better option anyway, saves importing os etc. Of course, I hope the active_path plugin will be able to use

Re: at_folder plugin

2008-06-18 Thread Edward K. Ream
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

Tkinter key woes

2008-06-18 Thread Edward K. Ream
I'm just about at my wits end concerning Tk key handling. Maybe that's a good thing: it may be time to try some new things. 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

Re: Tkinter key woes

2008-06-18 Thread TL
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 !

Re: New key settings inventions/conventions

2008-06-18 Thread TL
My initial approach of unbinding all of the commands was conceptually flawed. Instead, the approach should have been to unbind all keys (or just the unused keys as you suggest). I now have some local code which binds keys to the do-nothing command. For example, do-nothing !tree = Ctrl-a. It

Key bindings - Supporting updates

2008-06-18 Thread TL
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. Is there any chance that a

Re: Key bindings - Supporting updates

2008-06-18 Thread yarko
...or maybe a way to include other setting files (akin to plugins), then you could include a vileoSettings.leo file (*grin* mimicking my leo Settings naming) On Jun 18, 12:38 pm, TL [EMAIL PROTECTED] wrote: Copying a set of key bindings from leoSettings.leo to myLeoSettings.leo to enable them

neatest way to eliminate nodes

2008-06-18 Thread Terry Brown
What's the best way do delete nodes? I find myself writing this: def cmd_PurgeVanishedFiles(c): Remove files no longer present, i.e. *filename* entries. p = c.currentPosition() c.beginUpdate() try: cull = [child.copy() for child in p.children_iter() if