Always-Folded Method

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

Re: Always-Folded Method

Herbert Sitz
This post was updated on .
David J Patrick-2 wrote
  What about the scripts that have
> already been written that adhere to the indented conventions?
(re-iteration) Heading level conventions should not ever be changed. Too
much depends on it; existing codebase, all the post-processing scripts,
current development impetus and basic usability.

If the outcome is an agreement indicates a desire for increased
flexibility of body text indentation, and that proves trivial to
implement, then existing output scripts will keep working (if the indent
levels follow todays conventions) and are probably trivial to update, too.
Here's a first stab at an awk post-processing script that will normalize (I think) all kinds of text blocks to an indent of one tab

stop from preceding heading.  It doesn't change headings at all:

AWK Script to normalize an .otl file to have all text at single tab indent from heading
-----------------------------
# block to process headings
/^(\t)*[^;:<>|\t]/ { match( $0, /^\t*[^:;<>|]/ )
                headlevel= RLENGTH
                tabprefix = ""
                for ( i=0; i < headlevel; i++ )
                    tabprefix = tabprefix "\t"
                print $0 }

#block to process text lines
/^(\t)*[;:<>|]/ { text_char_start = match( $0, /[^\t].*$/ )
                textline = tabprefix substr( $0, text_char_start )
                print textline  }
----------------------------

It's not heavily tested, but anyone is free to use as they will.  As far as know, only thing it definitely will _not_ accommodate is outlines that have "rogue" text blocks in between subheadings that are intended to belong to higher level master heading.  IMO, that sort of rogue text has no place within an outline and a real outliner would prevent you from doing it, but just fyi the "rogue text block" below would be normalized by the above script to belong to the immediately preceding second level heading.  As, e.g, here:

Master heading
     : text block
     : text block
     Second level heading 1
            :text block for second level head
            :text block for second level head
            :text block for second level head
            :text block for second level head
     : "ROGUE" text block intended to belong to master heading
     : "ROGUE" text block intended to belong to master heading
     : "ROGUE" text block intended to belong to master heading
     : "ROGUE" text block intended to belong to master heading
     Second level heading 2
            :text block for second level head
            :text block for second level head
            :text block for second level head
            :text block for second level head


Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

Noel Henson
In reply to this post by Steve Litt

[snip]

> > It may be trivial to write for just body text. But there are other
> > objects as well that need to be considered. What about the scripts
> > that have already been written that adhere to the indented
> > conventions?
>
> I think that what Herb is saying is that for body text and body text
> alone, a simple filter script could input arbitrary body text
> indentation and output expected body text indentation to the existing
> post-processing script.
>
> As you mention, when you consider other objects the plot thickens,
> because for each object you have to decide whether it's considered a
> container or not, and whether following body text should be considered
> subservient to that kind of object, etc. In other words, as you mention,
> it can turn into a mess.
>
> VO currently allows any type of indentation method imaginable. If one
> wanted, the top level could be 8 tabs to the right, the second level
> could be 7 tabs to the right, the third level would be 6 tabs to the
> right, etc, and VO would merrily allow it. This whole thing boils down
> to a collapse question and a text color question. What do you collapse
> under a given headline, and what color is the stuff at various [levels |
> indents]. I think the question being asked is should we change the
> collapse and coloration to accommodate various types of indentation.
>
> My personal answer to the preceding question would be "no", especially
> if it would be difficult.
>
> As far as the post-processors failing with non-standard indentation,
> this is a documentation problem solved by the following paragraph:
>
> ======================================
> Standard documentation involves body text and other objects being
> exactly one indent right of the object they refer to, or the object
> containing them if you'd prefer to think of it that way. If the only
> objects you're using are headlines and body text and if you use
> non-standard indentation of body text, your post-processors will
> continue to work if you filter your outline through
> fix_bodytext_indentation.pl as follows:
>
> cat myoutline.otl | ./fix_bodytext_indentation.pl |
> ./my_postprocessor.pl
>
> However, if you're using other objects besides headlines and body text
> and choose to indent your body text (or any other objects) in a
> non-standard way, normal post processors will not work.
> ======================================
>
> SteveT

I see what Herb and David are after. Some of the reasons make sense to me.  
Being a hardware engineer and systems engineer, my instinct is to normalize
behaviors. Basic rules of the disciplines are to remove exception cases and
normalize processing (and data). But my design philosophies are a different
story.

There is a good deal of merit to having body text be viewable and editable
in a larger area when the location of the text is relatively deep. I went
over many older outlines I have and some of the text depth was a level 9.  
This gave me just about 40 characters of editing width. I felt like I was
using my Vic 20 or Atari 400 (though if you're a speed reader, the narrow
columns are kind of cool ;) ).

After thinking about this quite a bit and doing some simple tests, the only
objects that need to have 'different' behaviors are the ones specified in
'comments' they are the ones that have wrapping (while headings and others
don't). I have worked out the proper level of folding and indentation of
folded text while in fact the unfolded block had no indentation at all.  
Body text level computation is somewhat slower but still unnoticeable
because the extra computation takes place only on the body text. This might
warrant further experimentation. To complete the new feature would require
a couple of VO commands and maybe a flag. The functions would be something
like: left_justify_text_block, indent_text_block. We already have ,,b
(convert to colon-space body text) and ,,B (convert to space body text (for
printing)). It may be reasonable to modify those mappings a bit. Perhaps:

,,bb convert all body text to indented colon-space text
,,bB convert all body text to left-justified colon-space text
,,B convert all body text to indented space text

Or, since ,,B seems to be rarely used, leave it as a function that is
accessed via the command line or menu (in GUI mode).

,,b convert all body text to indented colon-space text
,,B convert all body text to left-justified colon-space text

Just thinking...

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
On Tuesday 13 October 2009, Noel Henson wrote:

> [snip]
>
> > > It may be trivial to write for just body text. But there are other
> > > objects as well that need to be considered. What about the scripts
> > > that have already been written that adhere to the indented
> > > conventions?
> >
> > I think that what Herb is saying is that for body text and body text
> > alone, a simple filter script could input arbitrary body text
> > indentation and output expected body text indentation to the existing
> > post-processing script.
> >
> > As you mention, when you consider other objects the plot thickens,
> > because for each object you have to decide whether it's considered a
> > container or not, and whether following body text should be considered
> > subservient to that kind of object, etc. In other words, as you
> > mention, it can turn into a mess.
> >
> > VO currently allows any type of indentation method imaginable. If one
> > wanted, the top level could be 8 tabs to the right, the second level
> > could be 7 tabs to the right, the third level would be 6 tabs to the
> > right, etc, and VO would merrily allow it. This whole thing boils down
> > to a collapse question and a text color question. What do you collapse
> > under a given headline, and what color is the stuff at various [levels
> > | indents]. I think the question being asked is should we change the
> > collapse and coloration to accommodate various types of indentation.
> >
> > My personal answer to the preceding question would be "no", especially
> > if it would be difficult.
> >
> > As far as the post-processors failing with non-standard indentation,
> > this is a documentation problem solved by the following paragraph:
> >
> > ======================================
> > Standard documentation involves body text and other objects being
> > exactly one indent right of the object they refer to, or the object
> > containing them if you'd prefer to think of it that way. If the only
> > objects you're using are headlines and body text and if you use
> > non-standard indentation of body text, your post-processors will
> > continue to work if you filter your outline through
> > fix_bodytext_indentation.pl as follows:
> >
> > cat myoutline.otl | ./fix_bodytext_indentation.pl |
> > ./my_postprocessor.pl
> >
> > However, if you're using other objects besides headlines and body text
> > and choose to indent your body text (or any other objects) in a
> > non-standard way, normal post processors will not work.
> > ======================================
> >
> > SteveT
>
> I see what Herb and David are after. Some of the reasons make sense to
> me. Being a hardware engineer and systems engineer, my instinct is to
> normalize behaviors. Basic rules of the disciplines are to remove
> exception cases and normalize processing (and data). But my design
> philosophies are a different story.
>
> There is a good deal of merit to having body text be viewable and
> editable in a larger area when the location of the text is relatively
> deep. I went over many older outlines I have and some of the text depth
> was a level 9. This gave me just about 40 characters of editing width. I
> felt like I was using my Vic 20 or Atari 400 (though if you're a speed
> reader, the narrow columns are kind of cool ;) ).
>
> After thinking about this quite a bit and doing some simple tests, the
> only objects that need to have 'different' behaviors are the ones
> specified in 'comments' they are the ones that have wrapping (while
> headings and others don't). I have worked out the proper level of
> folding and indentation of folded text while in fact the unfolded block
> had no indentation at all. Body text level computation is somewhat
> slower but still unnoticeable because the extra computation takes place
> only on the body text. This might warrant further experimentation. To
> complete the new feature would require a couple of VO commands and maybe
> a flag. The functions would be something like: left_justify_text_block,
> indent_text_block. We already have ,,b (convert to colon-space body
> text) and ,,B (convert to space body text (for printing)). It may be
> reasonable to modify those mappings a bit. Perhaps:
>
> ,,bb convert all body text to indented colon-space text
> ,,bB convert all body text to left-justified colon-space text
> ,,B convert all body text to indented space text
>
> Or, since ,,B seems to be rarely used, leave it as a function that is
> accessed via the command line or menu (in GUI mode).
>
> ,,b convert all body text to indented colon-space text
> ,,B convert all body text to left-justified colon-space text
>
> Just thinking...
>
> Noel

I forgot to mention that an auto-command (BufWritePre) could be used to
always force the VO file format (properly indented everything) when on
writing and quitting. A user variable in their vimoutlinerrc file could be
used with another auto-command (BufReadPre) to automatically for
left-justified wide text.

More 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:
[snip]
>> After thinking about this quite a bit and doing some simple tests, the
>> only objects that need to have 'different' behaviors are the ones
>> specified in 'comments' they are the ones that have wrapping (while
>> headings and others don't). I have worked out the proper level of
>> folding and indentation of folded text while in fact the unfolded block
>> had no indentation at all.
[also snip]

>
> I forgot to mention that an auto-command (BufWritePre) could be used to
> always force the VO file format (properly indented everything) when on
> writing and quitting. A user variable in their vimoutlinerrc file could be
> used with another auto-command (BufReadPre) to automatically for
> left-justified wide text.
>
> More thoughts?
This sounds just right; not to evil to the codebase nor disruptive to
users. Merci mon Capitaine!
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
There is a good deal of merit to having body text be viewable and editable
in a larger area when the location of the text is relatively deep. I went
over many older outlines I have and some of the text depth was a level 9.  
This gave me just about 40 characters of editing width. I felt like I was
using my Vic 20 or Atari 400 (though if you're a speed reader, the narrow
columns are kind of cool ;) ).
Exactly.  I see it as a good feature, but not necessarily one to push to front of queue of waiting features, expecially if there's any unexpected snag in implementation.

We've mentioned it before, but any possibility of putting code up on the web in svn or git?  Would make it much easier to keep track of experimental work in branches and let other people see and offer changes.

Noel Henson wrote
After thinking about this quite a bit and doing some simple tests, the only
objects that need to have 'different' behaviors are the ones specified in
'comments' they are the ones that have wrapping (while headings and others
don't).
Forgot about that.  I've removed the "automatic" real time wrapping flag (flag "a") in formatoptions in my VO because it's dog slow; can't even keep up with my keystrokes and sometimes induces even worse delays.  Not sure how you're handling this.  Wouldn't clean way to do indent change operation be to (1) make sure "a" flag is off (:set fo-=a), (2) change indents with something like vimscript port of my awk script above (wrap text without "a" flag will _not_ automatically reformat), (3) do reformatting ops (gq) for text in doc, (which will preserve previxes properly), and (4) renable "a" flag if it was being used before.

Noel Henson wrote
 I have worked out the proper level of folding and indentation of
folded text while in fact the unfolded block had no indentation at all.  
Body text level computation is somewhat slower but still unnoticeable
because the extra computation takes place only on the body text. This might
warrant further experimentation.
What issue is this dealing with?  Don't quite understand what problem is being dealt with.  [edit: never mind, I got it, when making flush left there's no level awareness needed at all.  Are you using something different from my awk script approach to normalize the indented text blocks?  I don't mind slight delay in computation, it's not an operation that people will be doing often, and lag should only be noticeable in very large documents.  If you put it in bufwritepre it could be an issue though.  Actually, thinking again I'm not sure what you're referring to.  If you're talking about level assignment in MyFoldLevel() then the algorithm used in my version works, I think, regardless of indent level of text.]

Noel Henson wrote
 To complete the new feature would require
a couple of VO commands and maybe a flag. The functions would be something
like: left_justify_text_block, indent_text_block. We already have ,,b
(convert to colon-space body text) and ,,B (convert to space body text (for
printing)). It may be reasonable to modify those mappings a bit. Perhaps:

,,bb convert all body text to indented colon-space text
,,bB convert all body text to left-justified colon-space text
,,B convert all body text to indented space text

Or, since ,,B seems to be rarely used, leave it as a function that is
accessed via the command line or menu (in GUI mode).

,,b convert all body text to indented colon-space text
,,B convert all body text to left-justified colon-space text

Just thinking...
All sounds good.  I know many of the functions I've written will have to be revised to be more general at identifying text blocks.  Something I had in my mind to do at some point anyway.

Thanks for doing this work Noel.  I wonder if you might want to make some list of changes you're making to current version of VO and order them by priority.  Then tackle them one at a time.

-- 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 forgot to mention that an auto-command (BufWritePre) could be used to
always force the VO file format (properly indented everything) when on
writing and quitting. A user variable in their vimoutlinerrc file could be
used with another auto-command (BufReadPre) to automatically for
left-justified wide text.

More thoughts?

Noel
Neat idea.  I was already thinking the awk indent normalization script might be better done within vim/VO itself.  -- Herb
Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

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

> Noel Henson wrote:
> > There is a good deal of merit to having body text be viewable and
> > editable in a larger area when the location of the text is relatively
> > deep. I went over many older outlines I have and some of the text
> > depth was a level 9. This gave me just about 40 characters of editing
> > width. I felt like I was using my Vic 20 or Atari 400 (though if
> > you're a speed reader, the narrow columns are kind of cool ;) ).
>
> Exactly.  I see it as a good feature, but not necessarily one to push to
> front of queue of waiting features, expecially if there's any unexpected
> snag in implementation.
>
> We've mentioned it before, but any possibility of putting code up on the
> web in svn or git?  Would make it much easier to keep track of
> experimental work in branches and let other people see and offer
> changes.
>
> Noel Henson wrote:
> > After thinking about this quite a bit and doing some simple tests, the
> > only
> > objects that need to have 'different' behaviors are the ones specified
> > in 'comments' they are the ones that have wrapping (while headings and
> > others don't).
>
> Forgot about that.  I've removed the "automatic" real time wrapping flag
> (flag "a") in formatoptions in my VO because it's dog slow; can't even
> keep up with my keystrokes and sometimes induces even worse delays.  Not
> sure how you're handling this.  Wouldn't clean way to do indent change
> operation be to (1) make sure "a" flag is off (:set fo-=a), (2) change
> indents (wrap text will _not_ automatically reformat), (3) do
> reformatting ops (gq) for text in doc, (which will preserve previxes
> properly), and (4) renable "a" flag if it was being used before.
>
> Noel Henson wrote:
> >  I have worked out the proper level of folding and indentation of
> > folded text while in fact the unfolded block had no indentation at
> > all. Body text level computation is somewhat slower but still
> > unnoticeable because the extra computation takes place only on the
> > body text. This might
> > warrant further experimentation.
>
> What issue is this dealing with?  Don't quite understand what problem is
> being dealt with.
>
> Noel Henson wrote:
> >  To complete the new feature would require
> > a couple of VO commands and maybe a flag. The functions would be
> > something like: left_justify_text_block, indent_text_block. We already
> > have ,,b (convert to colon-space body text) and ,,B (convert to space
> > body text (for
> > printing)). It may be reasonable to modify those mappings a bit.
> > Perhaps:
> >
> > ,,bb convert all body text to indented colon-space text
> > ,,bB convert all body text to left-justified colon-space text
> > ,,B convert all body text to indented space text
> >
> > Or, since ,,B seems to be rarely used, leave it as a function that is
> > accessed via the command line or menu (in GUI mode).
> >
> > ,,b convert all body text to indented colon-space text
> > ,,B convert all body text to left-justified colon-space text
> >
> > Just thinking...
>
> All sounds good.  I know many of the functions I've written will have to
> be revised to be more general at identifying text blocks.  Something I
> had in my mind to do at some point anyway.
>
> Thanks for doing this work Noel.  I wonder if you might want to make
> some list of changes you're making to current version of VO and order
> them by priority.  Then tackle them one at a time.
>
> -- Herb

Once I get VO 0.4.0 out; life keeps getting in the way, I'll set up
a controlled SVN system for VO. There were many times with the CVS server
that users without a glue about proper software development and coding
techniques were constantly changing the VO source. Then I'd have to go fix
it. Then they would make the stupid changes again. Then I'd have to fix it
again, etc., etc..

On such a server, I would like to keep the released version of VO
completely locked down. Users will be able to request updates and post
patches but they will be just that: requested updates and posted patches,
either of which may or may not be included in the next release.

I would also like to support and promote (and possibly enforce) the use of
VO plugin feature. This feature is there so that things can be changed
without the need for changing any VO core sources. The plugin feature can
be used for changing anything about VO, keymappings, different functions,
new features, changing the behavior of old features, etc.

A few, a precious few, will be allowed write access to the VO core SVN (you
would be on the list :) ). Everyone else could create their own area within
the SVN for their own scripts, modifications, plugins, features, color
schemes, etc.

As far as the list goes, I need to update my release 0.4.0 outline and post
it for comments.

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
In reply to this post by Noel Henson
Noel Henson wrote:
[slash]
> ,,B convert all body text to indented space text
>
> Or, since ,,B seems to be rarely used, leave it as a function that is
> accessed via the command line or menu (in GUI mode).
is anyone actually using this ?
is it deprecated ? (it should be)
can we just kill it ? (IMHO <tab><tab><space> is just a formatting trap)
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
On Tuesday 13 October 2009, David J Patrick wrote:

> Noel Henson wrote:
> [slash]
>
> > ,,B convert all body text to indented space text
> >
> > Or, since ,,B seems to be rarely used, leave it as a function that is
> > accessed via the command line or menu (in GUI mode).
>
> is anyone actually using this ?
> is it deprecated ? (it should be)
> can we just kill it ? (IMHO <tab><tab><space> is just a formatting trap)
> djp
> _______________________________________________
> VimOutliner mailing list
> [hidden email]
> http://www.lists.vimoutliner.org/mailman/listinfo

I use it rarely, like when I have to print an outline for a quick meeting
and don't want to go through the effort of printing HTML.

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

Steve Litt
In reply to this post by Noel Henson
On Tuesday 13 October 2009 10:16:40 Noel Henson wrote:

> [snip]
>
> > > It may be trivial to write for just body text. But there are other
> > > objects as well that need to be considered. What about the scripts
> > > that have already been written that adhere to the indented
> > > conventions?
> >
> > I think that what Herb is saying is that for body text and body text
> > alone, a simple filter script could input arbitrary body text
> > indentation and output expected body text indentation to the existing
> > post-processing script.
> >
> > As you mention, when you consider other objects the plot thickens,
> > because for each object you have to decide whether it's considered a
> > container or not, and whether following body text should be considered
> > subservient to that kind of object, etc. In other words, as you mention,
> > it can turn into a mess.
> >
> > VO currently allows any type of indentation method imaginable. If one
> > wanted, the top level could be 8 tabs to the right, the second level
> > could be 7 tabs to the right, the third level would be 6 tabs to the
> > right, etc, and VO would merrily allow it. This whole thing boils down
> > to a collapse question and a text color question. What do you collapse
> > under a given headline, and what color is the stuff at various [levels |
> > indents]. I think the question being asked is should we change the
> > collapse and coloration to accommodate various types of indentation.
> >
> > My personal answer to the preceding question would be "no", especially
> > if it would be difficult.
> >
> > As far as the post-processors failing with non-standard indentation,
> > this is a documentation problem solved by the following paragraph:
> >
> > ======================================
> > Standard documentation involves body text and other objects being
> > exactly one indent right of the object they refer to, or the object
> > containing them if you'd prefer to think of it that way. If the only
> > objects you're using are headlines and body text and if you use
> > non-standard indentation of body text, your post-processors will
> > continue to work if you filter your outline through
> > fix_bodytext_indentation.pl as follows:
> >
> > cat myoutline.otl | ./fix_bodytext_indentation.pl |
> > ./my_postprocessor.pl
> >
> > However, if you're using other objects besides headlines and body text
> > and choose to indent your body text (or any other objects) in a
> > non-standard way, normal post processors will not work.
> > ======================================
> >
> > SteveT
>
> I see what Herb and David are after. Some of the reasons make sense to me.
> Being a hardware engineer and systems engineer, my instinct is to normalize
> behaviors. Basic rules of the disciplines are to remove exception cases and
> normalize processing (and data). But my design philosophies are a different
> story.
>
> There is a good deal of merit to having body text be viewable and editable
> in a larger area when the location of the text is relatively deep. I went
> over many older outlines I have and some of the text depth was a level 9.
> This gave me just about 40 characters of editing width. I felt like I was
> using my Vic 20 or Atari 400 (though if you're a speed reader, the narrow
> columns are kind of cool ;) ).
>
> After thinking about this quite a bit and doing some simple tests, the only
> objects that need to have 'different' behaviors are the ones specified in
> 'comments' they are the ones that have wrapping (while headings and others
> don't). I have worked out the proper level of folding and indentation of
> folded text while in fact the unfolded block had no indentation at all.
> Body text level computation is somewhat slower but still unnoticeable
> because the extra computation takes place only on the body text. This might
> warrant further experimentation. To complete the new feature would require
> a couple of VO commands and maybe a flag. The functions would be something
> like: left_justify_text_block, indent_text_block. We already have ,,b
> (convert to colon-space body text) and ,,B (convert to space body text (for
> printing)). It may be reasonable to modify those mappings a bit. Perhaps:
>
> ,,bb convert all body text to indented colon-space text
> ,,bB convert all body text to left-justified colon-space text
> ,,B convert all body text to indented space text
>
> Or, since ,,B seems to be rarely used, leave it as a function that is
> accessed via the command line or menu (in GUI mode).
>
> ,,b convert all body text to indented colon-space text
> ,,B convert all body text to left-justified colon-space text
>
> Just thinking...

Ya know, if there's one comma comma command that wouldn't cause too much
trouble being cannibalized, ,,b and ,,B is it, at least for me. I ALWAYS use
colons except once in a while when I print, but even then I like colons
because the reader needs to know what's headline and what's body text.

Personally I'd vote for the ,,bb, ,,bB, and ,,B because it preserves the
opportunity to use space indented body text. No use leaving users high and
dry. Personally, I'd do this:

,,bb indented colon
,,bB left just colon
,,BB space indent
,,b* and ,,B*  reserved for other stuff we may need.

Maybe we can identify other seldom used ,, commands and open them up. We could
propose them on this mailing list, and if nobody appears to use them with
daily frequency, we could open them up to get 26 ,, commands where we used to
have one.

You know, in the summer of 2001 it NEVER OCCURRED to me that some day we'd run
out of ,, commands, or I would have put more "digits" on some of them.

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

Steve Litt
In reply to this post by David J Patrick-2
On Tuesday 13 October 2009 13:15:51 David J Patrick wrote:

> Noel Henson wrote:
> [slash]
>
> > ,,B convert all body text to indented space text
> >
> > Or, since ,,B seems to be rarely used, leave it as a function that is
> > accessed via the command line or menu (in GUI mode).
>
> is anyone actually using this ?
> is it deprecated ? (it should be)
> can we just kill it ? (IMHO <tab><tab><space> is just a formatting trap)
> djp

My opinion is it's bad karma to kill any feature, because somewhere out there,
maybe not even on our list, there's someone who regularly flips back and forth
between the two types of body text. In another email I mentioned a way to keep
,,B but add another "digit" to get 26 ,, commands where we used to have one.
If everyone else uses space indented body text as little as I do, I think
that's a reasonable sacrifice for that one guy to make, but I'd hate to yank
the rug out from under him.

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 Steve Litt
On Tuesday 13 October 2009, Steve Litt wrote:

[snip]

> > Just thinking...
>
> Ya know, if there's one comma comma command that wouldn't cause too much
> trouble being cannibalized, ,,b and ,,B is it, at least for me. I ALWAYS
> use colons except once in a while when I print, but even then I like
> colons because the reader needs to know what's headline and what's body
> text.
>
> Personally I'd vote for the ,,bb, ,,bB, and ,,B because it preserves the
> opportunity to use space indented body text. No use leaving users high
> and dry. Personally, I'd do this:
>
> ,,bb indented colon
> ,,bB left just colon
> ,,BB space indent
> ,,b* and ,,B*  reserved for other stuff we may need.
>
> Maybe we can identify other seldom used ,, commands and open them up. We
> could propose them on this mailing list, and if nobody appears to use
> them with daily frequency, we could open them up to get 26 ,, commands
> where we used to have one.

I like this. There are also a great number of additional commands that we
can use. I have experimented with a localleader of just ','. It worked
quite well; except for when I was programming in a functional programming
language within VO. The parameters passed to functions kept triggering VO
commands. So I stopped doing actual coding in VO. I still do design there,
though.

> You know, in the summer of 2001 it NEVER OCCURRED to me that some day
> we'd run out of ,, commands, or I would have put more "digits" on some
> of them.

Has it really been that long? No wonder I feel old. :)

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

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

Steve Litt
On Tuesday 13 October 2009 14:28:07 Noel Henson wrote:
> On Tuesday 13 October 2009, Steve Litt wrote:
[clip]
> > Maybe we can identify other seldom used ,, commands and open them up. We
> > could propose them on this mailing list, and if nobody appears to use
> > them with daily frequency, we could open them up to get 26 ,, commands
> > where we used to have one.
>
> I like this. There are also a great number of additional commands that we
> can use. I have experimented with a localleader of just ','. It worked
> quite well; except for when I was programming in a functional programming
> language within VO.

I considered a prefix (I think we should stop calling it a localleader as not
to bum out the Debian people) of a single comma and rejected it because way
too much legitimate content has a single comma, and it would slow authoring
immensely. Likewise, period period fails because of elipses. As far as I can
see, there's nothing on the keyboard that comes close to comma comma for the
combination of ease and unlikelihood of legitimate use in content. I
considered semicolon semicolon and rejected it because semicolons are all over
the place in C, Pascal, Perl and several other languages, although there are
few legitimate uses of double semicolon so that might be an option. I think
semicolon is harder on the wrists -- something I always keep in mind.

> The parameters passed to functions kept triggering VO
> commands. So I stopped doing actual coding in VO. I still do design there,
> though.
>
> > You know, in the summer of 2001 it NEVER OCCURRED to me that some day
> > we'd run out of ,, commands, or I would have put more "digits" on some
> > of them.
>
> Has it really been that long? No wonder I feel old. :)

:-)  :-)  :-)

Yep.

As everyone suggests these new esoteric features, I sometimes think they
should log a few hours with VO 0.1.3 -- remember, the one where folds occurred
1 line BELOW the headline :-). No body text, no executable lines, no
checkboxes. Funny thing was, I quite happily used 0.1.3 to design my book
"Troubleshooting Techniques of the Successful Technologist." I got used to the
strange folding and the first time Matej called me on it my first thought was
"oh big deal, you can get used to it."

It's a monument to VO's progress that people are asking for configurable
indentation and exact folding. There was a time it was more like this...

"Folding shmolding! Why in my day sonny, we were just grateful to have an
outliner that didn't take 30 seconds to drill down a tree, didn't use
Javascript, and didn't crash every few minutes! And we walked 3 miles to
school in 2 feet of snow!"

Yep, it's been a long time, and we've come a long way.

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
On Tuesday 13 October 2009, Steve Litt wrote:

> On Tuesday 13 October 2009 14:28:07 Noel Henson wrote:
> > On Tuesday 13 October 2009, Steve Litt wrote:
>
> [clip]
>
> > > Maybe we can identify other seldom used ,, commands and open them
> > > up. We could propose them on this mailing list, and if nobody
> > > appears to use them with daily frequency, we could open them up to
> > > get 26 ,, commands where we used to have one.
> >
> > I like this. There are also a great number of additional commands that
> > we can use. I have experimented with a localleader of just ','. It
> > worked quite well; except for when I was programming in a functional
> > programming language within VO.
>
> I considered a prefix (I think we should stop calling it a localleader
> as not to bum out the Debian people) of a single comma and rejected it
> because way too much legitimate content has a single comma, and it would
> slow authoring immensely. Likewise, period period fails because of
> elipses. As far as I can see, there's nothing on the keyboard that comes
> close to comma comma for the combination of ease and unlikelihood of
> legitimate use in content. I considered semicolon semicolon and rejected
> it because semicolons are all over the place in C, Pascal, Perl and
> several other languages, although there are few legitimate uses of
> double semicolon so that might be an option. I think semicolon is harder
> on the wrists -- something I always keep in mind.

Actually, I don't think it would slow authoring down much if at all. The
mapping contexts for almost all VO commands are only for use in normal
mode, not insert mode.

>
> > The parameters passed to functions kept triggering VO
> > commands. So I stopped doing actual coding in VO. I still do design
> > there, though.
> >
> > > You know, in the summer of 2001 it NEVER OCCURRED to me that some
> > > day we'd run out of ,, commands, or I would have put more "digits"
> > > on some of them.
> >
> > Has it really been that long? No wonder I feel old. :)
> >
> :-)  :-)  :-)
>
> Yep.
>
> As everyone suggests these new esoteric features, I sometimes think they
> should log a few hours with VO 0.1.3 -- remember, the one where folds
> occurred 1 line BELOW the headline :-). No body text, no executable
> lines, no checkboxes. Funny thing was, I quite happily used 0.1.3 to
> design my book "Troubleshooting Techniques of the Successful
> Technologist." I got used to the strange folding and the first time
> Matej called me on it my first thought was "oh big deal, you can get
> used to it."
>
> It's a monument to VO's progress that people are asking for configurable
> indentation and exact folding. There was a time it was more like this...
>
> "Folding shmolding! Why in my day sonny, we were just grateful to have
> an outliner that didn't take 30 seconds to drill down a tree, didn't use
> Javascript, and didn't crash every few minutes! And we walked 3 miles to
> school in 2 feet of snow!"
>
> Yep, it's been a long time, and we've come a long way.
>
> SteveT

Somehow I don't think our users are going to let us off the hook anytime
soon. I can just see it now...

10/13/2035 -- VO 5.9.25 Released! --------------------------------------

I know it's been a long time in coming but VO 5.9.25 has finally been
released. Among the new clamored-for features are:

* VR enhanced displays when using Eye-Glove(tm) HD contact lenses

* Look-to-pick / blink-to-click selections and checkbox management

* Enhanced gesture recognition (sub-cutaneous keyboards only)

* Real-time multi-user communication and collaboration
  (Iskin(tm), SubEtha(tm), SubQ(tm), sub-cutaneous phones only)

Some things have been depricated... :(

* colon-space body text

* Any need to follow any format or indentation what-so-ever
  (the VOAI takes are of any formatting issues and the DWIM engine have any
  kind of formatting obsolete - yeah!)


-----------------------------------------------------------------

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 Steve Litt
Steve Litt wrote
As everyone suggests these new esoteric features, I sometimes think they
should log a few hours with VO 0.1.3 -- remember, the one where folds occurred
1 line BELOW the headline :-). No body text, no executable lines, no
checkboxes. Funny thing was, I quite happily used 0.1.3 to design my book
"Troubleshooting Techniques of the Successful Technologist." I got used to the
strange folding and the first time Matej called me on it my first thought was
"oh big deal, you can get used to it."
You bring a smile to my face.  Reminds me a little bit of some of the ed users when vi came out:  "We've been getting along fine seeing just a single line," they said, "Why in the world would we want clutter things up by showing all those lines at once?"

Seriously, though, these "esoteric" features we're talking about are merely bringing VO a little bit closer to having all the outliner features that Grandview and other outliners had 20 years ago.  VO won't ever get there, just because of restrictions from using vim as the base of an outliner.  On the other hand, using vim as the base also adds some flexibility that you can't get in a dedicated outliner.  It's a decent tradeoff.

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

Re: Always-Folded Method

Noel Henson
On Tuesday 13 October 2009, hsitz wrote:

> Steve Litt wrote:
> > As everyone suggests these new esoteric features, I sometimes think
> > they should log a few hours with VO 0.1.3 -- remember, the one where
> > folds occurred
> > 1 line BELOW the headline :-). No body text, no executable lines, no
> > checkboxes. Funny thing was, I quite happily used 0.1.3 to design my
> > book "Troubleshooting Techniques of the Successful Technologist." I
> > got used to the
> > strange folding and the first time Matej called me on it my first
> > thought was
> > "oh big deal, you can get used to it."
>
> You bring a smile to my face.  Reminds me a little bit of some of the ed
> users when vi came out:  "We've been getting along fine seeing just a
> single line," they said, "Why in the world would we want clutter things
> up by showing all those lines at once?"
>
> Seriously, though, these "esoteric" features we're talking about are
> merely bringing VO a little bit closer to having all the outliner
> features that Grandview and other outliners had 20 years ago.  VO won't
> ever get there, just because of restrictions from using vim as the base
> of an outliner.  On the other hand, using vim as the base also adds some
> flexibility that you can't get in a dedicated outliner.  It's a decent
> tradeoff.
>
> -- Herb

I have a feeling that sometime, perhaps soon, the excellent programmers
that are VO users out there may want to collaborate on a really good,
cross-platform outliner. Then, perhaps, we can surpass the likes of
MaxThink and Grandview.

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
This post was updated on .
Noel Henson wrote
I have a feeling that sometime, perhaps soon, the excellent programmers
that are VO users out there may want to collaborate on a really good,
cross-platform outliner. Then, perhaps, we can surpass the likes of
MaxThink and Grandview.

Noel
Oh my.  The thought of building a nice desktop outliner from scratch would give me nightmares from the thought of a never-ending project taking over my life.  The idea of building a simple VO-compatible outliner built from available open source outline-oriented components seems a little more doable.

I think Steve L. mentioned similar idea a week or two ago, and said he might want to build it in FreePascal.  FreePascal is a clone of Delphi, which is what vast majority of my programming experience is in.  ObjectPascal seems to me a very beautiful language.  If I had to give others a sense of it I would say that C/C++ is to Perl as Delphi/ObjectPascal is to Python.  ObjectPascal is elegant, clean, easy to read, but a bit more verbose than c/c++ and generally lacking some of the nice but tricky idioms that come naturally in good c/c++.  People sometimes balk at the 'begin' and 'end' block tokens, or from their memory of the deficiencies of early versions of Pascal.  ObjectPascal still has the 'begin' and 'end' tokens, but apart from that most all the original problems of Pascal as a working (i.e, not educational) language have been addressed, and the object layer was nicely added without increasing language complexity by much.

FreePascal is pretty solid, but its IDE and library of desktop components still have a few rough edges, at least compared to Delphi.  People have been using FPC/Lazarus for fairly substantial projects for years, so I guess they can't be too bad.

The component libraries available for Delphi and to lesser extent FreePascal/Lazarus are what really make the languages and environments compelling as desktop app solutions.  Ideally, you'd want to find a nice component building-block that will do most of the work and then just revise functionality to make an app.  There's one open source component that might greatly simplify the creation of a nice desktop outliner:  VirtualTreeView.  It's been around for years, was one of first major components ported from Delphi to FPC/Lazarus, and is quite a nifty piece of work.  (It's even been used as one of components to build Delphi's IDE.)  

Here's an example of an outliner-type app using VirtualTreeview:
http://www.soft-gems.net/images/stories/screen-shots/Taonotes3d.gif

Here's picture of an xml editor that uses VirtualTreeView:
http://www.soft-gems.net/images/stories/screen-shots/xmlBlueprint.gif

Another outliner-type application of VirtualTreeView:
http://www.soft-gems.net/images/stories/screen-shots/Informaizer.gif

Here's link to VirtualTreeView page (and a second to the "VirtualTreeView gallery".  Most of the screenshots you see don't look much like outliners.  That's mostly just because the component is rich and full of features; I think most of the outliner functionality is built in and would just need to be harnessed:
http://www.soft-gems.net/index.php?option=com_content&task=view&id=12&Itemid=33
http://www.soft-gems.net/index.php?option=com_content&task=view&id=16&Itemid=33

Here's link to site for the TaoNotes outliner app that's built using VirtualTreeView.  It has all sorts of gobbledygook that I suspect most VO people would hate.  But it gives some idea of what is possible.  I think building an outliner uses VirtualTreeView as a base would be sort of the opposite of building an outliner using vim as the base.  VO takes vim, an editor, and adds outlining functionality.  An app built with VirtualTreeview would start with VirtualTreeView, an outlining component, and try to make it work more like an editor:
http://actitrend.fre3.com/index.html
Reply | Threaded
Open this post in threaded view
|

Re: Always-Folded Method

David J Patrick-2
In reply to this post by Noel Henson
Noel Henson wrote:

> I have a feeling that sometime, perhaps soon, the excellent programmers
> that are VO users out there may want to collaborate on a really good,
> cross-platform outliner.
yes, shortly after perfecting vimoutliner, which will never happen.
  Then, perhaps, we can surpass the likes of
> MaxThink and Grandview.
I never used either of those, but to surpass Thought (Traveling
Software, 1985) in features and/or usability, would happen only if said
outline programmers secluded themselves in the mountains and forgot the
concept of time, thinking in pure code. No, really, it was near
perfection in under 8k. Vimoutliner of today only starts to edge it out
on exportability. No, for me, I will continue on my path to grok vim and
it's splendors. How many years have you guys been making it and we guys
using it ? Well after all that time I feel the code maturing, and see a
community has grown up around it. If you guys wanna make a
multi-platform gui app, knock yerselves out, but I've found my platform
and am almost unstuck from the gui.
VO for me, please,
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

Steve Litt
In reply to this post by Noel Henson
On Tuesday 13 October 2009 16:08:10 Noel Henson wrote:

> On Tuesday 13 October 2009, hsitz wrote:
> > Steve Litt wrote:
> > > As everyone suggests these new esoteric features, I sometimes think
> > > they should log a few hours with VO 0.1.3 -- remember, the one where
> > > folds occurred
> > > 1 line BELOW the headline :-). No body text, no executable lines, no
> > > checkboxes. Funny thing was, I quite happily used 0.1.3 to design my
> > > book "Troubleshooting Techniques of the Successful Technologist." I
> > > got used to the
> > > strange folding and the first time Matej called me on it my first
> > > thought was
> > > "oh big deal, you can get used to it."
> >
> > You bring a smile to my face.  Reminds me a little bit of some of the ed
> > users when vi came out:  "We've been getting along fine seeing just a
> > single line," they said, "Why in the world would we want clutter things
> > up by showing all those lines at once?"
> >
> > Seriously, though, these "esoteric" features we're talking about are
> > merely bringing VO a little bit closer to having all the outliner
> > features that Grandview and other outliners had 20 years ago.  VO won't
> > ever get there, just because of restrictions from using vim as the base
> > of an outliner.  On the other hand, using vim as the base also adds some
> > flexibility that you can't get in a dedicated outliner.  It's a decent
> > tradeoff.
> >
> > -- Herb
>
> I have a feeling that sometime, perhaps soon, the excellent programmers
> that are VO users out there may want to collaborate on a really good,
> cross-platform outliner. Then, perhaps, we can surpass the likes of
> MaxThink and Grandview.
>
> Noel

I used Grandview for 3 or 4 years in the early 1990's. Frankly, I think we
surpassed Grandview the day we got body text (January 2003). My memory of
Grandview was wrist twisting keystrokes that were slow as molassas . I
understand it had lots of features I never used, but as far as core outlining
features, its only unmatched feature was cloning, and IIRC Grandview didn't
have anything like our executable lines.

My view is that all the features in the world mean little if the interface is
so clunky you forget what you were thinking while you're playing twister
getting the info into the outliner.

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

David J Patrick-2
In reply to this post by David J Patrick-2
David J Patrick wrote:
> yes, shortly after perfecting vimoutliner, which will never happen.

I'd like to put this in context; I am an imperfectionist, and don't
believe any software beyond "hello world" can ever be perfect.
So the previous comment should not me construed as a direct swipe at VO,
but more of recognizing and accepting imperfections all around us.
[hovers gently over the mat]
.. and I'm totally good with that.
_______________________________________________
VimOutliner mailing list
[hidden email]
http://www.lists.vimoutliner.org/mailman/listinfo
1234