Always-Folded Method

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

Always-Folded Method

Noel Henson
Everyone,

After reviewing Hsitz' technique for always-folded blocks, like body text
and other blocks, I have a suggestion to make this type of behavior easier
to implement and much faster to process. I learned this technique from
implementing the new hoisting method (which still needs a bit of work).

The basic idea is to change the fold levels of always-folded blocks to be
much deeper than one would expect. That way the normal zo, zc and company
and ,,1 through ,,0 will work as expected with no extra processing to go
back and re-fold always folded blocks.

Basically the implementation would be as follows.

Add variables for blocks that can be always folded:

        let vo_always_fold_text=1
        let vo_always_fold_preftext=1
        let vo_always_fold_tables=1
        let vo_always_fold_usertext=1
        let vo_always_fold_userpreftext=1

Modify ,,0 to set foldlevel to foldnestmax - 1

Modify MyFoldLevel to set any block that has it flag set to foldnestmax; so
it will always be folded. When vim updates the buffer, this function will
cause everything with a fold level of foldnextmax to be constantly folded.

This will not change anything but vim's understanding of the level of the
fold. Even always-folded blocks can be opened with zo, zc, etc.

Setting and clearing of the above flags can be done manually with 'let'
commands, via the vim menu in GUI mode, and via user-defined key mappings.

This method will be much faster than calling and recalling scripts to
refold blocks that are to be 'always folded'.

Thoughts?

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: Always-Folded Method

David J Patrick-2
Noel Henson wrote:
> Everyone,
>
> After reviewing Hsitz' technique for always-folded blocks, like body text
> and other blocks, I have a suggestion to make this type of behavior easier
> to implement and much faster to process. I learned this technique from
> implementing the new hoisting method (which still needs a bit of work).
oh, yes, please ! I have other uses for that method, too !

>
> The basic idea is to change the fold levels of always-folded blocks to be
> much deeper than one would expect. That way the normal zo, zc and company
> and ,,1 through ,,0 will work as expected with no extra processing to go
> back and re-fold always folded blocks.
>
> Basically the implementation would be as follows.
>
> Add variables for blocks that can be always folded:
>
> let vo_always_fold_text=1
> let vo_always_fold_preftext=1
> let vo_always_fold_tables=1
> let vo_always_fold_usertext=1
> let vo_always_fold_userpreftext=1
>
> Modify ,,0 to set foldlevel to foldnestmax - 1
>
> Modify MyFoldLevel to set any block that has it flag set to foldnestmax; so
> it will always be folded. When vim updates the buffer, this function will
> cause everything with a fold level of foldnextmax to be constantly folded.
>
> This will not change anything but vim's understanding of the level of the
> fold. Even always-folded blocks can be opened with zo, zc, etc.
>
> Setting and clearing of the above flags can be done manually with 'let'
> commands, via the vim menu in GUI mode, and via user-defined key mappings.
>
> This method will be much faster than calling and recalling scripts to
> refold blocks that are to be 'always folded'.
>
> Thoughts?
well worth the wait !
this looks absolutely great, madly customizable and minimally intrusive!

a most logical implementation, Captain.

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

Re: Always-Folded Method

Herbert Sitz
In reply to this post by Noel Henson
Noel Henson wrote
Everyone,

After reviewing Hsitz' technique for always-folded blocks, like body text
and other blocks, I have a suggestion to make this type of behavior easier
to implement and much faster to process. I learned this technique from
implementing the new hoisting method (which still needs a bit of work).

The basic idea is to change the fold levels of always-folded blocks to be
much deeper than one would expect. That way the normal zo, zc and company
and ,,1 through ,,0 will work as expected with no extra processing to go
back and re-fold always folded blocks.
[. . . ]
Noel --- Yeah, that sounds like a good idea.  The way I reimplemented the text-hiding folding is pretty similar, except I've made the the text folds only one level higher than expected.  I experimented quickly with making them even higher, but didn't do it because (1) unless I'm missing something it does require overriding the default zc and zo behaviors and (2) it already seemed plenty speedy.

Because each zc and zo moves the level up or down by only one level, zc and zo have to be modified to automatically do appropriate number of zc's or zo's when issued for a text level to bring it down from or up to the level of FoldNestMax.  You don't necessarily see this visually if you don't  have level-independent fold highlighting, but you notice it quickly because you find that sometimes you need to issue multiple zc's or zo's (or just manually inspect fold levels using the :echo MyFoldLevel(line(".")) command).  Not sure about the many other less frequently used built-in fold related commands, whether they will automatically make use of overridden 'zc' and 'zo' functions or whether they'll need to do be overridden themselves.  In any case, seems like it makes sense doing.  I have it working but haven't overridden zc and zo yet, which should be fairly straightforward.  I don't think it messes with any of the other stuff I did, which is still necessary because there are lots of times when you want to manipulate folds automatically on a non-global basis (e.g., per node tree).  Also, in case anyone is worried, seems easy enough to include alternative code to still allow use the default current behavior of ',,[1234567890]' (i.e., the version that doesn't hide text) under the same or a different keymapping.

In my version I also have two different levels of text blocks that can occur under each heading.   In scheme you describe, the "metadata" text block (if present) would always be at FoldNestMax level when folded, and the regular text blocks would be FoldNestMax - 1.  This allows you to easily unfold all the regular text blocks while leaving your metadata text blocks out of sight.

-- Herb


Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

David J Patrick-2
hsitz wrote:

> In my version I also have two different levels of text blocks that can occur
> under each heading.   In scheme you describe, the "metadata" text block (if
> present) would always be at FoldNestMax level when folded, and the regular
> text blocks would be FoldNestMax - 1.  This allows you to easily unfold all
> the regular text blocks while leaving your metadata text blocks out of
> sight.

Speaking as someone who has adopted that metadata format (in kind of a
big way) I like the differentiation there.
djp
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

Noel Henson
In reply to this post by Herbert Sitz
On Saturday 10 October 2009, hsitz wrote:

> Noel Henson wrote:
> > Everyone,
> >
> > After reviewing Hsitz' technique for always-folded blocks, like body
> > text and other blocks, I have a suggestion to make this type of
> > behavior easier to implement and much faster to process. I learned
> > this technique from implementing the new hoisting method (which still
> > needs a bit of work).
> >
> > The basic idea is to change the fold levels of always-folded blocks to
> > be much deeper than one would expect. That way the normal zo, zc and
> > company and ,,1 through ,,0 will work as expected with no extra
> > processing to go back and re-fold always folded blocks.
> > [. . . ]
>
> Noel --- Yeah, that sounds like a good idea.  The way I reimplemented
> the text-hiding folding is pretty similar, except I've made the the text
> folds only one level higher than expected.  I experimented quickly with
> making them even higher, but didn't do it because (1) unless I'm missing
> something it does require overriding the default zc and zo behaviors and
> (2) it already seemed plenty speedy.

I believe that we need to experiment a bit more. Body text is particularly
sticky because of historic reasons. I believe that body text should always
be indented to the same level as the child of a heading:

Text
    : blah blah blah
    : blah blah blah

Others believe that body text should be at the same indent level as the
heading.

Text
: blah blah blah
: blah blah blah

This make the syntax highlighting and other processing more difficult.  
Increasing the level by 1 would work for the first case, but not the
second; or vice-versa.

>
> Because each zc and zo moves the level up or down by only one level, zc
> and zo have to be modified to automatically do appropriate number of
> zc's or zo's when issued for a text level to bring it down from or up to
> the level of FoldNestMax.  You don't necessarily see this visually if
> you don't  have level-independent fold highlighting, but you notice it
> quickly because you find that sometimes you need to issue multiple zc's
> or zo's (or just manually inspect fold levels using the :echo
> MyFoldLevel(line(".")) command).  Not sure about the many other less
> frequently used built-in fold related commands, whether they will
> automatically make use of overridden 'zc' and 'zo' functions or whether
> they'll need to do be overridden themselves.  In any case, seems like it
> makes sense doing.  I have it working but haven't overridden zc and zo
> yet, which should be fairly straightforward.  I don't think it messes
> with any of the other stuff I did, which is still necessary because
> there are lots of times when you want to manipulate folds automatically
> on a non-global basis (e.g., per node tree). Also, in case anyone is
> worried, seems easy enough to include alternative code to still allow
> use the default current behavior of ',,[1234567890]' (i.e., the version
> that doesn't hide text) under the same or a different keymapping.
>
> In my version I also have two different levels of text blocks that can
> occur under each heading.   In scheme you describe, the "metadata" text
> block (if present) would always be at FoldNestMax level when folded, and
> the regular text blocks would be FoldNestMax - 1.  This allows you to
> easily unfold all the regular text blocks while leaving your metadata
> text blocks out of sight.
>
> -- Herb

I believe you get the idea. But that last paragraph may be a bit wrong.  
Using flags, all 'always-folded' regions would have the level of
foldnextmax.

I'll try to bang something out today for you, and anyone else who wants, to
test.

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: Always-Folded Method

Herbert Sitz
Noel Henson wrote
On Saturday 10 October 2009, hsitz wrote:
> Noel --- Yeah, that sounds like a good idea.  The way I reimplemented
> the text-hiding folding is pretty similar, except I've made the the text
> folds only one level higher than expected.  I experimented quickly with
> making them even higher, but didn't do it because (1) unless I'm missing
> something it does require overriding the default zc and zo behaviors and
> (2) it already seemed plenty speedy.

I believe that we need to experiment a bit more. Body text is particularly
sticky because of historic reasons. I believe that body text should always
be indented to the same level as the child of a heading:

Text
    : blah blah blah
    : blah blah blah

Others believe that body text should be at the same indent level as the
heading.

Text
: blah blah blah
: blah blah blah

This make the syntax highlighting and other processing more difficult.  
Increasing the level by 1 would work for the first case, but not the
second; or vice-versa.
The folding method I'm using works with text at any level of physical indent, since once you get started with this you see that the indent level you assign to text does not have to be tied to physical indent, whether folded or unfolded.  No problems with syntax highlighting.  (At present I think I have some non-folding related functions written to depend on text being physically indented one level from heading, but that's completely unnecessary and I've ben meaning to factor that out.)

Noel Henson wrote
On Saturday 10 October 2009, hsitz wrote:
> In my version I also have two different levels of text blocks that can
> occur under each heading.  

I believe you get the idea. But that . . . may be a bit wrong.  
Using flags, all 'always-folded' regions would have the level of
foldnextmax.
I realize you're making all folded text have level of foldnestmax.  But think through what happens if you have two different "kinds" of text.  One kind is regular text and one kind is metadata text.  It is very nice to have the ability to see all the regular text blocks (whether prepended by :, >, <, /, or | ) and at the same time have blocks of "metadata" text that remain hidden.  To do this you just revise your idea and have metadata text folded to level of foldnestmax and regular data folded to one level less, to foldnestmax-1.  This gives you the nice behavior of metadata text blocks that remain hidden while all regular text is easily expanded.  Not sure if it's necessary, but in my current implementation, a metadata text block, if it exists, must be first text block after any heading, i.e., it must precede any regular text blocks.

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

Re: Always-Folded Method

Noel Henson
On Sunday 11 October 2009, hsitz wrote:

> Noel Henson wrote:
> > On Saturday 10 October 2009, hsitz wrote:
> >> Noel --- Yeah, that sounds like a good idea.  The way I reimplemented
> >> the text-hiding folding is pretty similar, except I've made the the
> >> text folds only one level higher than expected.  I experimented
> >> quickly with making them even higher, but didn't do it because (1)
> >> unless I'm missing something it does require overriding the default
> >> zc and zo behaviors and (2) it already seemed plenty speedy.
> >
> > I believe that we need to experiment a bit more. Body text is
> > particularly sticky because of historic reasons. I believe that body
> > text should always be indented to the same level as the child of a
> > heading:
> >
> > Text
> >
> >     : blah blah blah
> >     : blah blah blah
> >
> > Others believe that body text should be at the same indent level as
> > the heading.
> >
> > Text
> >
> > : blah blah blah
> > : blah blah blah
> >
> > This make the syntax highlighting and other processing more difficult.
> > Increasing the level by 1 would work for the first case, but not the
> > second; or vice-versa.
>
> The folding method I'm using works with text at any level of physical
> indent, since once you get started with this you see that the indent
> level you assign to text does not have to be tied to physical indent,
> whether folded or unfolded.  No problems with syntax highlighting.  (At
> present I think I have some non-folding related functions written to
> depend on text being physically indented one level from heading, but
> that's completely unnecessary and I've ben meaning to factor that out.)

I get it. Cool.

>
> Noel Henson wrote:
> > On Saturday 10 October 2009, hsitz wrote:
> >> In my version I also have two different levels of text blocks that
> >> can occur under each heading.   In scheme you describe, the
> >> "metadata" text block (if present) would always be at FoldNestMax
> >> level when folded, and the regular text blocks would be FoldNestMax -
> >> 1.  This allows you to easily unfold all the regular text blocks
> >> while leaving your metadata text blocks out of sight.
> >>
> >> -- Herb
> >
> > I believe you get the idea. But that . . . may be a bit wrong.
> > Using flags, all 'always-folded' regions would have the level of
> > foldnextmax.
>
> I realize you're making all folded text have level of foldnestmax.  But
> think through what happens if you have two different "kinds" of text.
> One kind is regular text and one kind is metadata text.  It is very nice
> to have the ability to see all the regular text (whether prepended by :,
> >, <, /, or
>
> | ) and at the same time have blocks of "metadata" text that remain
> | hidden.
>
> To do this you just revise your idea and have metadata text folded to
> level of foldnestmax and regular data indented one level less, to
> foldnestmax-1. This gives you the nice behavior of metadata text blocks
> that remain hdden while all regular text is easily expanded.  Not sure
> if it's necessary, but in my current implementation, a metadata text
> block, if it exists, must be first text block after any heading, i.e.,
> it must precede any regular text blocks.
>
> -- Herb

I see what you mean. What I'm going for is global flags that will allow all
always-folded items to have the same level, foldnestmax. The differentiator
and state holder for each type of block would be a variable. This state
variable would be processed by MyFoldLevel(), much like you are doing. We
may be saying the same thing. Or am I still missing something?

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: Always-Folded Method

Herbert Sitz
Noel Henson wrote
I see what you mean. What I'm going for is global flags that will allow all
always-folded items to have the same level, foldnestmax. The differentiator
and state holder for each type of block would be a variable. This state
variable would be processed by MyFoldLevel(), much like you are doing. We
may be saying the same thing. Or am I still missing something?

Noel
I think you're thinking only of the global collapse/fold function.  Merely for the purposes of that it makes no difference whether you have text blocks folded to different levels.  The usefulness comes in when you want to differentiate when _unfolding_ the text blocks.  You will usually only want to see regular text, not metadata text, so it's nice to be able to differentiate and unfold only the regular stuff while metadata remains hidden.  If you have no interest in metadata it's entirely possible to go through an entire editing session (adding, editing, showing, and hiding regular text) without ever seeing the metadata text.  Set up right, the metadata remains naturally hidden all the time, out of sight and out of mind, until you decide you want to see it.

I guess maybe you could collapse everything to foldnestmax and then just differentiate the metadata text when unfolding.  That's an implementation detail, the important thing is to have differentiating between regular text and metadata text.  I think the implementation may be simpler with method of assigning regular text a foldlevel of (foldnestmax-1) and metadata (foldnestmax), since then you can use built-in simple global command (e.g., ,,[foldnestmax-1]) to reveal all the regular text but leave the metadata text hidden.

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

Re: Always-Folded Method

Steve Litt
In reply to this post by Noel Henson
On Sunday 11 October 2009 10:45:31 Noel Henson wrote:

> On Saturday 10 October 2009, hsitz wrote:
> > Noel Henson wrote:
> > > Everyone,
> > >
> > > After reviewing Hsitz' technique for always-folded blocks, like body
> > > text and other blocks, I have a suggestion to make this type of
> > > behavior easier to implement and much faster to process. I learned
> > > this technique from implementing the new hoisting method (which still
> > > needs a bit of work).
> > >
> > > The basic idea is to change the fold levels of always-folded blocks to
> > > be much deeper than one would expect. That way the normal zo, zc and
> > > company and ,,1 through ,,0 will work as expected with no extra
> > > processing to go back and re-fold always folded blocks.
> > > [. . . ]
> >
> > Noel --- Yeah, that sounds like a good idea.  The way I reimplemented
> > the text-hiding folding is pretty similar, except I've made the the text
> > folds only one level higher than expected.  I experimented quickly with
> > making them even higher, but didn't do it because (1) unless I'm missing
> > something it does require overriding the default zc and zo behaviors and
> > (2) it already seemed plenty speedy.
>
> I believe that we need to experiment a bit more. Body text is particularly
> sticky because of historic reasons. I believe that body text should always
> be indented to the same level as the child of a heading:
>
> Text
>
>     : blah blah blah
>     : blah blah blah
>
> Others believe that body text should be at the same indent level as the
> heading.
>
> Text
>
> : blah blah blah
> : blah blah blah

Oh HECK no! Body text is ABOUT its parent, not IN ADDITION TO its parent.

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: Always-Folded Method

Noel Henson
In reply to this post by Herbert Sitz
On Sunday 11 October 2009, hsitz wrote:

> Noel Henson wrote:
> > I see what you mean. What I'm going for is global flags that will
> > allow all
> > always-folded items to have the same level, foldnestmax. The
> > differentiator
> > and state holder for each type of block would be a variable. This
> > state variable would be processed by MyFoldLevel(), much like you are
> > doing. We may be saying the same thing. Or am I still missing
> > something?
> >
> > Noel
>
> I think you're thinking only of the global collapse/fold function.
> Merely for the purposes of that it makes no difference whether you have
> text blocks indented to different levels.  The usefulness comes in when
> you want to differentiate when _unfolding_ the text blocks.  You will
> usually only want to see regular text, not metadata text, so it's nice
> to be able to differentiate and unfold only the regular stuff while
> metadata remains hidden.  If you have no interest in metadata it's
> entirely possible to go through an entire editing session (adding,
> editing, showing, and hiding regular text) without ever seeing the
> metadata text.  Set up right, the metadata remains naturally hidden all
> the time, out of sight and out of mind, until you decide you want to see
> it.
>
> -- Herb

Herb,

I still think we are going after the same thing but somehow missing each
other in the communication. If there were are set of flags like:

let alwaysfold_meta=1
let alwaysfold_text=1
let alwaysfold_tables=1

Then user commands, keys or whatever would change these variables and thus
change the always-folded behavior of the blocks in question. I believe this
accomplished the needed behavior for all use cases. But, if I'm still
missing something, please take the time to give me a more remedial example
so I can 'get it'. But, if what I'm trying to do by normalizing things
simply won't work, then I'll be happy to reserve the foldnestmax level for
metadata and foldnestmax-1 can be used for other conditional always-folded
item.

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: Always-Folded Method

Herbert Sitz
Noel Henson wrote
Herb,

I still think we are going after the same thing but somehow missing each
other in the communication.
It is just an implementation issue.  The question is, if metadata text and regular text are both folded to foldnestmax, what do you do when you want to view all the regular text and leave all the metadata hidden?  If you have metadata folded to foldnestmax and reg-text to foldnestmax-1, then simple ,,[foldnestmax-1] command will reveal everything but the metadata.  You could accomplish same thing if metadata and regular text were folded to same level, but you'd need to add differentiating logic to MyFoldLevel function.  Conceptually and codewise it just seems simpler to have them folded to different levels.

In the quick and dirty proof-of-concept I added to my own MyFoldLevel function I do something even more different.  I simply add 10 to the existing unfolded level when folding regular text and 20 to level for folded metadata text.  That works for an effective maximum of 10 heading levels (0 to 9) , and gives you corresponding folded regular text levels (of, I think, 11 to 20) but lacks the concept of foldnestmax you have.  It has benefit, however of allowing greater granularity when expanding, since you aren't forced to expand all levels of text at once.  E.g., in an outline having headline levels of 0 to 9, the regular text will be folded to levels 11 to 20.  If you want to expand all heading levels but unfold text only for levels 1 and 2 you would issue command ,,12 .  

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

Re: Always-Folded Method

Noel Henson
In reply to this post by Steve Litt
On Sunday 11 October 2009, Steve Litt wrote:

> On Sunday 11 October 2009 10:45:31 Noel Henson wrote:
> > On Saturday 10 October 2009, hsitz wrote:
> > > Noel Henson wrote:
> > > > Everyone,
> > > >
> > > > After reviewing Hsitz' technique for always-folded blocks, like
> > > > body text and other blocks, I have a suggestion to make this type
> > > > of behavior easier to implement and much faster to process. I
> > > > learned this technique from implementing the new hoisting method
> > > > (which still needs a bit of work).
> > > >
> > > > The basic idea is to change the fold levels of always-folded
> > > > blocks to be much deeper than one would expect. That way the
> > > > normal zo, zc and company and ,,1 through ,,0 will work as
> > > > expected with no extra processing to go back and re-fold always
> > > > folded blocks.
> > > > [. . . ]
> > >
> > > Noel --- Yeah, that sounds like a good idea.  The way I
> > > reimplemented the text-hiding folding is pretty similar, except I've
> > > made the the text folds only one level higher than expected.  I
> > > experimented quickly with making them even higher, but didn't do it
> > > because (1) unless I'm missing something it does require overriding
> > > the default zc and zo behaviors and (2) it already seemed plenty
> > > speedy.
> >
> > I believe that we need to experiment a bit more. Body text is
> > particularly sticky because of historic reasons. I believe that body
> > text should always be indented to the same level as the child of a
> > heading:
> >
> > Text
> >
> >     : blah blah blah
> >     : blah blah blah
> >
> > Others believe that body text should be at the same indent level as
> > the heading.
> >
> > Text
> >
> > : blah blah blah
> > : blah blah blah
>
> Oh HECK no! Body text is ABOUT its parent, not IN ADDITION TO its
> parent.
>

I'm not quite sure what you're saying here but...  Body text IS about the
parent. It belongs to the parent. Just like children belong to the parent.  
If the body text was about a child, it would be indented underneath the
child. If VO adopted that philosophy, then syntax highlighting, folding and
post processing would be much easier. In summary, anything that is an
attribute of a parent is indented under the parent.

Parent
    : This is text about the parent. It cannot be about a child
    : because it comes immediately under the parent.
    Child
        : this is the child that clearly belongs to the parent

In my (limited) mind, an outline is very simple. There is a heading and
there are objects the heading can contain including other headings.

Heading
    Headings
    Text
    Tables
    User Text
    Preformatted User Text
    Labeled User Text
    Preformatted Labeled User Text

When done with text not indented under the heading, it is no longer clear
visually that the text is contained in (or is about) the heading. This
makes syntax highlighting, fold level computation and post processing more
difficult; there is that exception  case for text.

I'm not arguing for change here. Some have one way of doing things, some
another. For me, I like the visual cleanliness of having body text indented
under the heading it belongs to.

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: Always-Folded Method

Noel Henson
In reply to this post by Herbert Sitz
On Sunday 11 October 2009, hsitz wrote:

> Noel Henson wrote:
> > Herb,
> >
> > I still think we are going after the same thing but somehow missing
> > each other in the communication.
>
> It is just an implementation issue.  The question is, if metadata text
> and regular text are both folded to foldnestmax, what do you do when you
> want to view all the regular text and leave all the metadata hidden?  If
> you have metadata folded to foldnestmax, then simple ,,[foldnestmax-1]
> command will reveal everything but the metadata.  You could accomplish
> same thing if metadata and regular text were folded to same level, but
> you'd need to add differentiating logic to MyFoldLevel function.
> Conceptually and codewise it just seems simpler to have them indented to
> different levels.
>
> In the quick and dirty proof-of-concept I added to my own MyFoldLevel
> function I simply add 10 to level of folded regular text and 20 to level
> of folded metadata text.  That works for an effective maximum of 10
> heading levels, but lacks the concept of foldnestmax you have.  It has
> benefit, however of allowing greater granularity when expanding, since
> you aren't forced to expand all levels of text at once.  E.g., in an
> outline having headline levels of 0 to 9, the regular text will be
> folded to levels 10 to 19.  If you want to expand all heading levels but
> unfold text only for levels 1 and 2 you would issue command ,,11 .
>
> -- Herb

Herb,

I see what you are saying and, in the simple case of just body text and
meta data, cannot argue with you. However, there are many objects that can
be folded and may want to be hidden. There are body text, preformatted body
text, user text, preformatted user text, labeled user text, preformatted
labeld user text and tables.

Noel

PS: I'm setting up your most recent scripts for testing now.

--

------------------------------------------------------------------
  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: Always-Folded Method

Herbert Sitz
In reply to this post by Steve Litt
Steve Litt wrote
On Sunday 11 October 2009 10:45:31 Noel Henson wrote:
> Text
>
>     : blah blah blah
>     : blah blah blah
>
Oh HECK no! Body text is ABOUT its parent, not IN ADDITION TO its parent.
Steve -- IMO you need to get past concept of indent level determining outline level.  Personally, there are times when I'd like to have all text blocks be rendered flush left with no indent (even if I didn't enter them that way), regardless of the level of heading they're "attached" to.  Seems you're tied to concept of outline level as being tied to indent level.  There's no (good) reason to restrict it in that way.  Expand your mind.  ;)

In any case I think VO should be set up so that a person can have their text blocks indented to any level they want.  The important thing is that however they're indented the text blocks are "attached" to the immediately preceding headline node.

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

Re: Always-Folded Method

Herbert Sitz
In reply to this post by Noel Henson
Noel Henson wrote
I see what you are saying and, in the simple case of just body text and
meta data, cannot argue with you. However, there are many objects that can
be folded and may want to be hidden. There are body text, preformatted body
text, user text, preformatted user text, labeled user text, preformatted
labeld user text and tables.
Yes, in everything I said previously the phrase "regular text" included body text, preformatted body
text, user text, preformatted user text, labeled user text, preformatted
labeld user text and tables.  Only the metadata text blocks would be folded to one level higher.

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

Re: Always-Folded Method

Noel Henson
On Sunday 11 October 2009, hsitz wrote:

> Noel Henson wrote:
> > I see what you are saying and, in the simple case of just body text
> > and meta data, cannot argue with you. However, there are many objects
> > that can be folded and may want to be hidden. There are body text,
> > preformatted body
> > text, user text, preformatted user text, labeled user text,
> > preformatted labeld user text and tables.
>
> Yes, in everything I said previously the phrase "regular text" included
> body text, preformatted body
> text, user text, preformatted user text, labeled user text, preformatted
> labeld user text and tables.  Only the metadata text blocks would be
> folded to one level higher.
>
> -- Herb

So how do we normalize it so the functionality can be shared?

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: Always-Folded Method

Noel Henson
In reply to this post by Herbert Sitz
On Sunday 11 October 2009, hsitz wrote:

> Steve Litt wrote:
> > On Sunday 11 October 2009 10:45:31 Noel Henson wrote:
> >> Text
> >>
> >>     : blah blah blah
> >>     : blah blah blah
> >
> > Oh HECK no! Body text is ABOUT its parent, not IN ADDITION TO its
> > parent.
>
> Steve -- IMO you need to get past concept of indent level determining
> outline level.  Personally, there are times when I'd like to have all
> flush be rendered flush left with no indent, regardless of there outline
> level. Seems you're tied to concept of outline level as being tied to
> indent level. There's no (good) reason to restrict it in that way.
> Expand your mind.  ;)
>
> In any case I think VO should be set up so that a person can have their
> text blocks indented to any level they want.  The important thing is
> that however they're indented the text blocks are "attached" to the
> immediately preceding headline node.
>
> -- Herb

Herb,

This can be VERY difficult; I mean supporting any indent level. Yes, it can
be handled with a function but highlighting can be quite an issue.

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: Always-Folded Method

Herbert Sitz
In reply to this post by Noel Henson
Noel Henson wrote
> text, user text, preformatted user text, labeled user text, preformatted
> labeld user text and tables.  Only the metadata text blocks would be
> folded to one level higher.
>

So how do we normalize it so the functionality can be shared?

Noel
Noel -- Not quite sure what the question is.  Everything should work exactly as you were describing, except that metadata blocks are treated differently.  If you want, you can fold all regular text to foldnestmax (if their flag is set) and fold metadata to foldnestmax+1.  What issue are you concerned about?
Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

Herbert Sitz
In reply to this post by Noel Henson
Noel Henson wrote
> In any case I think VO should be set up so that a person can have their
> text blocks indented to any level they want.  The important thing is
> that however they're indented the text blocks are "attached" to the
> immediately preceding headline node.

This can be VERY difficult; I mean supporting any indent level. Yes, it can
be handled with a function but highlighting can be quite an issue.

Noel
If I recall, that's not an issue at all with syntax file I use.  All text blocks shares same highlight regardless of indent or fold level.  What's the problem you're seeing?
Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

Herbert Sitz
In reply to this post by Herbert Sitz
hsitz wrote
Noel Henson wrote
So how do we normalize it so the functionality can be shared?
Noel -- Not quite sure what the question is.  Everything should work exactly as you were describing, except that metadata blocks are treated differently.  If you want, you can fold all regular text to foldnestmax (if their flag is set) and fold metadata to foldnestmax+1.  What issue are you concerned about?
Noel -- One thing I just thought of.  Functionality I currently use expands and collapses all "regular" text (body text, preformatted, table, etc.) as a single block.  Entering zc on a headline expands or collapses all varieties of text block underneath at same time.  I'm not sure I even understand how it would be possible to have them collapsed into a headline independently, with some kinds of text collapsed and some not.

For example, take this headline with several kinds of text:

headline
     : body text
     : body text
     | table
     | table
     | table
     ;  preformatted
     ; preformatted
     ; preformatted

How are you thinking it would be possible to fully "collapse" the body text and the preformatted text into the headline, but leave the table text visible?  I don't see any way it would work; any way I can think of is both conceptually ugly (i.e, treats text as headline elements) and ugly on the screen.  The text should all be collapsed as one element.

If you want something that fits with the conceptual underpinnings of an outline you can't rely on outline structure that is implicitly contained within text blocks.  Headings contain all the structure of an outline. If different kinds of text blocks are important enough that you want them separately collapsible then they are important enough to have their own headings.  So if you wanted the text elements above to be separately collapsible you instead would enter you outline like this:

headline
     : body text
     : body text
     Table for Headline 1
          | table
          | table
          | table
     Preformatted text heading
          ;  preformatted
          ; preformatted
          ; preformatted

That isn't to say that it's wrong to have different kinds of text all under same heading.  But if there is some structure implicit them that makes it reasonable to view some while others are hidden, then they should go under headings.  At least that's the conceptually clean way to do it.  Proper outliners do not "fold" text, text is "collapsed" into a heading.  

I don't mean to alarm anyone and I don't mean to suggest that you in fact make VO operate this way.  Whatever you do is fine with me.  But as it stands VO is an outliner with cracks where its base as a mere folding text editor shows through.  Some people may even rely on it.  But the VO behavior is nevertheless in many cases different from what you'd have in a true outliner.  Personally, I think if VO is developed further it should focus on making it a true outliner, getting away from areas where its base as a folding text editor shows through.  I'm sure others differ.  Maybe you want to freeze code at some point and call it VO Classic, for those who think VO is perfect as it is.

-- Herb
1234