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).
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. Is it reliable? We don't know if it was operator error or bugs in the code. Regardless, it's a fact that the code is worn out and needs to be restructured. 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 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. So what are the next steps? 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, invoke functions that are implemented externally with exceptions only 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. Do we cleanup the open_with/vim plugin solution and have the contextmenu.py plugin invoke it? This is my recommendation. The plugin architecture already provides a nice solution for loading editor specific code. 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. Here are the features, currently working in the open_with/vim plugin implementation that are not implemented in the contextmenu.py: 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. 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). 5. Providing a means to determine the source node associated with the text being edited in the external editor (configurable). Here are problems/limitations in the current contextmenu.py implementation: 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. Regards, TL --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
