On Mon, 28 Apr 2014 06:43:45 -0500
Kent Tenney <kten...@gmail.com> wrote:
> Standard version control is time-based, my workmethods seem
> to want space-based versioning, IE: the variations I'm considering
> are next to each other, not before and after.
>
> What would suit me would be a tabbed editor pane. A node would
> offer the capability to create new versions of it's headline and body.
> I would select one to be 'active', the inactive versions could live
> in the UA, only the active one would be visible and written to the
> @auto file on save. Selecting another tab would trigger an
> active/inactive swap.
Adding UI elements makes this into a non-trivial task. What would be
quick and easy would be some new commands for keys / buttons:
body-versions-add
Add the current body text as a new entry in the nodes list of
body texts with the name "YYYY-MM-DD HH:MM:SS"
body-versions-commit
Save the current body text as the text for the currently
displayed version
body-versions-revert
Replace the current body text with the text for the currently
displayed version
body-versions-delete
Delete the body version currently being viewed
body-versions-rotate
Store the current displayed body version and switch to the next one
in the list, wrapping around if necessary
body-versions-list
Show list of body versions for node
body-versions-name
Change name of current body version
I guess these aren't versions in a temporal sense, just a way of managing
named alternate body texts. And if you just keep using `body-versions-add`,
then it does act as versioning.
Perhaps one way to get really cheap, effort wise, UI integration would
be to have these commands add a button which displays the current body
version name.
What might the v.u entry look like?
'body_vers': {
'current': 'red option',
'version': {
'red option': <str of body text>,
'2014-04-28 09:45:32': <str of body text>,
}
}
I think I would probably find a way to make subnodes work for me,
rather than this approach, but it does sound useful.
Cheers -Terry
> It seems this would be very useful, leveraging Leo's presentation
> capabilities and the utility of the UA sidecar available to each node.
>
> Would anyone else find this interesting?
>
> Thanks,
> Kent
>
--
You received this message because you are subscribed to the Google Groups
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to leo-editor+unsubscr...@googlegroups.com.
To post to this group, send email to leo-editor@googlegroups.com.
Visit this group at http://groups.google.com/group/leo-editor.
For more options, visit https://groups.google.com/d/optout.
