send in the clones

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

send in the clones

David J Patrick-2
Any experienced outline user will run into situations where a branch of
the outline logically belongs in more than one place. Cloning enables a
user to work any number of conceptual layouts, without actually having
duplicate entries. A cloned branch (or node, or what have you) is the
same thing in more than one location, and the great outliners of olde,
had this feature, and it was good.

will vimoutliner ever be able do that ?
how ?

djp
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Noel Henson
David,

The problem, in vim, is synchronization of the branches. It's easy enough
to copy and paste a branch, but some kind of processing is necessary to 1:
identify cloned branches, 2: keep them synchronized and 3: prevent
recursion. I have done a number of experiments with this but so far what
I've done falls short of what I would consider practical. I will be taking
more looks at how to do it in the future.

Right now my time is being spent on a proper vim patch for colored folded
regions. Yes, a Q&D patch has already been created. And it works; which is
very cool. But it is not implemented in a vim-like manner and for that
reason is very unlikely to be included in future vim releases.

I am almost done with one that is implemented in a way that is compatible
with vim's way of doing things. And instead of just adding individual
highlighting by folded level, the highlighting can be done by content as
well. Eg. all folded text regions can be green while all folded headings
can be colored by the same color as the unfolded headings, or not.

I am doing this by adding a method similar to foldexpr where
a user-provided script can set the fold level. In my case a user-provided
script will tell vim which highlighting ID to use (like BT1 or UT4, or
whatever).

I hope that it is so well integrated into vim (and vim's way of doing
things) that it will become part of the main source code.

Noel

On Wednesday 09 September 2009, David J Patrick wrote:

> Any experienced outline user will run into situations where a branch of
> the outline logically belongs in more than one place. Cloning enables a
> user to work any number of conceptual layouts, without actually having
> duplicate entries. A cloned branch (or node, or what have you) is the
> same thing in more than one location, and the great outliners of olde,
> had this feature, and it was good.
>
> will vimoutliner ever be able do that ?
> how ?
>
> djp
> _______________________________________________
> VimOutliner mailing list
> [hidden email]
> http://www.lists.vimoutliner.org/mailman/listinfo


--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

David J Patrick-2
Noel Henson wrote:
> David,
>
> The problem, in vim, is synchronization of the branches. It's easy enough
> to copy and paste a branch, but some kind of processing is necessary to 1:
> identify cloned branches, 2: keep them synchronized and 3: prevent
> recursion. I have done a number of experiments with this but so far what
> I've done falls short of what I would consider practical. I will be taking
> more looks at how to do it in the future.

OK, I'll preface this with the reminder that I am not a programmer, and
the inner working of vim as as mysterious for me as the crab nebula..

I'm outlining away, and decide that the branch represented by lines
10-15 are a clonable entry. so I select the region (visually, or by
range, and hit the magic "clone" key. This sends those line NUMBERS into
the magic clone buffer. Then, then I hit the magic clone-paste key, the
line NUMBERS are inserted.. again..

so that you might see lines

50
51
10
11
12
13
14
15
52
53, etc

I can't imagine what kniptions vim would throw, but this is how I
imagine it.
>
> Right now my time is being spent on a proper vim patch for colored folded
> regions. Yes, a Q&D patch has already been created. And it works; which is
> very cool. But it is not implemented in a vim-like manner and for that
> reason is very unlikely to be included in future vim releases.
that sounds very neat, in an un-vimoutliner-like way

>
> I hope that it is so well integrated into vim (and vim's way of doing
> things) that it will become part of the main source code.
wow

djp
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Steve Litt
In reply to this post by David J Patrick-2
On Wednesday 09 September 2009 22:04:03 David J Patrick wrote:
> Any experienced outline user will run into situations where a branch of
> the outline logically belongs in more than one place. Cloning enables a
> user to work any number of conceptual layouts, without actually having
> duplicate entries. A cloned branch (or node, or what have you) is the
> same thing in more than one location, and the great outliners of olde,
> had this feature, and it was good.
>
> will vimoutliner ever be able do that ?
> how ?

Body text was easy. So was interoutline linking once Dillon told me about
ctags. Being an ex Grandviewer, I thought a lot about cloning in the old days.
I couldn't even get to first base. It's a REALLY tough problem if you're using
the Vim engine and only the Vim engine.

I think cloning is going to require each copy of the cloned subtree to have
meta information. Then some event will be necessary to reconcile the all the
copies. I cannot think of an easy way to automatically do it, and asking the
user to hit some sort of command for reconcilliation is kind of iffy.

We need to decide whether a set of clones is like hard links, where each is as
good as the other, or symbolic links, where there's a master and a bunch of
subservient links. Personally I'd vote for the hard link type.

Here's one copy _clone_221_
        Subline 1
        Subline 2
Here's one copy _clone_221_
        Subline 1
        Subline 2

If you change anything in one of the trees, it changes in the other.

I mean, if U guys are willing to accept the user having to manually call for
reconcilliation after changing a copy of the clone, and if you don't mind the
necessity of the _clone_398_ metadata, then heck, it's pretty much done. If
nothing else, I could write a perlscript to do it in a heartbeat. I could even
use Python if you guys like that better :-)

Hey Noel -- is there any way we could have some sort of asyncronous thread
going some place that signals Vim every five seconds and tells it to reconcile
if necessary? Is there any practical way that VO could detect when you leave a
certain subtree?

Thanks

SteveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Noel Henson
On Wednesday 09 September 2009, Steve Litt wrote:

> On Wednesday 09 September 2009 22:04:03 David J Patrick wrote:
> > Any experienced outline user will run into situations where a branch
> > of the outline logically belongs in more than one place. Cloning
> > enables a user to work any number of conceptual layouts, without
> > actually having duplicate entries. A cloned branch (or node, or what
> > have you) is the same thing in more than one location, and the great
> > outliners of olde, had this feature, and it was good.
> >
> > will vimoutliner ever be able do that ?
> > how ?
>
> Body text was easy. So was interoutline linking once Dillon told me
> about ctags. Being an ex Grandviewer, I thought a lot about cloning in
> the old days. I couldn't even get to first base. It's a REALLY tough
> problem if you're using the Vim engine and only the Vim engine.
>
> I think cloning is going to require each copy of the cloned subtree to
> have meta information. Then some event will be necessary to reconcile
> the all the copies. I cannot think of an easy way to automatically do
> it, and asking the user to hit some sort of command for reconcilliation
> is kind of iffy.
>
> We need to decide whether a set of clones is like hard links, where each
> is as good as the other, or symbolic links, where there's a master and a
> bunch of subservient links. Personally I'd vote for the hard link type.
>
> Here's one copy _clone_221_
> Subline 1
> Subline 2
> Here's one copy _clone_221_
> Subline 1
> Subline 2
>
> If you change anything in one of the trees, it changes in the other.
>
> I mean, if U guys are willing to accept the user having to manually call
> for reconcilliation after changing a copy of the clone, and if you don't
> mind the necessity of the _clone_398_ metadata, then heck, it's pretty
> much done. If nothing else, I could write a perlscript to do it in a
> heartbeat. I could even use Python if you guys like that better :-)
>
> Hey Noel -- is there any way we could have some sort of asyncronous
> thread going some place that signals Vim every five seconds and tells it
> to reconcile if necessary? Is there any practical way that VO could
> detect when you leave a certain subtree?
>

Steve,

The auto-command method was what I was experimenting with. It was poor at
best and kept interrupting further edits. AND it was SLOW. But you're
correct; the meta-information is necessary.  I was hoping that Vince
Negri's conceal patch was going to make it into the main sources so we
could hide the meta information from view and edits. But we can open a new
thread to discuss ways of doing cloning once I finish my current VO
modifications.  We can open up a new thread now but I won't be able to
devote my full attention to it. My head is filled with vim sources at the
moment for better folded-item highlighting.

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Herbert Sitz
In reply to this post by Noel Henson
Noel Henson wrote
I am doing this by adding a method similar to foldexpr where
a user-provided script can set the fold level. In my case a user-provided
script will tell vim which highlighting ID to use (like BT1 or UT4, or
whatever).

I hope that it is so well integrated into vim (and vim's way of doing
things) that it will become part of the main source code.

Noel
Noel --

Not sure, but I'm assuming you're talking about the ugly hack I did as the one that was non-Vim-Like.  Very true.

I was going to take another look and try to do it in a cleaner way that sounds like it might be similar to what you're now doing.  Maybe not, I'm not quite clear on what you're doing.   I was dealing only with changing the highlighting of the folded text lines depending on level (since main problem was that they all used same highlight style, regardless of level).  Right now there is a callback that Vim can do to a user-defined function to get the fold text, which is used by VO.  What I wanted to do was create a new Vim variable that would hold a highlight style.  Then in the foldtext function used by VO the value of that variable would be set each time the foldtext function was called to be a highlight value appropriate for the folded line being written.

I expect it wouldn't be hard to fit that into the Vim code for someone who knows what they're doing.   Not sure how similar that is to the method you're actually implementing.

-- Herb
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Noel Henson
On Wednesday 09 September 2009, hsitz wrote:

> Noel Henson wrote:
> > I am doing this by adding a method similar to foldexpr where
> > a user-provided script can set the fold level. In my case a
> > user-provided script will tell vim which highlighting ID to use (like
> > BT1 or UT4, or whatever).
> >
> > I hope that it is so well integrated into vim (and vim's way of doing
> > things) that it will become part of the main source code.
> >
> > Noel
>
> Noel --
>
> Not sure, but I'm assuming you're talking about the ugly hack I did as
> the one that was non-Vim-Like.  Very true.

I was. And there was no disrespect intended. It did give me the motivation
to take a good look at it myself.

>
> I was going to take another look and try to do it in a cleaner way that
> sounds like it might be similar to what you're now doing.  Maybe not,
> I'm not quite clear on what you're doing.   I was dealing only with
> changing the highlighting of the folded text lines depending on level
> (since main problem was that they all used same highlight style,
> regardless of level).  Right now there is a callback that Vim can do to
> a user-defined function to get the fold text, which is used by VO.  What
> I wanted to do was create a new Vim variable that would hold a highlight
> style.  Then in the foldtext function used by VO the value of that
> variable would be set each time the foldtext function was called to be a
> highlight value appropriate for the folded line being written.
>
> I expect it wouldn't be hard to fit that into the Vim code for someone
> who knows what they're doing.   Not sure how similar that is to the
> method you're actually implementing.
>
> -- Herb

I looked at what you did; AND it works. That's further than I had gotten
before. I am impressed. The problem with what you did is that you added the
settings in the table of constants for predefined highlighting primitives.  
Then you added some hard-coding in the form of a case statement. It would
work for us, but it does not seem to be the vim way of doing things.

What I am adding is a user setting similar to foldexpr and foldtext. It is
called foldhighlight or fdh. It is set to either the default function
foldhidef() that returns the original vim constant HLF_FL to the routines
where HLF_FL is needed. IF the user-supplied function is specified, that
function will return a highlight ID (hlID) instead. This ID is an index
into the dynamic table of highlight specifications created with the hl
command in a syntax or, more appropriately, a colorscheme file.

A user function might look like this for simple level-specific highlights:

function MyFoldHighlight(level)
        let retval = hlID("Folded".level)
        if retval = -1
                retval = foldhidef()
        endif
        return retval
endf

then a simple:

setlocal foldhighlight=MyFoldLevel(v:foldlevel)

The colorscheme file would have entries like

hi Folded0 guifg=darkgray ctermfg=gray
hi Folded1 guifg=darkblue ctermfg=blue
etc.

The end goal is not only to have a function that allows us to set the text
of a fold (when folded), it would allow a function to set the highlighting.

I hope the above is understandable.

How does the implementation sound?

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Herbert Sitz
Noel Henson wrote
On Wednesday 09 September 2009, hsitz wrote:
> Noel --
>
> Not sure, but I'm assuming you're talking about the ugly hack I did as
> the one that was non-Vim-Like.  Very true.

I was. And there was no disrespect intended. It did give me the motivation
to take a good look at it myself.
Oh, yes, no disrespect taken.  It is definitely an ugly hack.  Not really that messy, but the hardcoding is not a nice way of doing things.  I wouldn't let it into Vim code base even if I were the maintainer myself.

Noel Henson wrote
What I am adding is a user setting similar to foldexpr and foldtext. It is
called foldhighlight or fdh. It is set to either the default function
foldhidef() that returns the original vim constant HLF_FL to the routines
where HLF_FL is needed. IF the user-supplied function is specified, that
function will return a highlight ID (hlID) instead.

[. . .]
I hope the above is understandable.

How does the implementation sound?

Noel
Noel -- I think I get it, and it looks like it will work.

I just tried something like the method I was thinking of in previous post above, which I was thinking would be simpler:  just create a variable that holds a highlight style and change value of variable every time MyFoldText is called.  It struck me that I'm not sure how different that is from simply changing the Folded style itself each time MyFoldText() is called.

So I just tried that.  That works only very partially, because I think the text is retrieved using MyFoldText only once, when each region is collapsed.  The actual folded line is redrawn very often on the screen, however, and each redraw seems to use whatever current value of Folded highlight is (with no chance to dynamically change because MyFoldText() isn't getting re-called).

This makes me wonder whether there may be speed problems with having a user-defined function to get dynamically changing highlight info.  MyFoldText doesn't really slow things down at all, because (I think) it's very rarely called.  I'm not clear on how often the highlight info is accessed, but I'm guessing it may be getting called way, way more often than the foldtext or foldexpr functions.  I have no idea whether frequency of calling will be great enough for a lag to be perceptible to a user.  Do you?  Maybe it won't be an issue at all.

The dynamically changing highlight function sure looks like a nifty solution, though.  Definitely worth a go.

-- Herb
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Noel Henson
On Wednesday 09 September 2009, hsitz wrote:

> Noel Henson wrote:
> > On Wednesday 09 September 2009, hsitz wrote:
> >> Noel --
> >>
> >> Not sure, but I'm assuming you're talking about the ugly hack I did
> >> as the one that was non-Vim-Like.  Very true.
> >
> > I was. And there was no disrespect intended. It did give me the
> > motivation to take a good look at it myself.
>
> Oh, yes, no disrespect taken.  It is definitely an ugly hack.  Not
> really that messy, but the hardcoding is not a nice way of doing things.
>  I wouldn't let it into Vim code base even if I were the maintainer
> myself.
>
> Noel Henson wrote:
> > What I am adding is a user setting similar to foldexpr and foldtext.
> > It is called foldhighlight or fdh. It is set to either the default
> > function foldhidef() that returns the original vim constant HLF_FL to
> > the routines where HLF_FL is needed. IF the user-supplied function is
> > specified, that function will return a highlight ID (hlID) instead.
> >
> > [. . .]
> > I hope the above is understandable.
> >
> > How does the implementation sound?
> >
> > Noel
>
> Noel -- I think I get it, and it looks like it will work.

It seems to be so far. I'm working out some casting issues and sometimes
I get the wrong line number.

>
> I just tried something like the method I was thinking of in previous
> post above, which I was thinking would be simpler:  just create a
> variable that holds a highlight style and change value of variable every
> time MyFoldText is called.  It struck me that I'm not sure how different
> that is from simply changing the Folded style itself each time
> MyFoldText() is called.
>
> So I just tried that.  That works only very partially, because I think
> the text is retrieved using MyFoldText only once, when each region is
> collapsed. The actual folded line is redrawn very often on the screen,
> however, and each redraw seems to use whatever current value of Folded
> highlight is (with no chance to dynamically change because MyFoldText()
> isn't getting re-called).
>
> This makes me wonder whether there may be speed problems with having a
> user-defined function to get dynamically changing highlight info.
> MyFoldText doesn't really slow things down at all, because (I think)
> it's very rarely called.  I'm not clear on how often the highlight info
> is accessed, but I'm guessing it may be getting called way, way more
> often than the foldtext or foldexpr functions.  I have no idea whether
> frequency of calling will be great enough for a lag to be perceptible to
> a user.  Do you? Maybe it won't be an issue at all.
>

The problem with setting a variable is that creating the display buffer
before displaying seems to be a multi-pass operation. The variable would
contain information that could easily be stale or out of context for
a particular line. I tried this by modifying the highlight table (hi
commands) on-the-fly for each folded fold.

Since the function is only called on folded lines and we are doing that
already by specifying the fold level for each line and the fold text for
each folded line, I don't think there would be any performance issues.

> The dynamically changing highlight function sure looks like a nifty
> solution, though.  Definitely worth a go.
>
> -- Herb

I'll let you know how it all works out.

Noel
--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.

_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: send in the clones

Steve Litt
In reply to this post by Noel Henson
On Thursday 10 September 2009 00:07:50 Noel Henson wrote:

> On Wednesday 09 September 2009, Steve Litt wrote:
> > On Wednesday 09 September 2009 22:04:03 David J Patrick wrote:
> > > Any experienced outline user will run into situations where a branch
> > > of the outline logically belongs in more than one place. Cloning
> > > enables a user to work any number of conceptual layouts, without
> > > actually having duplicate entries. A cloned branch (or node, or what
> > > have you) is the same thing in more than one location, and the great
> > > outliners of olde, had this feature, and it was good.
> > >
> > > will vimoutliner ever be able do that ?
> > > how ?
> >
> > Body text was easy. So was interoutline linking once Dillon told me
> > about ctags. Being an ex Grandviewer, I thought a lot about cloning in
> > the old days. I couldn't even get to first base. It's a REALLY tough
> > problem if you're using the Vim engine and only the Vim engine.
> >
> > I think cloning is going to require each copy of the cloned subtree to
> > have meta information. Then some event will be necessary to reconcile
> > the all the copies. I cannot think of an easy way to automatically do
> > it, and asking the user to hit some sort of command for reconcilliation
> > is kind of iffy.
> >
> > We need to decide whether a set of clones is like hard links, where each
> > is as good as the other, or symbolic links, where there's a master and a
> > bunch of subservient links. Personally I'd vote for the hard link type.
> >
> > Here's one copy _clone_221_
> > Subline 1
> > Subline 2
> > Here's one copy _clone_221_
> > Subline 1
> > Subline 2
> >
> > If you change anything in one of the trees, it changes in the other.
> >
> > I mean, if U guys are willing to accept the user having to manually call
> > for reconcilliation after changing a copy of the clone, and if you don't
> > mind the necessity of the _clone_398_ metadata, then heck, it's pretty
> > much done. If nothing else, I could write a perlscript to do it in a
> > heartbeat. I could even use Python if you guys like that better :-)
> >
> > Hey Noel -- is there any way we could have some sort of asyncronous
> > thread going some place that signals Vim every five seconds and tells it
> > to reconcile if necessary? Is there any practical way that VO could
> > detect when you leave a certain subtree?
>
> Steve,
>
> The auto-command method was what I was experimenting with. It was poor at
> best and kept interrupting further edits. AND it was SLOW.

Maybe we can just have a user initiated "update" command. It was good enough
for Lotus and Wordstar, maybe it's good enough for us, at least for now.

> But you're
> correct; the meta-information is necessary.  I was hoping that Vince
> Negri's conceal patch was going to make it into the main sources so we
> could hide the meta information from view and edits.

I'd consider leaving the meta information visible so the user doesn't
accidentally forget what's clone and what's not, and which things are clones
of which. Something like _clone_####_ is unobtrusive, and can easily be
filtered out by any output script if desired.

StevveT

Steve Litt
Recession Relief Package
http://www.recession-relief.US
Twitter: http://www.twitter.com/stevelitt


_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo