On Thu, Jul 2, 2009 at 6:12 PM, TL<[email protected]> wrote: > Guilherme now has a "open with" solution. He's happy for now. > However, he is using a version that doesn't support most of the > functionality that is currently available in the open_with/vim plugin > solution, doesn't work with the Tk GUI, and is configured using a non- > standard Leo configuration method (i.e. an environment variable).
open_with.py only adds the entries in file -> open with, the rest of what is there is covered by contextmenu.py and core. Assuming that we want to allow launching a node in separate editors, it can easily be added "elsewhere". > So why didn't we just spend some time to get the open_with/vim plugin > implementation working for him? The contention is that it is doesn't > work reliably and that it is difficult to configure. My understanding (from looking at the code) was that open_with.py is implemented in a completely tk-specific fashion. It was much easier for me to implement the simple one-size-fits-all solution than start porting over the old stuff. > Is it difficult to configure? No. All that is required is the > enabling of a plugin and the declaring of a global in the > myLeoSettings.leo file. This is the standard Leo convention and > required knowledge to configure anything in Leo. What's needed is My idea all along has been that a user should not need to configure anything in Leo (apart from enabling plugins). It's ok if a user *can* configure stuff, but it should not be a requirement. The only stuff I have in myLeoSettings.leo is @enabled-plugins, and I get by alright. I don't know why a new user (that needs a safety net of his own editor, for a while at least ;-) should be urged to do a nontrivial configuration task. Additionally, the configuration of open_with *is* a bit contorted. Why do I need to specify subprocess.Popen as the launch method? > better documentation for new users and, perhaps, a change in Leo to > create a basic myLeoSettings.leo file if the user opens it from the > "Help" menu and the file does not exist. Automatic creation of myLeoSettings.leo would be nice. > Do we port all of the missing "open with vim" functionality into the > contextmenu.py plugin as well as any future code to support other > editors? In my opinion, the contextmenu.py plugin should, as a rule, Has anyone tried open with vim with contextmenu.py already? I think it could work without doing anything. At least I don't see anything special in the code that wouldn't work. It just calls c.openWith that does most of the work (just like contextmenu.py). If it doesn't work, we can easily make it work. > made for trivial features. At the moment, the new "open with" > implementation is trivial, providing a one-size fits all solution > which doesn't deal with the editor and operating system specific code > needed to restore the lost features and correctly handle certain > headline text. Adding that support will definitely result in the > embedding of a non-trivial feature within the contextmenu.py. Again, c.openWith does this part of the work. > Do we leave things the way they are with the understanding that some > users will switch to the open_with/vim plugin version when they need > the additional functionality? I assume users can can remove the > embedded "open with" feature from the context menu and add an entry > that invokes the open_with/vim plugin implementation. Yes, this can be done. > 1. Appending a file extension, based on the file type of an ancestor > node, to n...@file type nodes to enable the correct syntax > highlighting within the external editor. Implemented in c.openWith > 2. Launching only one copy of the external editor that displays the > latest exported node instead of launching separate copies of the > external editor for each node (configurable). > > 3. Utilizing the editor's multi-buffer display capability, such as > Vim's tab cards, to display multiple exported nodes in a single editor > view (configurable). > > 4. Positioning the cursor within the external editor on the same line > that Leo's cursor resided on at the time the node was exported > (configurable). We get these from vim.py. The only thing needed (if we want vim in contextmenu, as opposed to other launch mechanism) is to add a call to open_in_vim. Actually, vim.py can easily add this item by itself when loaded. > 5. Providing a means to determine the source node associated with the > text being edited in the external editor (configurable). Don't know what this is, so can't comment. > 1. Handling node headline text that contains characters that the > operating system, python, or Leo does not support in a directory path > or file name. > > 2. Handling node headline text that contains spaces. These are handled by c.openWith and they work. -- Ville M. Vainio http://tinyurl.com/vainio --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "leo-editor" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
