open-with starting to work: it's time to *really* fix it

[Edward K. Ream]

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

[Kent Tenney]

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.

> --
> You received this message because you are subscribed to the Google Groups "leo-editor" group.
> To post to this group, send email to leo-e...@googlegroups.com.
> To unsubscribe from this group, send email to leo-editor+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/leo-editor?hl=en.
>

[Ville M. Vainio]

I guess basic use cases are covered by rclick menu?

[Edward K. Ream]

On Tue, Feb 28, 2012 at 9:46 AM, Kent Tenney <kte...@gmail.com> wrote:
> 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.

Iirc, the various options were requested by one or another of Leo's
users. Presumably these aren't vital feature--there have not been
many complaints while the Open With menu has been *completely* broken.

@Ville

> I guess basic use cases are covered by rclick menu?

Thanks for this suggestion. Reviewing the contextmenu.py plugin, I
see that it uses the $EDITOR system setting.

It seems like something very simple like this might make the open-with
command more useful than it is now. I'll investigate today...

Edward

[Edward K. Ream]

On Feb 28, 9:03 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> ===== A proposed solution
>
> 1. We need a much more user-friendly format for @openwith nodes.

Rev 5042 implements this solution. It is much better in all
dimensions:

@openwith nodes are easy to understand. For examples, see
leoSettings.leo. In particular, Leo no longer munges quotes. If you
want something quoted, then quote it in the @open node.

eval is a thing of the past.

The crucial code in openTempFileInExternalEditor is now quite simple.

More testing is needed, but already we have something that looks like
working.

To do: test other kinds of openers besides subprocess.Popen & update
the docs.

Edward

[SegundoBob]

Using Leo-Editor Rev. 5051 under Unbuntu 11.10 with the Fluxbox window
manager.

I was prompted to correct the lack of a tag in the @openwith node in
my myLeoSettings.leo.
I fixed this problem. My new @openwith node is:

Headline:
@openwith emacs = Alt+Shift+Ctrl+E

Body:
kind: subprocess.Popen
arg: /usr/bin/emacs
---end body---

Now I can edit the body of any node using emacs---but any changes I
make never make it back into my Leo-Editor file. I think my changes
should be put back in my Leo-Editor file. Since I have never used
this feature much, I'm not certain that this ever worked as I
expected, but I think this once worked.

There is even more surprising behavior: I used emacs to change a
body. I wrote the changes to the Leo-editor temporary file. I exited
back to Leo-Editor and saw that my changes were not put in my Leo-
Editor file. Again I used emacs to edit the same node. The start
message this time was "reopening" (last log-pane message below), and
my change was still there in the temporary file--so I was not editing
the contents of the node body.

creating: file_tmp_x_py_LeoTemp_177510284.py
time: 1330626562.009093
reopening: file_tmp_x_py_LeoTemp_177510284.py

[Edward K. Ream]

On Thu, Mar 1, 2012 at 12:34 PM, SegundoBob <bhos...@ieee.org> wrote:
> Using Leo-Editor Rev. 5051 under Unbuntu 11.10 with the Fluxbox window
> manager.

> Now I can edit the body of any node using emacs---but any changes I

> make never make it back into my Leo-Editor file.  I think my changes
> should be put back in my Leo-Editor file.

Correct. As I recently wrote somewhere (this thread?) you must enable
the contextmenu.py plugin for this to happen.

I'm not sure when this functionality migrated out of the vim.py and
xemacs.py plugins, but I can guess why it happened: there was a
conflict in the "idle" event handler, and somebody decided to put all
the idle-time functionality in one place.

At present, however, contextmenu.py doesn't play well with the vim.py
and xemacs.py plugins: it raises a dialog any time vim.py or xemacs.py
want to update the Leo outline. That is way too clumsy, and must be
fixed before Leo 4.10 b1.

Edward

[Ville M. Vainio]

On Sat, Mar 3, 2012 at 1:06 PM, Edward K. Ream <edre...@gmail.com> wrote:

> Correct.  As I recently wrote somewhere (this thread?) you must enable
> the contextmenu.py plugin for this to happen.
>
> I'm not sure when this functionality migrated out of the vim.py and
> xemacs.py plugins, but I can guess why it happened: there was a
> conflict in the "idle" event handler, and somebody decided to put all
> the idle-time functionality in one place.

I did that back when I created Edit commands for context menu.

vim.py problems were subsequently fixed, maybe they have surfaced
again because of other changes.

[Edward K. Ream]

On Sat, Mar 3, 2012 at 5:42 AM, Ville M. Vainio <viva...@gmail.com> wrote:
>> I'm not sure when this functionality migrated out of the vim.py and
>> xemacs.py plugins, but I can guess why it happened: there was a
>> conflict in the "idle" event handler, and somebody decided to put all
>> the idle-time functionality in one place.
>
> I did that back when I created Edit commands for context menu.
>
> vim.py problems were subsequently fixed, maybe they have surfaced
> again because of other changes.

Thanks for the confirmation. I am going to fix the present problems,
probably by having the contextmenu plugin skip the dialog when the
update is to a temp file created by the vim or xemacs plugins.

Edward

[Edward K. Ream]

On Mar 3, 9:36 am, "Edward K. Ream" <edream...@gmail.com> wrote:

> Thanks for the confirmation.  I am going to fix the present problems,
> probably by having the contextmenu plugin skip the dialog when the
> update is to a temp file created by the vim or xemacs plugins.

Done in the trunk at rev 5066. Here is the checkin log:

Several changes so that the vim and xemacs plugins work well with
contextmenu plugin.

- vim.py and xemacs.py load contextmenu.py if necessary the first time
they open a temp file.

- contextmenu.py (edit_node_on_idle) suppresses the "conflicts dialog"
if the file's path is in
[z.get('path') for z in g.app.openWithFiles]

All expected unit tests pass, as do hand tests of the vim and xemacs
plugins.

EKR