Re: c.bind c.bind2 bugs
On Mon, Jun 16, 2008 at 4:14 AM, bobjack [EMAIL PROTECTED] wrote: I'm not familiar with tag_bind, maybe the add=None fix should be applied to that as well? Let's not touch tag_bind now. 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: minor rclick issue
On Jun 16, 8:51 am, Edward K. Ream [EMAIL PROTECTED] wrote: You were wise not to attempt a specific fix. Actually, the fix involved creating new callbacks in several plugins where there are calls of the form: b.configure(command=command) In other words, a common pattern is: b = c.frame.addIconButton() ... b.configure(command=command) As I write this, I realize that addIconButton can also have a command arg, so maybe a few more fixes are needed... Perhaps one or more new convenience methods would be good too. This is turning out to be a bit tricky. It would be nice to have a cleaner solution... 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
Sorry for the late reply. Been busy. Never mind. I see that the docs are actually quite good. I've rendered them in restructured text in leoDocs.leo. Thanks for the feedback and the work to put them in leoDocs.leo You can see the preliminary result at http://webpages.charter.net/edreamleo/vimBindings.html Some to the documentation is outdated (my fault). I'll update it soon. However, I would like help with one point: The discussion for body pane bindings says: All vi text navigation and editing functionality has been implemented except for the following. I saw your follow-up post indicating that you will dive into the actual key bindings. Good idea. They are not that hard to understand and I've standardized their naming and how they are coded (mostly). BTW, the patches, problems and notes sections are quite helpful. If was hard to read them because of their format, but I've reformatted them in my to-do list so I can read them comfortably now. I used the OTL outliner plugin for Vim to write the documentation. The document is easier to read with syntax highlighting. I'll fix the items on the list of problems one by one. Some, I think, have already been fixed. Great. Thanks. Let me know how I can help. 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: at_folder plugin
On Fri, Jun 13, 2008 at 8:38 AM, Kent Tenney [EMAIL PROTECTED] wrote: Why is the code very complex? It's complex because there are lots of special cases. This is often the case with code that looks simple. In this case, the special cases involve issues such as the following: - How to default to the current working directory. - How to default to the directory from which the file was opened. (This won't exist for new files). - What to do if directories don't exist. - How to handle relative v absolute directories. - What do do if no @path is given. All these issues can be subtly different depending on context: @auto, @thin, scripts, etc. Is it possible to simplify it? Yes and no. Sometimes code can be simplified by refactoring, but that's not easy here. The relevant codes are at: Code--Core classes...--@thin leoAtFile.py--at.Uilites--atFile.scanAllDirectives Code--Core classes...--@thin leoTangle.py--class tangleCommands methods--utility methods--tangle.scanAllDirectives Code--Core classes...--@thin leoGlobals.py--Commands Directives--Directive utils...--g.scanDirectives And it's dangerous to change this code: subtle changes could mess up people's outlines. And naturally, there are no unit tests :-) 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
On Fri, Jun 13, 2008 at 11:09 AM, Terry Brown [EMAIL PROTECTED] wrote: My active_path plugin is working quite well now. I'll commit it to the trunk, it's only a plugin so it won't do anything unless you enable it (active_path.py). Very interesting. I'll add @thin active_path.py to leoPlugins.leo soon. I'll have a go at making @path nest, Edward - just want to verify you're not looking at it right now. Correct. It's on the list for b2 at the earliest. 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: c.bind c.bind2 bugs
On Mon, Jun 16, 2008 at 9:38 AM, bobjack [EMAIL PROTECTED] wrote: Doh! Yes of course! Thank you. I added the *args arg to both c.bind and c.bind2. It's now on the trunk. With this change, c.bind and c.bind2 are identical. If this change actually works I'll eventually change all calls to c.bind2 to c.bind. No hurry, though... 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
On Mon, Jun 16, 2008 at 10:04 AM, Edward K. Ream [EMAIL PROTECTED] wrote: On Fri, Jun 13, 2008 at 8:38 AM, Kent Tenney [EMAIL PROTECTED] wrote: Why is the code very complex? It's complex because there are lots of special cases. This is often the case with code that looks simple. In this case, the special cases involve issues such as the following: - How to default to the current working directory. - How to default to the directory from which the file was opened. (This won't exist for new files). - What to do if directories don't exist. - How to handle relative v absolute directories. - What do do if no @path is given. All these issues can be subtly different depending on context: @auto, @thin, scripts, etc. I don't appreciate the subtleties. It seems the only time @path matters is if a directive was followed by a file name. @auto @file @nosent ... When a file name is encountered, Leo ascends the tree, prepending @path statements as found. If the resulting path began in the filesystem root it is absolute, if not prepend the .leo file home. If the resulting fq filename is invalid issue a report. It seems to me that those requirements are the same for any situation involving the name of the file on the filesystem. If all was ok except the existence of the directory which the named file is to live in, the config would be consulted and the directory would be created or a report issued.. What am I missing? Thanks, Kent Is it possible to simplify it? Yes and no. Sometimes code can be simplified by refactoring, but that's not easy here. The relevant codes are at: Code--Core classes...--@thin leoAtFile.py--at.Uilites--atFile.scanAllDirectives Code--Core classes...--@thin leoTangle.py--class tangleCommands methods--utility methods--tangle.scanAllDirectives Code--Core classes...--@thin leoGlobals.py--Commands Directives--Directive utils...--g.scanDirectives And it's dangerous to change this code: subtle changes could mess up people's outlines. And naturally, there are no unit tests :-) 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
Afaik all vim-like patches have been applied to the latest trunk:
Headline pane:
- (Done earlier) Prevent -- exit-named-modes from switching focus
to the Body pane.
Removed 'c.frame.log.deleteTab('Mode') from endMode
Body pane:
- (Done today) Enable search for 'space' character in text
Removed 'if ch.isspace(): return' in zapToCharacter:
- (Done today) Eliminate delete-word from removing trailing white
space
Removed 'self.killWs(event)' in killWord and backwardKillWord
- (Done earlier) Put zapped text to clipboard
Added 'g.app.gui.replaceClipboardWith(s[ins:i])' after
'sel.addToKillBuffer(s[ins:i])' in zapToCharacter
Imo, the changes to delete-word and backward-delete-word are slightly
dubious, but they will remain unless people complain.
I plan now to resolve most of the remaining vim problems.
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
-~--~~~~--~~--~--~---
