The utility I use basically just specifies - interpreter (shell or an application) - code (node contents, either a command line or script) - where stdout and stderr go
This has been adequate for me. On Tue, Feb 28, 2012 at 9:03 AM, Edward K. Ream <[email protected]> wrote: > Revs 5037/8 contain fixes that allow the open-with command to start to > work, at least in 'subprocess.Popen' mode. > > However, I think it is time for a complete rethink of how users > specify open-with settings. > > ===== The problems > > 1. The format of settings in @openwith nodes is way too wonky. At > present, the body text of such nodes consists of a single line, which > contains a 3-tuple of elements. Let us call this line the **open-with > line**. > > The entire open-with line must be a valid Python tuple. This causes > problems for both user and implementation, as discussed more fully > below. > > 2. openTempFileInExternalEditor is the method that translates the > settings in @openwith nodes into code that actually open the temp file > with the desired editor. At present, this method has to do an > **eval** of the single @openwith line, which has lots bad > consequences: > > - eval is a slight security problem, although there are a gazillion > worse problems. > > - The user has to quote strings, and those quotes are removed by eval, > so there is no easy way to specify quoted strings (the user has to > *doubly* quote strings.) > > - There is no indication of what the parts of the open-with line mean. > > 3. At present, openTempFileInExternalEditor does some ridiculously- > complicated munging of the *eval'd* open-with line in order to get > produce the correct call to subprocess.Popen. It's possible that > there is an easier way, but I haven't found it yet. > > ===== A proposed solution > > 1. We need a much more user-friendly format for @openwith nodes. Let > us suppose that the body of @openwith nodes contains one or more lines > of the following form:: > > tag: value > > The possible tags will be:: > > - kind: <a string> > > The value specifies the **opener logic**, that is, the method used to > launch the external editor, one of > ('subprocess.Popen','os.system','os.startfile','os.spawnl','os.spawnv', > 'exec') > > - arg: <a string> > > There may be many such arg lines. Each line will be a string to be > passed as an argument to the opener logic, in a format that is > compatible with the specified opener logic. > > **Important**: quotes in <a string> will be *retained* (not eval'd), > allowing the user to specify exactly the arguments to be passed to > opener logic. > > - custom: <a string> > > Here, <a string> *will* be eval'd, yielding an object to be used as > the opener logic. > > It's likely that either the "custom" tag or the "exec" opener value is > redundant. > > ===== Summary > > The present scheme is wonky, confusing, inflexible and extremely > difficult to implement. It should be replaced immediately. > > It is urgent to do this asap, so that the new scheme can be tested in > time for Leo 4.10 b1. > > Your comments please, Amigos. > > Edward > > -- > 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. > -- 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.
