shadow directory name...
Terry Brown
change to something like .leo_shadow? That would be my preference. I
don't think there's a need to handle LeoShadow directories from before
the merge...
Thinking of leo_, if the foreground / background color API uses uAs,
would/should the uAs use the reserved "leo_<something>" namespace?
Cheers -Terry
Edward K. Ream
So when @shadow merges into the trunk will the name of the shadow dir
change to something like .leo_shadow? That would be my preference.
I have no objection to making .leo_shadow the default.
I don't think there's a need to handle LeoShadow directories from before
the merge...
I'm not sure what you mean by this. It seems to me that shadow directories would typically not be committed to bzr.
Thinking of leo_, if the foreground / background color API uses uAs,
would/should the uAs use the reserved "leo_<something>" namespace?
I don't know. I'll keep this question in mind as I add color capabilities.
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> > I don't think there's a need to handle LeoShadow directories from
> > before
> > the merge...
>
> I'm not sure what you mean by this. It seems to me that shadow
> directories would typically not be committed to bzr.
Heh. Well, all I meant was, I don't think you need to worry about
handling the infinitesimal number of legacy cases where people are
already using @shadow, if you change the default to .leo_shadow, after
the merge of the shadow branch into the trunk.
So, a trivial thing.
But unintentionally raising an interesting point about committing
<leo_shadow_directories> to VCS. In a shared VCS you probably wouldn't
want to do that. But then reverting to an earlier version, you won't
have the layout you'd made for the file in the @shadow tree at that
time any more. I guess the same thing could apply to the .leo file
itself, if that's not in the shared VCS either.
I put .leo files and have just started putting LeoShadow files in VCS,
but then I work by myself mostly.
Probably the closest to a solution would be to symlink your .leo file
and .leo_shadow dir to some other dir where you have your own VCS on
them. And arrange for bzr to commit there also whenever you commit on
the shared repo.
Anyway, I'm really liking shadow for the control it gives you over when
to move code to a child node, unlike @auto. For a piece of code like
this:
class TableReader(object):
"""iterateor for lines in a table (lists of field values)
subclasses must register() themselves"""
_subclasses = [] # lists subclasses,
@classmethod
def register(cls, other):
"""register a subclass or anything that implements this
signature"""
cls._subclasses.append(other)
def __init__(self, URI):
"""looks for subclass to delegate to, sets __class__
appropriately"""
self.URI=URI
for i in self._subclasses:
if i._handles(self.URI):
self.__class__ = i
i.__init__(self, self.URI)
I don't want all those pieces on separate nodes, they're small and make
more sense together.
Cheers -Terry
Edward K. Ream
Heh. Well, all I meant was, I don't think you need to worry about
On Mon, 28 Jul 2008 15:04:36 -0500
"Edward K. Ream" <edre...@gmail.com> wrote:
> > I don't think there's a need to handle LeoShadow directories from
> > before
> > the merge...
>
> I'm not sure what you mean by this. It seems to me that shadow
> directories would typically not be committed to bzr.
handling the infinitesimal number of legacy cases where people are
already using @shadow, if you change the default to .leo_shadow, after
the merge of the shadow branch into the trunk.
So, a trivial thing.
There could be problems, but all such problems can be resolved by copying the setting from
@settings-->Plugins-->shadow plugin-->@string shadow_subdir = LeoShadow
to myLeoSettings.leo
But unintentionally raising an interesting point about committing
<leo_shadow_directories> to VCS. In a shared VCS you probably wouldn't
want to do that.
I agree. That was what I was trying to say.
But then reverting to an earlier version, you won't have the layout you'd made for the file in the @shadow tree at that time any more. I guess the same thing could apply to the .leo file
itself, if that's not in the shared VCS either.
Yes. Private files really are private, and give a private view of the data.
As you mentioned later, moving or inserting blocks of code will work, but will cause the moved/inserted code not to be split into nodes, because the nodes exist only in private views.
For this reason, @shadow would typically be used in situations where not everyone uses Leo. If Leo were a company-wide standard, @thin would work better. Still, @shadow promises to be a big help for those that want to use Leo when Leo is not the standard.
Anyway, I'm really liking shadow for the control it gives you over when
to move code to a child node, unlike @auto. [snip]
I don't want all those pieces on separate nodes, they're small and make
more sense together.
Interesting. I gather from your comments that @shadow is working well for you. Are there any other rough edges that you are seeing?
Edward
Terry Brown
"Edward K. Ream" <edre...@gmail.com> wrote:
> For this reason, @shadow would typically be used in situations where
> not everyone uses Leo. If Leo were a company-wide standard, @thin
> would work better. Still, @shadow promises to be a big help for
> those that want to use Leo when Leo is not the standard.
I'm not so sure. Even in a all Leo environment, it's nice to be able
to diff your source without seeing #@ stuff in it. For me I'd rather
have #@ free source and the limitations of @auto, but @shadow is the
best of both worlds.
> Interesting. I gather from your comments that @shadow is working
> well for you. Are there any other rough edges that you are seeing?
Well I'm not really testing the external editing part much, but I
haven't seen any problems. I'll speak up if I do. yarko was having
problems.
Cheers -Terry
Terry Brown
A very minor thing, but I had a @thin node, converted it to @shadow(*)
and when I reloaded the file a node was marked as if to indicate
external change, but there shouldn't have been any external change.
(*) another case where @shadow is preferable to @thin, for editing html
(templates), where you don't really want you're web pages full of
<!--@-node:tbrown.20071205122025.1:head--> type comments.
Cheers -Terry
Edward K. Ream
On Tue, 29 Jul 2008 05:40:35 -0500
> I gather from your comments that @shadow is working well forA very minor thing, but I had a @thin node, converted it to @shadow
> you. Are there any other rough edges that you are seeing?
and when I reloaded the file a node was marked as if to indicate
external change, but there shouldn't have been any external change.
Hmm. I don't think this is a problem, but there are a variety of special cases involved when the @shadow tree is first created.
Suppose you simply change @thin to @shadow and save the .leo file. Presumably the new @shadow file will be dirty, so both the public and private versions of the file will be written. The public file should overwrite the old derived file (containing sentinels). So yes, I agree that you might not expect to get any change warnings when you reload Leo.
But you may have created the shadow file in other ways, which might create different results. Unless you can describe exactly what you did, I can't do much...This is the weakness of @shadow: it's cool but it's a bit tricky at first.
Edward