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.
