Leo 4.9 b1 for June
Edward K. Ream
mid June.
The only significant item on the to-do list is the new file format. I
plan to propose soon the simplest additions to the file format that
could possibly work.
When the file format works, it will likely take several weeks to fix
all significant bugs.
Please let me know if there are any other items that should appear in
4.9.
Edward
Ville M. Vainio
> The only significant item on the to-do list is the new file format. I
> plan to propose soon the simplest additions to the file format that
> could possibly work.
The best bang for buck in this regard would be not adding new version
number yet, but just ensuring that expansion status and geometry info
is stored in c.db instead of .leo file.
Edward K. Ream
On May 15, 12:28 pm, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> > The only significant item on the to-do list is the new file format. I
> > plan to propose soon the simplest additions to the file format that
> > could possibly work.
>
> The best bang for buck in this regard would be not adding new version
> number yet, but just ensuring that expansion status and geometry info
> is stored in c.db instead of .leo file.
draft of the file spec.
Edward
Edward K. Ream
On May 15, 8:44 am, "Edward K. Ream" <edream...@gmail.com> wrote:
> When the file format works, it will likely take several weeks to fix
> all significant bugs.
>
> Please let me know if there are any other items that should appear in
> 4.9.
bugs on the list. I plan to fix them all before releasing 4.9 b1.
Please let me know if you think any wish-list bugs have higher
priority.
Edward
Edward K. Ream
> I've just reviewed the bug list. There are 12 medium-to-high level
> bugs on the list. I plan to fix them all before releasing 4.9 b1.
bugs list at https://bugs.launchpad.net/leo-editor/+bugs All bugs
scheduled to be fixed have been marked medium priority or higher and
have been targeted to the Leo 4.9b1 milestone.
I have also revised Leo's to-do list in leoPy.leo. The to-do list
contains a first cut at deferring items to Leo 4.10, which will focus
on deprecating Tk.
I plan to clear the "action items list first", then the items on the
"first" list.
This would be a good time for those who are interested to review the
to-do list and bugs list.
Edward
Ville M. Vainio
The only defect that hits me is:
https://bugs.launchpad.net/bugs/760531
{Spurious ""...has been modified outside of Leo. Overwrite this file?"}
The others don't seem to be big issues.Which is a good thing, easily
beta quality already. I'd actually recommend making an alpha release
before june, possibly without fixing any of the reported issues.
Edward K. Ream
> I scanned through the list.
Thanks for doing that.
>
> The only defect that hits me is:
>
> https://bugs.launchpad.net/bugs/760531
>
> {Spurious ""...has been modified outside of Leo. Overwrite this file?"}
Yes, it easily merits it's high severity rating.
Scanning through the to-do list just now, I came across an old item
requesting versioning of nodes. I'd like to do that before the next
release, be it a1 or b1.
> The others don't seem to be big issues.Which is a good thing, easily
> beta quality already. I'd actually recommend making an alpha release
> before June, possibly without fixing any of the reported issues.
I can do that. Why would you like an alpha release?
Edward
Ville M. Vainio
> Scanning through the to-do list just now, I came across an old item
> requesting versioning of nodes. I'd like to do that before the next
> release, be it a1 or b1.
Are you sure? There are several ways to do this, none of which are
"obvious". It's worth bigger discussion.
My current solution is the "git-dump" feature, you can probably search
it in archives.
> I can do that. Why would you like an alpha release?
I'd like to get an "official" debian package out soon, and I don't
like doing it for anonymous releases.
Edward K. Ream
> Are you sure? There are several ways to do this, none of which are
> "obvious". It's worth bigger discussion.
Ok. It's no problem to defer it.
> I'd like to get an "official" debian package out soon, and I don't
> like doing it for anonymous releases.
Alright. I'll fix the high-priority bugs and most or all of the
action items, and then do an alpha release soon after. This would
likely take a week or so.
I would like to fix all bugs before b1 if possible.
Edward
Edward K. Ream
> > Scanning through the to-do list just now, I came across an old item
> > requesting versioning of nodes. I'd like to do that before the next
> > release, be it a1 or b1.
>
> Are you sure? There are several ways to do this, none of which are "obvious".
is worth doing immediately, for the following reasons.
1. This is an important feature. It should have been done years ago.
2. The simplest thing that could possibly work is extremely simple:
just add an undo stack and stack pointer to every vnode. This will
reuse all the code in leoUndo.py. In fact, once the concept works, it
will simplify the undo code considerably. An hour's work should
suffice. I plan to do it today. There will be a switch in leoNodes.py
that will enable per-node undo, so there is no danger if it doesn't
work.
Leo will not read or write the undo information, so the undo
information will not persist across Leo editing sessions. That
doesn't bother me at all.
3. Human factors, not code considerations, will determine how
successful per-node undo is.
> It's worth bigger discussion.
> My current solution is the "git-dump" feature, you can probably search it in archives.
As I understand it, this gives a permanent history for each node.
This would be cute, but it is hardly necessary. We can experiment
with this approach later. But I want per-session, per-node undo now.
Edward
Edward K. Ream
> 2. The simplest thing that could possibly work is extremely simple:
> just add an undo stack and stack pointer to every vnode.
The undo code will do this only as necessary using hasattr and
setattr. Thus, the changes will be completely confined to leoUndo.py.
EKR
Ville M. Vainio
> On May 18, 3:16 pm, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> 2. The simplest thing that could possibly work is extremely simple:
> just add an undo stack and stack pointer to every vnode. This will
Ah, you were talking about per-node UNDO, not versioning.
Nevermind that, you are right, there is obvious way to do it.
Edward K. Ream
> Ah, you were talking about per-node UNDO, not versioning.
>
> Never mind that, you are right, there is obvious way to do it.
Glad you agree. I'm working on it now.
After a false start it looks like there is a way to do it without
changing any existing code in leoUndo.py, except in the top-level
undo/redo methods. New save/restore code called from the undo/redo
methods will set the undoer ivars on entry using v.undo_info and save
the undoer ivars to v.undo_info on exit. v.undo_info will be a
g.bunch, created only as necessary.
The only change to Leo's core outside of leoUndo.py will be a single
call to c.undoer.onSelect(p) in leoTree.select. This is needed to set
up undo menu items. leoTree.select is gui-independent code.
BTW, unit tests will probably be quite effective in catching coding
blunders, so I hope to have everything working today.
Edward
Kent Tenney
> On Thu, May 19, 2011 at 2:48 PM, Edward K. Ream <edre...@gmail.com> wrote:
>> On May 18, 3:16 pm, "Ville M. Vainio" <vivai...@gmail.com> wrote:
>
>> 2. The simplest thing that could possibly work is extremely simple:
>> just add an undo stack and stack pointer to every vnode. This will
>
> Ah, you were talking about per-node UNDO, not versioning.
So versioning remains an elusive feature.
To browse back in forth in time in a node would be
extremely useful and powerful, a huge productivity boost.
Given my workflow, much more useful than regular file based
version control.
Thanks,
Kent
>
> Nevermind that, you are right, there is obvious way to do it.
>
> --
> 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
> To browse back in forth in time in a node would be
> extremely useful and powerful, a huge productivity boost.
That may be, but it is not likely to happen for 4.9.
Edward
Ville M. Vainio
> So versioning remains an elusive feature.
>
> To browse back in forth in time in a node would be
> extremely useful and powerful, a huge productivity boost.
>
> Given my workflow, much more useful than regular file based
> version control.
Luckily this is easy to implement, using git as the backend. Check out
gitarchive.py plugin - all it's missing is an ui to move back/forward
in history. It can be implemented in few hours.
Kent Tenney
Cool!
Notes:
- I had to run "git init" manually
- I had to create ~/.leo/workbook.leo manually (not sure why it's needed)
- git and gitk must be installed
A couple minutes and I seem to have node-wise versioning.
What a delightful use of git, which was designed for project-level
control, less granular than other systems. Here it is providing
super-granular control.
The only knobs I see are git-dump and git-log.
git-dump takes a snapshot, git-log brings up gitk.
I look forward to playing with it.
Thanks,
Kent
Edward K. Ream
> It looks like there is a way to do it without changing any existing code in leoUndo.py.
Rev 4085 contains what *might* be considered working code. Please
read on for details and warnings.
At present the new code is disabled: self.per_node_undo is False. All
unit tests pass, but *only* if the code is disabled.
As expected, the code was straightforward, but also as expected there
are some pretty interesting use-case complications:
1. Many (all?) unit tests fail when per-node undo is in effect. The
reason is simply that the unit tests tacitly assume that undo is
global.
2. This tacit assumption is hardly confined to the unit tests. At
present, it is not clear that per-node undo is going to work as we
might intuitively think it should. In principle, this is not a show
stopper, but in practice it might be tricky to get right.
I'm going to stop work on this for the moment. There are more
important projects to do just now, and I really don't have a good
mental model of what I want to happen.
Edward
Edward K. Ream
On May 19, 9:51 am, "Ville M. Vainio" <vivai...@gmail.com> wrote:
> Luckily [versioning] is easy to implement, using git as the backend. Check out
> in history. It can be implemented in few hours.
Edward
Kent Tenney
I've had time for only a cursory trial, seems the node content gets
written and versioned to the file for that node, what remains is the
machinery to get
text out of the file and back into the node.
Is that right?
(replying to Edward, but asking of Ville)
Indeed, it looks very close to offering node-wise time travel,
although ... not sure if it's actually granular enough.
<alt-x> git-log brings up gitk, where you can browse the versions for the
node, but choosing one also reverts all other changes ...
true?
might a different persistence tool be required, one with file level
granularity ...
... or am I missing the point?
Thanks,
Kent
>
> Edward
Kent Tenney
I've lost track, will there be any changes to the xml?
Will <t> nodes have headlines?
Kent Tenney
> mid June.
>
> The only significant item on the to-do list is the new file format. I
> plan to propose soon the simplest additions to the file format that
> could possibly work.
sorry, ignore prev post please.
too much hurried.
>
> When the file format works, it will likely take several weeks to fix
> all significant bugs.
>
> Please let me know if there are any other items that should appear in
> 4.9.
>
> Edward
>