Autosaving when external file saved

[Ville M. Vainio]

Just an idea:

After discovering sublime edit, I have started using external editor mode more (rclick -> Edit in...). Annoyance there is that once you save in external editor, you still have to go to leo and save there, or your changes will be lost if you close leo without saving.

This can lead to loss of date if you don't routinely agree to save changes when closing Leo. I often don't do this, as I save all the time when I type, and don't want to save accidental changes I might have done to the leo document; I don't usually have time to review changes when closing a document.

Maybe .leo could automatically save the tree if and only if the externally edited node is the only dirty one.

[Matt Wilkie]

I've been bit by this several times too.

It's lead to me relying on pyscripter (my usual external editor these days, has more useful to me command completion than leo) more and more, when I otherwise might just nip out, do a few things and come back.

-matt

[Edward K. Ream]

I agree there is a problem, but I don't believe hacking Leo's save logic is a good idea, for several reasons:

1. There might be several dirty nodes, and you could still lose data (strictly following your suggestion) in that case.

2. The write logic for external files is complex, mainly due to file caching.  I tolerate that complexity because caching is such a big win.  But it would not be easy to do @file AI to discover the special case you mention.

3. Imo, the proper place to handle this problem is in the vim and xemacs plugins.  These plugins are responsible for the interaction with Leo.

Would it work for you if the xemacs and vim plugins automatically saved an external file whenever the plugin caused a node in that file to become dirty?  This would likely solve the problem you mention, although I wouldn't be my life on it.

Your comments, please.

Edward

[Ville M. Vainio]

I wouldn't change the save logic, I'd just execute "save" for the full .leo document when 

- Node has changed in external editor.

- The node that changed is the only dirty node in the whole leo document.

I don't use xemacs/vim plugin, but rather "edit in" in right click menu (contextmenu.py plugin IIRC).

I agree that this is not an elegant proposal, in that it involves a potentially surprising (if useful) special case.

I have to think this a bit more. Perhaps some kind of extra warning in the UI for this scenario would do the trick as well.

--
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.

[Edward K. Ream]

On Thu, Nov 29, 2012 at 6:30 AM, Ville M. Vainio <viva...@gmail.com> wrote:

I wouldn't change the save logic, I'd just execute "save" for the full .leo document when 

- Node has changed in external editor.

- The node that changed is the only dirty node in the whole leo document.

I don't use xemacs/vim plugin, but rather "edit in" in right click menu (contextmenu.py plugin IIRC).

Ok.  In that case the contextmenu plugin should handle this.

I agree that this is not an elegant proposal, in that it involves a potentially surprising (if useful) special case.

I have to think this a bit more. Perhaps some kind of extra warning in the UI for this scenario would do the trick as well.

I agree that if the code is going to do something like this it should issue a clear warning that something has happened.  Otoh, such "clear warnings" tend to get ignored :-)  Indeed, the problem is that you are *already* ignoring such a clear warning!  Adding another warning is not likely to be a big help...

Edward

[Edward K. Ream]

On Thu, Nov 29, 2012 at 6:30 AM, Ville M. Vainio wrote:

I wouldn't change the save logic, I'd just execute "save" for the full .leo document when 

- Node has changed in external editor.

- The node that changed is the only dirty node in the whole leo document.

I don't use xemacs/vim plugin, but rather "edit in" in right click menu (contextmenu.py plugin IIRC).

Ok.  In that case the contextmenu plugin should handle this.

I believe that c.openWith should be able to deal with this problem.  c.openWith creates a temporary external file and updates a node when the user changes that file.  This logic is independent of the editor being used; it works, for example, with Scite, my default external editor.

Clearly, c.openWith (or rather, one of its helpers) is able to update the node and to mark it dirty.  So at the time the node is marked dirty c.openWith has an opportunity to automatically save the file containing the vnode.  c.openWith can issue a colored message to the log pane, but that should be the only "warning" necessary.

My present plan is to write a helper, say c.write_vnode, that will discover the external file (if any) containing the vnode, and immediately write that external file *without* a prompt.  If there is no external file, c.write_vnode could just do an ordinary save of the .leo file and all dirty external files.  Alternatively, c.write_vnode could write only the .leo file (the write-outline-only command) *without* clearing the c.changed bit.

I believe c.write_vnode will solve this problem fairly completely.  What do you think, Amigos?

Edward

[Edward K. Ream]

On Thu, Nov 29, 2012 at 9:17 AM, Edward K. Ream <edre...@gmail.com> wrote:

Clearly, c.openWith (or rather, one of its helpers) is able to update the node and to mark it dirty. 

The "helper" is the idle-time hook,  editnode_on_idle, in contextmenu.py.  You could call this good news, because our experiments with auto-saving can be confined to the contextmenu plugin.  If our experiments end happily we can use the same techniques in the vim and xemacs plugins.

I'll wait awhile for your comments before going ahead with the proposed changes.

Edward

[Edward K. Ream]

On Thu, Nov 29, 2012 at 9:49 AM, Edward K. Ream <edre...@gmail.com> wrote:

I'll wait awhile for your comments before going ahead with the proposed changes.

One thing that must be done in any case is to provide alt-x commands for all context-menu entries.  There is something wrong with having to use the mouse at all...

Edward

[Terry Brown]

On Thu, 29 Nov 2012 10:41:29 -0600
"Edward K. Ream" <edre...@gmail.com> wrote:

> One thing that must be done in any case is to provide alt-x commands for
> all context-menu entries. There is something wrong with having to use the
> mouse at all...

Coincidentally I added the alt-X command 'context-menu-open' a week or
so ago, letting you open the context menu with a keyboard binding so
you can then navigate the menu with the cursor keys.

This is because not all menu entries can have alt-X commands,
specifically the quickMove plugins commands for moving nodes to
pre-defined destinations in other outlines, this is basically a list
selection operation, but being on a sub-sub-menu it's a pain with the
mouse, and easier with the cursor keys.

This is part of my method for handling todo items for different
projects, they are imported from email to one outline, and then I file
them to the relevant project outline's todo node. Which creates a
management problem I just found a surprisingly viable solution for I'll
mention in another post.

Cheers -Terry

[Ville M. Vainio]

"""

My present plan is to write a helper, say c.write_vnode, that will discover the external file (if any) containing the vnode, and immediately write that external file *without* a prompt.  If there is no external file, c.write_vnode could just do an ordinary save of the .leo file and all dirty external files. 

"""

Maybe a relatively safe solution is to do this:

1) My present plan is to write a helper, say c.write_vnode, that will discover the external file (if any) containing the vnode, and immediately write that external file *without* a prompt. 

But not do this:

2) If there is no external file, c.write_vnode could just do an ordinary save of the .leo file and all dirty external files. 

This way, if you "want to be safe", you will create an external @file for the content.

For situation 2), some kind of loud warning is in order, not sure of what kind though. Red g.es?

--

You received this message because you are subscribed to the Google Groups "leo-editor" group.

To view this discussion on the web visit https://groups.google.com/d/msg/leo-editor/-/rS1KLCE1vEMJ.

[Edward K. Ream]

On Tue, Dec 11, 2012 at 5:55 AM, Ville M. Vainio <viva...@gmail.com> wrote:

"""

My present plan is to write a helper, say c.write_vnode, that will discover the external file (if any) containing the vnode, and immediately write that external file *without* a prompt.  If there is no external file, c.write_vnode could just do an ordinary save of the .leo file and all dirty external files. 

"""

Maybe a relatively safe solution is to do this:

1) My present plan is to write a helper, say c.write_vnode, that will discover the external file (if any) containing the vnode, and immediately write that external file *without* a prompt. 

But not do this:

2) If there is no external file, c.write_vnode could just do an ordinary save of the .leo file and all dirty external files. 

This way, if you "want to be safe", you will create an external @file for the content.

For situation 2), some kind of loud warning is in order, not sure of what kind though. Red g.es?

Thanks for this suggestion.  I have a great distrust of all operations containing "if" statements in their explanation.  Somehow, we need a simpler approach, but I don't know what it is.

For now, I'm going to file this under Leo/Bugs.  Feel free to up the heat by posting a real bug report.

Edward