On Sun, Apr 13, 2008 at 06:31:37AM -0700, Edward K. Ream wrote:
It appears that Leo will, relatively soon, move to the unified-node world.
Compatibility with existing code and scripts should be no big deal.
Indeed, unified nodes will contain .v and .t ivars, inited in the ctor
as follows:
A long term solution may be to use pyDispatcher and translate doHook
and registerHook calls to this. It should be possible to do this
transparently and so without effecting the current api or code. Only
code using the hook tables directly would be effected.
Interesting. Are you
Hi Tl
Thanks for the vim enhancements, I like them a lot. Thanks also for
the tips on setting up Vim, the folding trick for leo sentinals was
especially cool.
One small bug I noticed though. You can not now edit the first node of
an @thin file, wheras before you could.
Bob
On Sun, Apr 13, 2008 at 5:23 PM, Terry Brown [EMAIL PROTECTED]
wrote:
find-next-clone is what I'm talking about, how's that done?
Just like it has always been done. That is, p = c.currentPosition() is a
(new) position. We traverse the tree, starting from p, looking for the next
position p2
I could have sworn the trunk was at revision 300 + but now its at
revision 214, what's happening?
Bob
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
leo-editor group.
To post to this group, send email to
Kayvan
I've made some changes which I hope will fix your problem.
They are on the mod_rclick branch which you will need to merge with
your leo to test. I will put them on the trunk soonest but there
appears to be a problem with the trunk at the moment.
Bob
On Apr 13, 9:20 am, Alex Polite [EMAIL PROTECTED] wrote:
I'd like to get up to speed with rClick, are there any howtos/code
examples out there that I can learn from?
I have started a howto as you suggested on the wiki. There is nothing
much there yet but I will try to fix it up over the
On Mon, Apr 14, 2008 at 3:17 AM, derwisch
[EMAIL PROTECTED] wrote:
On Apr 13, 3:31 pm, Edward K. Ream [EMAIL PROTECTED] wrote:
That is for any node n, n.v == n, n.t == n, n.v.t == n. In other
words, if there is only one kind of node, the problem of
distinguishing between vnodes and
On Mon, Apr 14, 2008 at 8:09 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
I think that's about it for now. It truly is thrilling to be able to
simplify and generalize this fundamental code.
Naturally, the first thing I did was merge the tnode and vnode ctors into
the node ctor. It was fun:
On Mon, Apr 14, 2008 at 8:19 AM, Edward K. Ream [EMAIL PROTECTED] wrote:
Nodes will have an .unknownAttributes ivar. But since there is only one
kind of node, there can only be one kind of .unknownAttributes ivar.
It might be possible to associate permanent data with positions. My guess
is
On Mon, Apr 14, 2008 at 1:01 AM, Kayvan A. Sylvan [EMAIL PROTECTED] wrote:
On Sun, Apr 13, 2008 at 06:31:37AM -0700, Edward K. Ream wrote:
It appears that Leo will, relatively soon, move to the unified-node
world.
Compatibility with existing code and scripts should be no big deal.
On Mon, 14 Apr 2008 10:04:30 -0500
Edward K. Ream [EMAIL PROTECTED] wrote:
I think the way to retain the context distinctions you get from
vnodes will be through position dependent rendering of nodes. You
might need to inspect p.stack to work out the context the node is
displayed in. I
On Mon, Apr 14, 2008 at 9:48 AM, Terry Brown [EMAIL PROTECTED]
wrote:
This is great. I was never really a fan of the previous great graph
aha that graphs could be represented in trees, anything can be
represented in trees, or strings, or base64, after all. But now more
complex relationships
In current leo, the data that could be associated with a vnode within
the leo file is the following (taken from leoNodes.py):
# Archived...
clonedBit = 0x01 # True: vnode has clone mark.
# not used = 0x02
expandedBit = 0x04 # True: vnode is expanded.
markedBit = 0x08 # True: vnode is marked
14 matches
Mail list logo
