wondering about vimoutliner package status AND introducing taskwarrior

[David J Patrick-2]

Hi VO fans !
seems to have been sort of quiet on the list, and I have been unclear as
to what the status is of the proposed fresh and new vimoutliner package.
I ask for selfish reasons; while I've been using vimoutliner for years,
I'm still learning the winders of vim, and want to be using the very
best collection of vimoutliner development.

Meanwhile, I have also been a long-time user of a todotxt sort of CLI
task manager, called "task" (by Paul Beckingham) and find myself after
having been such a demanding user and suggester, that I have been
declared (by Paul) as the designer of the future iterations, now called
"taskwarrior". (now housed at taskwarrior.org) and I fully intend to a)
see task developed into an amazing task manager, and b) continue to use
VO for all it's worth, in conjunction with task. As I scramble along
this path, I'll be making requests for tweaks and enhancements, and I
hope that at least some of you will join me in making these two great
apps work seamlessly.

In regards to vimoutliner.org upgrades; how is the drupalization going ?
I have access to a rather gaggle of drupal developers, and might unleash
a few, if it would help with the upgrade. Either that OR, I would be
happy to have another instance of Redmine put up, like we are using
(quite happily) for taskwarrior. I would highly recommend Redmine (on my
server, or yours) for a software development site (over drupal, which I
use for linuxcaffe.com) as the ticket tracking system, and the wiki, are
top-notch.

I do hope to see the vimoutliner state-of-the-art packaged soon, as the
current goodness is somewhat jumbled and the "peeps" need a good
outliner. Thanks for entertaining my ravings,
djp
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo/vimoutliner

[Scott Scriven-2]

* David J Patrick <djp@...> wrote:

> Meanwhile, I have also been a long-time user of a todotxt sort
> of CLI  task manager, called "task" (by Paul Beckingham) and
> find myself after  having been such a demanding user and
> suggester, that I have been  declared (by Paul) as the designer
> of the future iterations, now called  "taskwarrior". (now
> housed at taskwarrior.org) and I fully intend to a)  see task
> developed into an amazing task manager, and b) continue to use  
> VO for all it's worth, in conjunction with task. As I scramble
> along  this path, I'll be making requests for tweaks and
> enhancements, and I  hope that at least some of you will join
> me in making these two great  apps work seamlessly.

It looks neat.  I don't know how much I'd use the CLI-only
version much, since, um, I tend to have so many tasks on my list
that it doesn't fit in my xterm scrollback buffer.  But the
curses UI looks interesting.

I'm curious how you plan to integrate VO and Taskwarrior.  I like
VO's file format and the ability to have todo.otl files all over
my filesystem (in the same dir as the project it represents).  
It's also nice being able to edit the files with vim.  But it
doesn't look like Task works that way.  So, I'm curious if those  
things might be possible someday.

Also, I don't know if you're interested, but I did finally get
around to adding a curses UI to TKDO, a few months ago.  I
haven't done a proper release yet, but all I need to do is pack
it up and announce it.  Maybe update some docs, too.  For now, it
requires bzr to get to that version (bzr branch lp:tkdo).

This is its site, in case it's of any interest:
http://toykeeper.net/programs/tkdo/

I suppose I should make some screenshots or screencasts of it
sometime...  a lot easier to show what it does with examples.


-- Scott
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Anders Bo Rasmussen-2]

On Thu, Sep 3, 2009 at 10:00 AM, Scott Scriven
<vimoutliner@...> wrote:
> Also, I don't know if you're interested, but I did finally get
> around to adding a curses UI to TKDO, a few months ago.  I
> haven't done a proper release yet, but all I need to do is pack
> it up and announce it.  Maybe update some docs, too.  For now, it
> requires bzr to get to that version (bzr branch lp:tkdo).
>
> This is its site, in case it's of any interest:
> http://toykeeper.net/programs/tkdo/

Hi. I've started to use tkdo and have some feedback.

It is a good step forward from my former solution. Before I simply put
a <p:1> on lines that I regarded as a priority 1 task. Done tasks was
marked with <done>. Then I ran my own otlsort with parameters so
<done> tasks went to the bottom, while the rest was sorted by
priority. Of course the parent-child relations in the tree was never
broken. It had the limitation that there was (explicit) dead lines, i
just changed priorities when things started to get more important. I
would like a standardized way to set variables for nodes in a vim
outline, so things like otlsort could work with these variables. But
that is another story. Here are the things that popped up while I've
started to use tkdo:

I like tkdo as it is the best I've seen so far for managing my tasks,
and I'll continue to use it.


After unpacking the .tar.gz it is necessary to remove the call to bzr
in the Makefile in order to run "make install"


I see some warnings coming on the console when starting tkdo (one of
them only comes when you have no tasks):
/home/fuzz/local/tkdo/usr/bin/tkdo:1913: DeprecationWarning: use gtk.UIManager
  else: factory = g.ItemFactory(g.MenuBar, '<main>', accel_group)
/home/fuzz/local/tkdo/usr/bin/tkdo:1752: GtkWarning:
gtk_tree_view_set_cursor_on_cell: assertion `tre
e_view->priv->tree != NULL' failed
  self.treeview.set_cursor(0)
/home/fuzz/local/tkdo/usr/bin/tkdo:1686: GtkWarning:
gtk_tree_view_set_cursor_on_cell: assertion `tre
e_view->priv->tree != NULL' failed
  self.treeview.set_cursor(0)


When writing/modifying tasks in vim, it is hard to not write invalid
syntax e.g.:
[x] I have to do this
[ ] I also have to do this
The problem is that tkdo simply ignore these lines. Therefore it is
possible that the future tasks never shows up because of a syntax
error. I don't know what is the right solution to this. Maybe some
syntax highlighting in vim for tkdo-files or an option/command to tkdo
to warn about lines that are not recognized by tkdo?

Sometimes it would be nice to view all tasks, that doesn't require a
resource. E.g. filtering by not @internet. This could e.g. be done by
adding a "not-column" of check boxes in View->Filter by Context(List)

It would also be good with filtering on the command line. E.g. only
get tasks with @internet. But this is connected to my wish for having
a standardized way to set variables. If it was standardized it would
be possible to do this with a otlgrep that had nothing to do with tkdo
(if tkdo could read a task file from a pipe).

I currently have more than 100 tasks with no deadline. When I enter a
deadline and a lead time, the task goes to the bottom (below the 99
tasks without a deadline), until a lot of the lead time has past. I
think that my tasks that has a deadline and where we have reached the
lead time should be above the tasks that has no deadline at all.

It would be good with an option to add other columns in the gui. E.g.
Due date, (X)done date and Importance, task file, line number, etc. It
would also be good to have this as an option to the list-command. This
would make it easy to combine the tkdo-list command with other
programs.

When snoozing first item in next-type, tkdo shows the second item
instead. I think this must be a bug?

I have the typical problem when having a file opened in two programs,
in this case tkdo and vim, I risk loosing my changes in one program
when not taking care to reload the file in one of the programs while
having made changes in the other. An auto-update function that auto
reloads the task files in tkdo when the have been changed would be
good. So would a read-only option be.

I prefer changing files in Vim and not in the gui. This is not because
tkdo is a bad gui, but because I prefer the consistent way of entering
code, mail and other text with the same user interface. So some
vim-macros/functions that does the same as in the gui would be good.
E.g. a macro that sets the task under the cursor as done by making an
X in [_] and sets the X variable to the current date. A common vim
functions that sets/updates a variable for the task under the cursor
would be great.

I hope some of these observations can be used for something.

Regards
 Anders Bo Rasmussen
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Scott Scriven-2]

* Anders Bo Rasmussen <fuzz@...> wrote:
> When writing/modifying tasks in vim, it is hard to not write
> invalid syntax e.g.:
> [x] I have to do this
> [ ] I also have to do this

That's an issue with vimoutliner.  I could add support for those
easily in TKDO, but have been trying to stick to the same data
format as VO.

The recommended way to create tasks in VO is to enter the text
for the task then press ,,cb to turn it into a checkbox.  Then,
when marking it completed, press ,,cx to toggle the X.  These are
pretty much out of my control.

> Maybe some syntax highlighting in vim for tkdo-files

Er, that's part of what vimoutliner does.  I'm not aware of an
option to colorize task lines differently than regular nodes, but
perhaps some of the VO team knows how?

> some vim-macros/functions that does the same as in the gui
> would be good.  E.g. a macro that sets the task under the
> cursor as done by making an X in [_] and sets the X variable to
> the current date.

That's not an easy thing to do, since tkdo and vimoutliner are
separate programs.  I don't really expect the VO crew to accept
patches for tkdo support.  However, I could include something in
tkdo's contrib/ dir if someone has code to share.  Or if enough
people are interested, we could work out a common solution for
both programs.


-- Scott
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Monday 28 September 2009, Scott Scriven wrote:
> * Anders Bo Rasmussen <fuzz@...> wrote:
> > When writing/modifying tasks in vim, it is hard to not write
> > invalid syntax e.g.:
> > [x] I have to do this
> > [ ] I also have to do this

Actually the possible checkboxes are:
[X] task complete
[_] task incomplete
[-] task (and subtree) ignored

>
> That's an issue with vimoutliner.  I could add support for those
> easily in TKDO, but have been trying to stick to the same data
> format as VO.
>
> The recommended way to create tasks in VO is to enter the text
> for the task then press ,,cb to turn it into a checkbox.  Then,
> when marking it completed, press ,,cx to toggle the X.  These are
> pretty much out of my control.
>
> > Maybe some syntax highlighting in vim for tkdo-files
>
> Er, that's part of what vimoutliner does.  I'm not aware of an
> option to colorize task lines differently than regular nodes, but
> perhaps some of the VO team knows how?

Hmmm. What kind of coloring were you thinking of? (I assume for checkbox
lines)

>
> > some vim-macros/functions that does the same as in the gui
> > would be good.  E.g. a macro that sets the task under the
> > cursor as done by making an X in [_] and sets the X variable to
> > the current date.
>
> That's not an easy thing to do, since tkdo and vimoutliner are
> separate programs.  I don't really expect the VO crew to accept
> patches for tkdo support.  However, I could include something in
> tkdo's contrib/ dir if someone has code to share.  Or if enough
> people are interested, we could work out a common solution for
> both programs.
>

I don't know that we wouldn't. A large part of VO use is tracking projects.  
And VO does have a plugin architecture.

>
> -- Scott
> _______________________________________________
> VimOutliner mailing list
> VimOutliner@...
> http://www.lists.vimoutliner.org/mailman/listinfo

Noel

--

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

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Scott Scriven-2]

* Noel Henson <noel@...> wrote:

> > > some vim-macros/functions that does the same as in the gui
> > > would be good.  E.g. a macro that sets the task under the
> > > cursor as done by making an X in [_] and sets the X
> > > variable to the current date.
> >
> > That's not an easy thing to do, since tkdo and vimoutliner
> > are separate programs.  I don't really expect the VO crew to
> > accept patches for tkdo support.  However, I could include
> > something in tkdo's contrib/ dir if someone has code to
> > share.  Or if enough people are interested, we could work out
> > a common solution for both programs.
>
> I don't know that we wouldn't. A large part of VO use is
> tracking projects.  And VO does have a plugin architecture.

It might be kind of a pain to keep the behavior in sync between
two different implementations.  When the user hits 'x' in TKDO,
the following happens:

  - The [_] becomes [X] (or vice versa).
  - Parent tasks are updated if necessary.
  - The "last completed" variable gets set to the current date,
    if the new state is [X].  However, it only gets saved in the
    .otl file if there is other metadata on the task.
  - An entry is written to ~/.tkdo/action_log.
  - If the task is recurring:
    - Set a new due date (if using fixed dates).
    - Put the task in "snoozed" mode so it will hide until it
      hits its lead time.  Mark it as [Z].

Most of it is pretty simple, but some parts don't quite seem
appropriate for VO.


-- Scott
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Monday 28 September 2009, Scott Scriven wrote:

> * Noel Henson <noel@...> wrote:
> > > > some vim-macros/functions that does the same as in the gui
> > > > would be good.  E.g. a macro that sets the task under the
> > > > cursor as done by making an X in [_] and sets the X
> > > > variable to the current date.
> > >
> > > That's not an easy thing to do, since tkdo and vimoutliner
> > > are separate programs.  I don't really expect the VO crew to
> > > accept patches for tkdo support.  However, I could include
> > > something in tkdo's contrib/ dir if someone has code to
> > > share.  Or if enough people are interested, we could work out
> > > a common solution for both programs.
> >
> > I don't know that we wouldn't. A large part of VO use is
> > tracking projects.  And VO does have a plugin architecture.
>
> It might be kind of a pain to keep the behavior in sync between
> two different implementations.  When the user hits 'x' in TKDO,
> the following happens:
>
>   - The [_] becomes [X] (or vice versa).
>   - Parent tasks are updated if necessary.
>   - The "last completed" variable gets set to the current date,
>     if the new state is [X].  However, it only gets saved in the
>     .otl file if there is other metadata on the task.
>   - An entry is written to ~/.tkdo/action_log.
>   - If the task is recurring:
>     - Set a new due date (if using fixed dates).
>     - Put the task in "snoozed" mode so it will hide until it
>       hits its lead time.  Mark it as [Z].
>
> Most of it is pretty simple, but some parts don't quite seem
> appropriate for VO.
>
>
> -- Scott
> _______________________________________________
> VimOutliner mailing list
> VimOutliner@...
> http://www.lists.vimoutliner.org/mailman/listinfo

Scott,

It might be possible for the user to simply not load the checkboxes plugin
and load the tkdo plugin. Checkbox behavior is an add-on to the VO after
all.

Noel

--

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

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Anders Bo Rasmussen-2]

On Mon, Sep 28, 2009 at 09:35:15AM -0600, Scott Scriven wrote:
> > i just changed priorities when things started to get more
> > important.
>
> That sounds like it would take a lot of extra time.

Yes. It took some time, so I ended up having one task file and
one calendar.

> > The problem is that tkdo simply ignore these lines. Therefore
> > it is possible that the future tasks never shows up because of
> > a syntax error.
>
> Does it really happen very often?  VO has key bindings to add,
> remove, and toggle checkboxes...

Ah. As Noel says later in the thread it is possible to not use the
checkbox-plugin - which is what I do. I'll turn it on.

> That's an interesting idea.  I'll probably add it, perhaps using
> a relatively standard '!' syntax.  So, you could type:
>
>   /!@internet

Yes, that would be very intuitive to use.

> > I currently have more than 100 tasks with no deadline. When I
> > enter a deadline and a lead time, the task goes to the bottom
> > (below the 99 tasks without a deadline), until a lot of the
> > lead time has past.
>
> That's kind of intentional.  It just means the task exists but
> isn't very important yet.  It stays hidden until the beginning of
> the lead time, then rises up the list until it either gets
> completed or hits its maximum overdue value.  The actual details
> depend on your configuration, but the default is:
>
>   due_bonus = 1.5
>   max_overdue = 1.75
>
> So, if an item is normally 100, it will get a base score of 150
> if it has a due date.  The score will rise like this:
>
>   Zzz T=-1    (before lead time)
>     0 T=0     (beginning of lead time)
>    37 T=0.25  (1/4 of the way through the lead time)
>    50 T=0.333
>    75 T=0.5   (halfway through lead time)
>   100 T=0.667
>   150 T=1     (due date)
>   175 T=2     (way past due)
>
> Perhaps you would prefer a different rate for items to rise?  You
> could try...
>
>   due_bonus = 2.0
>   max_overdue = 3.0
>
>     0 T=0
>    50 T=0.25
>   100 T=0.5
>   200 T=1.0
>   300 T=2.0
>
> That way, it catches up to its non-due siblings a halfway through
> its lead time, then races way ahead afterward.

Ok. That seems to be the way to go. I'll be setting the lead time to the
double of the value I use now.

> > It would be good with an option to add other columns in the
> > gui. E.g.  Due date, (X)done date and Importance, task file,
> > line number, etc.
>
> The title of the task file is already included on each line.  I
> can see the due date being useful, though that's kind of what the
> 'cal' command is for.  I keep my 'tkdo cal' in conky where it's
> always visible, so I guess I haven't needed it elsewhere.  
> Perhaps it should be more visible.
>
> I've intentionally de-emphasized the "importance" value,
> encouraging people to use other approaches to prioritize tasks.  
> Changing the order in the outline files is a simple way to do it,
> as is toggling "active" status on things you intend to do soon.  
> Or, snooze the items/projects/files you don't intend to do soon.
>
> After using PyGTD for a while (which relied almost entirely on
> importance and urgency values to sort items), I've been avoiding
> number tweaking.  It got really annoying and was one of the main
> reasons I stopped using PyGTD.
>
> Could you describe how it would help to have columns for done
> date, importance, and line number?

It could give different overviews if it was possible to search by the
columns as well. E.g. if I would like to find the tasks with the
heighest importance, the next due date, order as they appear in the
files or order done tasks as there were done.

> > It would also be good to have this as an option to the
> > list-command. This would make it easy to combine the tkdo-list
> > command with other programs.
>
> It would help to have a use case with an example of desired
> behavior.

E.g. if I wanted to have the last 10 tasks mask as done:

tkdo list -attr 'done-date,name' | sort | tail 10

to get the the last 10 done tasks.

In general I was more thinking it could be usefull for automatic mails,
programs like conky, etc. to have easy access to the extra fields.

/anders
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Anders Bo Rasmussen-2]

On Mon, Sep 28, 2009 at 07:41:20AM -0700, Noel Henson wrote:
> > > Maybe some syntax highlighting in vim for tkdo-files
> >
> > Er, that's part of what vimoutliner does.  I'm not aware of an
> > option to colorize task lines differently than regular nodes, but
> > perhaps some of the VO team knows how?
>
> Hmmm. What kind of coloring were you thinking of? (I assume for checkbox
> lines)

I think it would be enough if the [X], [_], [Z] was colored in a
different color. Then it would be easy to see which lines would be
accepted by tkdo.

> > > some vim-macros/functions that does the same as in the gui
> > > would be good.  E.g. a macro that sets the task under the
> > > cursor as done by making an X in [_] and sets the X variable to
> > > the current date.
> >
> > That's not an easy thing to do, since tkdo and vimoutliner are
> > separate programs.  I don't really expect the VO crew to accept
> > patches for tkdo support.  However, I could include something in
> > tkdo's contrib/ dir if someone has code to share.  Or if enough
> > people are interested, we could work out a common solution for
> > both programs.
> >
>
> I don't know that we wouldn't. A large part of VO use is tracking projects.  
> And VO does have a plugin architecture.

If there was a centralized way in vimoutliner for how to store
attributes in a node, then a lot of the code would belong to
vimoutliner. The rest could fit into a tkdo vimoutliner-plugin.

/Anders
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Saturday 03 October 2009, Anders Bo Rasmussen wrote:

> On Mon, Sep 28, 2009 at 07:41:20AM -0700, Noel Henson wrote:
> > > > Maybe some syntax highlighting in vim for tkdo-files
> > >
> > > Er, that's part of what vimoutliner does.  I'm not aware of an
> > > option to colorize task lines differently than regular nodes, but
> > > perhaps some of the VO team knows how?
> >
> > Hmmm. What kind of coloring were you thinking of? (I assume for
> > checkbox lines)
>
> I think it would be enough if the [X], [_], [Z] was colored in a
> different color. Then it would be easy to see which lines would be
> accepted by tkdo.

This could be done by providing an extended syntax file.

>
> > > > some vim-macros/functions that does the same as in the gui
> > > > would be good.  E.g. a macro that sets the task under the
> > > > cursor as done by making an X in [_] and sets the X variable to
> > > > the current date.
> > >
> > > That's not an easy thing to do, since tkdo and vimoutliner are
> > > separate programs.  I don't really expect the VO crew to accept
> > > patches for tkdo support.  However, I could include something in
> > > tkdo's contrib/ dir if someone has code to share.  Or if enough
> > > people are interested, we could work out a common solution for
> > > both programs.
> >
> > I don't know that we wouldn't. A large part of VO use is tracking
> > projects. And VO does have a plugin architecture.
>
> If there was a centralized way in vimoutliner for how to store
> attributes in a node, then a lot of the code would belong to
> vimoutliner. The rest could fit into a tkdo vimoutliner-plugin.

Ah, here in lies the problem with many things we'd like to do with VO: the
lack of a standard way to store meta data. It would be even cooler if the
meta data could be hidden from view, but that's another story.

>
> /Anders
> _______________________________________________
> VimOutliner mailing list
> VimOutliner@...
> http://www.lists.vimoutliner.org/mailman/listinfo

Noel

--

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

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Scott Scriven-2]

* Noel Henson <noel@...> wrote:
> > If there was a centralized way in vimoutliner for how to
> > store attributes in a node, then a lot of the code would
> > belong to vimoutliner. The rest could fit into a tkdo
> > vimoutliner-plugin.
>
> Ah, here in lies the problem with many things we'd like to do
> with VO: the lack of a standard way to store meta data. It
> would be even cooler if the meta data could be hidden from
> view, but that's another story.

If people come up with and agree on a syntax for arbitrary
metadata, I'll be happy to add support for it.  Until then, I'll
stick with what I've been using -- a single line with the format
of "; NAMESPACE: var1=value1 var2=value2 bool1 bool2".

For example:
    [_] Do something important every week (or so) at home <--
        ; TKDO: I=90 D=+1w @home active
        "I=90" and "D=+1w" are arbitrary name/value pairs.
        "@home" and "active" are simple boolean options.  The @
            sign is part of the variable name, not any sort of
            special syntax.

Sometimes I'm kind of cheating though.  Some values are stored in
the task title, not the metadata line.  Like, I'm using the "<--"
to indicate a task is "active", instead of the "active" keyword
on the next line.  And at some point I'll probably move all
contexts (@home) to the title line, for easier grepping.


It's worth mentioning that a syntax alone isn't a complete
solution.  It might also be worthwhile to define the names and
meanings of some common attributes.


-- Scott
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Anders Bo Rasmussen-2]

On Sun, Oct 04, 2009 at 01:45:55AM -0600, Scott Scriven wrote:

> > > If there was a centralized way in vimoutliner for how to
> > > store attributes in a node, then a lot of the code would
> > > belong to vimoutliner. The rest could fit into a tkdo
> > > vimoutliner-plugin.
> >
> > Ah, here in lies the problem with many things we'd like to do
> > with VO: the lack of a standard way to store meta data. It
> > would be even cooler if the meta data could be hidden from
> > view, but that's another story.
>
> If people come up with and agree on a syntax for arbitrary
> metadata, I'll be happy to add support for it.  Until then, I'll
> stick with what I've been using -- a single line with the format
> of "; NAMESPACE: var1=value1 var2=value2 bool1 bool2".

I've used a syntax like:

Task1 <p:2.5>
Task2 <p:3>
Task3 <done>

With namespaces it would be <TKDO.I=90>, <TKDO.@home> etc.

I don't know if it is better or worse. But it is a different way to do
it.

I think it is important that you can have several namespaces for one
node. Your syntax could easy be extended to have multiple namespaces,
like:

; TKDO: I=90 FORMAT:bold

But values without namespace is somewhat harder to represent.

>
> For example:
>     [_] Do something important every week (or so) at home <--
>         ; TKDO: I=90 D=+1w @home active
>         "I=90" and "D=+1w" are arbitrary name/value pairs.
>         "@home" and "active" are simple boolean options.  The @
>             sign is part of the variable name, not any sort of
>             special syntax.
>
> Sometimes I'm kind of cheating though.  Some values are stored in
> the task title, not the metadata line.  Like, I'm using the "<--"
> to indicate a task is "active", instead of the "active" keyword
> on the next line.  And at some point I'll probably move all
> contexts (@home) to the title line, for easier grepping.

I think greping could be done with an otlgrep.

> It's worth mentioning that a syntax alone isn't a complete
> solution.  It might also be worthwhile to define the names and
> meanings of some common attributes.

I think it is a good idea. But as a first step we should IMHO get defined how
the attributes should look like. This would make it possible to make things
like otlsort, otlgrep and set/get-functions in vim.

So what is important for the attribute syntax? I can think of:

Easy to write in vim
        :Even though set/get-functions existed, it would be good to be able to
        :easily insert the values by hand
Namespace support
        :For programs like tkdo it is probably a good idea to have it's own
        :namespace to avoid name clash for other attributes the user might have.
No namespace support
        :For the end user it might be anoying to have to specify a namespace. So
        :it might be good to be able to have attributes without a namespace.
Easy to see if it has the correct syntax
        :It would be good if it was easy for a human to see if an attribute has
        :the correct syntax without having to rely on syntax highlighting.
Easy to parse
        :Since there is both perl,python,etc. programs that should be able to
        :parse the attributes, they should be easy to parse.

/Anders
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[David J Patrick-2]

Anders Bo Rasmussen wrote:

> On Sun, Oct 04, 2009 at 01:45:55AM -0600, Scott Scriven wrote:
>>>> If there was a centralized way in vimoutliner for how to
>>>> store attributes in a node, then a lot of the code would
>>>> belong to vimoutliner. The rest could fit into a tkdo
>>>> vimoutliner-plugin.
>>> Ah, here in lies the problem with many things we'd like to do
>>> with VO: the lack of a standard way to store meta data. It
>>> would be even cooler if the meta data could be hidden from
>>> view, but that's another story.
>> If people come up with and agree on a syntax for arbitrary
>> metadata, I'll be happy to add support for it.  Until then, I'll
>> stick with what I've been using -- a single line with the format
>> of "; NAMESPACE: var1=value1 var2=value2 bool1 bool2".

Our own hilf has been using metadata thusly;

Heading
        ;{key:value}
        : body text

for several things, including handling remind statements (brilliant
implementation) and I have adopted it for general metadata use,
including ;{author:Me} and ;{title:MyBook} that get passed to LaTeX
output via (modified) otl2aft.awk. I think it's a clean and clear as
anything. Herb has also written some exceptionally good syntax files
that gives these metadata lines special folding behavior. We (at
linuxcaffe) have been enhancing this output chain and I am finally
seeing hardcopy that doesn't suck.

There is something broken about this development community when an
outlining veteran with clear ideas backed up with working
implementations is basically ignored while the core team debates how
ELSE those things might be approached. I urge you all once again to
re-consider his concepts and code. I can vouch for the fact that his
stuff works as advertised, and have been enjoying real productivity
gains while you fellahs have been tossing around early ideas.

Outlining in vim is important, and vimoutliner has been a mainstay for
me for years, but right now I see nothing but fragmentation and
everybody wandering off in different directions.

Sorry if I sound a bit peevish, but outlining is central to my process,
and it doesn't look like the well-thought-out solutions at hand, are
even being considered, and those things that ARE being considered are
unclear and half-baked.

exasperatedly yours,
djp
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Sunday 04 October 2009, David J Patrick wrote:

> Anders Bo Rasmussen wrote:
> > On Sun, Oct 04, 2009 at 01:45:55AM -0600, Scott Scriven wrote:
> >>>> If there was a centralized way in vimoutliner for how to
> >>>> store attributes in a node, then a lot of the code would
> >>>> belong to vimoutliner. The rest could fit into a tkdo
> >>>> vimoutliner-plugin.
> >>>
> >>> Ah, here in lies the problem with many things we'd like to do
> >>> with VO: the lack of a standard way to store meta data. It
> >>> would be even cooler if the meta data could be hidden from
> >>> view, but that's another story.
> >>
> >> If people come up with and agree on a syntax for arbitrary
> >> metadata, I'll be happy to add support for it.  Until then, I'll
> >> stick with what I've been using -- a single line with the format
> >> of "; NAMESPACE: var1=value1 var2=value2 bool1 bool2".
>
> Our own hilf has been using metadata thusly;
>
> Heading
> ;{key:value}
>
> : body text
>

You have pointed out a feature that many have either forgotten over the
years or simply not used. There are more objects in VO than headings,
checkboxes and body text. There are:

; preformatted text blocks - I usually use them for code snippets
> user-defined text block - works just like body text
< user-defined, preformatted text blocks - works just like ;

You can even modify the foldtext expression to make any of these say
'metadata' or 'TKDO' when folded.

Perhaps lines starting with either of the latter two or perhaps we define
a new object that is a line starting with one of these: !, ~, ', `, & or
something else.

> for several things, including handling remind statements (brilliant
> implementation) and I have adopted it for general metadata use,
> including ;{author:Me} and ;{title:MyBook} that get passed to LaTeX
> output via (modified) otl2aft.awk. I think it's a clean and clear as
> anything. Herb has also written some exceptionally good syntax files
> that gives these metadata lines special folding behavior. We (at
> linuxcaffe) have been enhancing this output chain and I am finally
> seeing hardcopy that doesn't suck.
>
> There is something broken about this development community when an
> outlining veteran with clear ideas backed up with working
> implementations is basically ignored while the core team debates how
> ELSE those things might be approached. I urge you all once again to
> re-consider his concepts and code. I can vouch for the fact that his
> stuff works as advertised, and have been enjoying real productivity
> gains while you fellahs have been tossing around early ideas.

First, whose code are we referring to?

Second, VO is just supposed to be an outliner. Text objects have been
defined so that others can use them any way they see fit; just as you are
using ';' to indicate metadata. We have tried to keep VO a simple tool.  
Even checkboxes are not really part of VO. They are just another plugin.

>
> Outlining in vim is important, and vimoutliner has been a mainstay for
> me for years, but right now I see nothing but fragmentation and
> everybody wandering off in different directions.

I see. If you look back over the years, this is how VO development seems to
be done. We through a bunch of stuff out there, see how people react to it,
modify it, determine if it's even useful and then make changes accordingly.  
This is a software project that has evolved according to what people need
to get done. Especially for me. I worked with Steve Litt initially to
create a tool we both needed. Matej came in with some good suggestions and
code snippets. And VO evolved a bit more. Then I needed to create a 50+
slide presentation with an impossible deadline so I created otl2html.py
with and htmlslides output format. And VO evloved. Then I needed to take
a 2800+ line outline and create some reports for a client that had less
detail; thus was born otlhead. And VO evloved a bit more. But the core of
VO stayed basically the same.

> Sorry if I sound a bit peevish, but outlining is central to my process,
> and it doesn't look like the well-thought-out solutions at hand, are
> even being considered, and those things that ARE being considered are
> unclear and half-baked.
>
> exasperatedly yours,
> djp

Perhaps it would help if you listed the issues, features-to-be and
features-needed and provided what you think is best solution for each. Then
the discussion can begin.

Saying that you are exasperated and peaved and that we are basically
without direction and clueless might be a suboptimal path towards a viable
solution.

Also, please try to keep in mind that there is basically just one developer
for VO. And his time to work on VO is quite limited much of the time.

Noel

--

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

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[David J Patrick-2]

Noel Henson wrote:

> On Sunday 04 October 2009, David J Patrick wrote:
>> Our own hilf has been using metadata thusly;
>>
>> Heading
>> ;{key:value}
>>
>> : body text
>>
>
> First, whose code are we referring to?

Oh, sorry, hsitz (Herbert Sitz) is the code-monger in question.
>
> Second, VO is just supposed to be an outliner. Text objects have been
> defined so that others can use them any way they see fit; just as you are
> using ';' to indicate metadata. We have tried to keep VO a simple tool.  
> Even checkboxes are not really part of VO. They are just another plugin.
This I get completely, and I'm not gunning for any plug-ins but talking
about core functionality that is in flux. Just as I want to continue to
do my thing, with the built in features, I appreciate that others need
the freedom to do other things, but that doesn't mean the core couldn't
be improved, and if done right, will only enhance future flexibility.
>
> I see. If you look back over the years, this is how VO development seems to
> be done. We through a bunch of stuff out there, see how people react to it,
> modify it, determine if it's even useful and then make changes accordingly.  
Actually, my current grumbles have to do with this very thing. Herb has
been putting forth some very sound thinking, over the past couple of
years with almost no reaction from the VO community. He started by
articulating clearly his concerns and ideas, and when that had no effect
, he began to post screenshots of his implementations. Then, when that
was met with almost no response, he began posting links to screen
movies, showing his work in action. I was part of the non-chorus, until
one of his suggestions caught my attention, and I reviewed all of his
submissions, actually looked at the screenshots and watched the movies.

This guy is good, and has been in the mode since the heyday of text-mode
outliners, and he can write code and read yours.
>
> Perhaps it would help if you listed the issues, features-to-be and
> features-needed and provided what you think is best solution for each. Then
> the discussion can begin.

alright, as a variation on that theme, let me list the substantial
improvements that Herb has made (and shared via off-list email, after I
implored him) that I think all VO users should have access to;

improved syntax highlighting
with nice touches, like de-emphasizing of the object identifying
characters ; : < >

enhanced folding
with less annoying text block behavior and better indications of folded
content. key-bindings allow easy expand and collapse, one branch at a
time, one level at a time.
<ctrl><arrow-key>

enhanced navigation
with key-bindings that easy movement between heading levels and from
level to level, with sane and safe behavior (you won't suddenly find
yourself somewhere unexpected)
<alt><arrow-key>

enhanced section movement
featuring outline-aware promote, demote and move up-and-down (this alone
has revolutionized my freedom editing outlines)
<ctrl><shift><arrow-key>

metadata handling
with clear and logical syntax using existing (;) objects. Already in use
are; {cost:amt}, {date:YYY-MM-DD}, {author:Author}, {title:Title} and
most impressively, REM statements that can then be aggregated to a
working remind file. Herb says that with a little prodding, this method
could carry arbitrary metadata, and the MakeDict2() implementation is
able to juggle almost any behavior, like a database.
>
> Saying that you are exasperated and peaved and that we are basically
> without direction and clueless might be a suboptimal path towards a viable
> solution.
heyyy... I never said clueless ;-)
My apologies if I offended. My frustrations now are that substantial
enhancement of core functionality is likely to die on the vine. I have
many of these changes working here, but the current discussions re;VO
development show no hint of recognizing these offered contributions,
nevermind their being adopted. This is what I see as dysfunctional.
>
> Also, please try to keep in mind that there is basically just one developer
> for VO. And his time to work on VO is quite limited much of the time.
And that is exactly why I would hope that when someone with decades of
outlining experience, good ideas, working implementations generously
offers his work, that he should get a chance to take some of the load.
Is there a snowballs chance that any of these contributions might
someday make it to end users? I can see that he knows the code-base, is
respectful of the process, understands how users need to retain all of
their freedoms, is ready to work within the existing framework. If you
are serious about improving VO, have a closer look at these contributions.

djp
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Anders Bo Rasmussen-2]

On Tue, Oct 06, 2009 at 11:00:24AM -0600, Scott Scriven wrote:
> > or order done tasks as there were done.
>
> This data is available in the log.  However, it often is *not*
> available in the .otl files.  If you like, I could add an option
> to always store the date an item was completed.  Currently,
> that's omitted if it's the only metadata, because it seems like
> useless clutter on non-recurring items.

That would be nice.  Currently I do not use the log and don't have it in
subversion as I do with the rest of the files, to be able to share
between my desktop and laptop. It might make merge conflicts as 'g' is
also put in the log.

> > E.g. if I wanted to have the last 10 tasks mask as done:
> > tkdo list -attr 'done-date,name' | sort | tail 10
> > to get the the last 10 done tasks.
>
> There's a way to do this today:
>
>   grep Completed ~/.tkdo/action_log | tail -10
>
> Or if the log gets really huge, you could keep things quick by
> putting a "tail -500" or something on the front end.

This was just an example of a query I (or someone else) might want to
make.

I would actually prefer if a standard way to store attributes could be
decided on. Then there would be no need for listing the attributes by
tkdo, because there would be a standardized way to get them.
 
> Does any of this help?

Yes. Thanks for your answers (also those I've deleted from the quoting)

/Anders
_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Noel Henson]

On Sunday 04 October 2009, David J Patrick wrote:

> Noel Henson wrote:
> > On Sunday 04 October 2009, David J Patrick wrote:
> >> Our own hilf has been using metadata thusly;
> >>
> >> Heading
> >> ;{key:value}
> >>
> >> : body text
> >
> > First, whose code are we referring to?
>
> Oh, sorry, hsitz (Herbert Sitz) is the code-monger in question.
>
> > Second, VO is just supposed to be an outliner. Text objects have been
> > defined so that others can use them any way they see fit; just as you
> > are using ';' to indicate metadata. We have tried to keep VO a simple
> > tool. Even checkboxes are not really part of VO. They are just another
> > plugin.
>
> This I get completely, and I'm not gunning for any plug-ins but talking
> about core functionality that is in flux. Just as I want to continue to
> do my thing, with the built in features, I appreciate that others need
> the freedom to do other things, but that doesn't mean the core couldn't
> be improved, and if done right, will only enhance future flexibility.
>
> > I see. If you look back over the years, this is how VO development
> > seems to be done. We through a bunch of stuff out there, see how
> > people react to it, modify it, determine if it's even useful and then
> > make changes accordingly.
>
> Actually, my current grumbles have to do with this very thing. Herb has
> been putting forth some very sound thinking, over the past couple of
> years with almost no reaction from the VO community. He started by
> articulating clearly his concerns and ideas, and when that had no effect
> , he began to post screenshots of his implementations. Then, when that
> was met with almost no response, he began posting links to screen
> movies, showing his work in action. I was part of the non-chorus, until
> one of his suggestions caught my attention, and I reviewed all of his
> submissions, actually looked at the screenshots and watched the movies.
>
> This guy is good, and has been in the mode since the heyday of text-mode
> outliners, and he can write code and read yours.
>
> > Perhaps it would help if you listed the issues, features-to-be and
> > features-needed and provided what you think is best solution for each.
> > Then the discussion can begin.
>
> alright, as a variation on that theme, let me list the substantial
> improvements that Herb has made (and shared via off-list email, after I
> implored him) that I think all VO users should have access to;
>
> improved syntax highlighting
> with nice touches, like de-emphasizing of the object identifying
> characters ; : < >
>
> enhanced folding
> with less annoying text block behavior and better indications of folded
> content. key-bindings allow easy expand and collapse, one branch at a
> time, one level at a time.
> <ctrl><arrow-key>
>
> enhanced navigation
> with key-bindings that easy movement between heading levels and from
> level to level, with sane and safe behavior (you won't suddenly find
> yourself somewhere unexpected)
> <alt><arrow-key>
>
> enhanced section movement
> featuring outline-aware promote, demote and move up-and-down (this alone
> has revolutionized my freedom editing outlines)
> <ctrl><shift><arrow-key>
>
> metadata handling
> with clear and logical syntax using existing (;) objects. Already in use
> are; {cost:amt}, {date:YYY-MM-DD}, {author:Author}, {title:Title} and
> most impressively, REM statements that can then be aggregated to a
> working remind file. Herb says that with a little prodding, this method
> could carry arbitrary metadata, and the MakeDict2() implementation is
> able to juggle almost any behavior, like a database.
>
> > Saying that you are exasperated and peaved and that we are basically
> > without direction and clueless might be a suboptimal path towards a
> > viable solution.
>
> heyyy... I never said clueless ;-)
> My apologies if I offended. My frustrations now are that substantial
> enhancement of core functionality is likely to die on the vine. I have
> many of these changes working here, but the current discussions re;VO
> development show no hint of recognizing these offered contributions,
> nevermind their being adopted. This is what I see as dysfunctional.
>
> > Also, please try to keep in mind that there is basically just one
> > developer for VO. And his time to work on VO is quite limited much of
> > the time.
>
> And that is exactly why I would hope that when someone with decades of
> outlining experience, good ideas, working implementations generously
> offers his work, that he should get a chance to take some of the load.
> Is there a snowballs chance that any of these contributions might
> someday make it to end users? I can see that he knows the code-base, is
> respectful of the process, understands how users need to retain all of
> their freedoms, is ready to work within the existing framework. If you
> are serious about improving VO, have a closer look at these
> contributions.
>
> djp
> _______________________________________________
> VimOutliner mailing list
> VimOutliner@...
> http://www.lists.vimoutliner.org/mailman/listinfo

David,

Sorry to have taken so long to get back to you. I have looked at Hsitz
stuff. Some of it IS cool. I still need to test it for inclusion into VO.  
Some of it, the basic idea is nice but the implementation needs work. Like
the script for keeping body text folded, for example. On large outlines, it
really slows down opening and closing folds with ,,1 through ,,0.

Coming up here, this weekend, I'll have some time to check out the
remainder of his stuff, run some of my own tests, and finish the 0.4 ToDo.  
That way everyone can see what is to be included in the 0.4 release and
they can cheer or boo from that point on.

Again, please keep in mind that some of us old timers on the VO project are
just really old timers when it comes to using computers and computer
programs, including outliners. I constructed my first microprocessor-based
system in 1977.  I did my first electronic "outlines" using Xerox word
processor that stored information on magnetic cards.  I was first
introduced to the concept of outlining by a science teacher way back in
1970 or 1971, although I was using paper, pencil and 3x5 cards then, LOL.  
In that light, let's try to maintain a level of civility.

Noel

--

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

_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[David J Patrick-2]

Noel Henson wrote:
> Sorry to have taken so long to get back to you. I have looked at Hsitz
> stuff. Some of it IS cool. I still need to test it for inclusion into VO.  
I like his directions and implementations a lot. Of course, he'd
probably be the first to admit it ain't perfect, nothing is. I'm happy
you had a chance to give it a once-over. After using these changes, I
wouldn't want to lose them, and I think you'd like them too.
>
  I constructed my first microprocessor-based
> system in 1977.  I did my first electronic "outlines" using Xerox word
> processor that stored information on magnetic cards.  I was first
> introduced to the concept of outlining by a science teacher way back in
> 1970 or 1971, although I was using paper, pencil and 3x5 cards then, LOL.  
While I've been somewhat computer obsessed since the late '80s, I
realized early that I would never be a programmer, and just became a
demanding user with a very broad but very shallow understanding of the
IT universe.

> In that light, let's try to maintain a level of civility.
If my pent up passions popped, and seemed uncivil, I am truly sorry. I
am in no position to tell you what to do, one way or another, and I'm
deeply appreciative of all that you have shared with us in the past, and
for your ongoing sincere efforts to do what's right for this project.

I'd like to be a positive force in shaping vimoutliner into something
lean and sharp, that required no thinking to use, but could be bent to
any purpose, then I'll continue to speak up even at the risk of stepping
on toes, because it's part of my creative pipeline and I want it to flow.

Blame Mark Eppley, of Traveling Software in 1985, who wrote an outliner
called Thought. using 8 line x 40 character LCD and about 8k in ROM,
Thought did everything we've ever talked about on this list; metadata,
file linking, cloning, numbering, hoisting, and blazingly fast, instant
(depends on typing speed) and in using that for a few years to great
success, my mode was set, and I have been searching for that level of
usability ever since. Today, I use VO with a few of Herbs patches, and
it gets that much closer. (He's chasing Grandview, which was to DOS what
Thought was to the Radioshack TRS80, model100) but, y'know, we all have
our hangups ;-) in truth, those outliners of olde were bold.

Please don't be offended, I mean well and have nothing but respect,
peace out
djp


_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo

[Herbert Sitz ()]

Noel Henson wrote:

. . .  I have looked at Hsitz
stuff. Some of it IS cool. I still need to test it for inclusion into VO.  
Some of it, the basic idea is nice but the implementation needs work. Like
the script for keeping body text folded, for example. On large outlines, it
really slows down opening and closing folds with ,,1 through ,,0.

Noel

Noel -- I think you're probably looking at an old version of my changes where I had switched over to using a syntax foldmethod.  That did indeed have a noticeable delay when doing global fold operations that grew as file size grew.  I was able to revise things and get the same functionality with foldmethod=expr (i.e, the same fold method as VO currently uses), which has identical speed (as far as I can tell) to global folding in the current VO.

Moreover, in all the changes I have made I've done things in a way that is compatible with current VO.  With regard to the changed folding behavior, for example, using 'foldmethod=expr' means that folding is controlled by a custom function.  It would be perfectly possible for a future version of VO to have two such functions, e.g., "MyFoldLevelOriginal(v:lnum)" which would retain VO's current fold behavior, and "MyFoldLevelNew(v:lnum)" that could implement different fold behavior.  Users could specify which one is default behavior in their vo_base.vim, and could even switch between the two on the fly by reassigning 'foldexpr' in a running instance of vim.  Likewise, I have modified the foldtext to something I think is preferable, but there could be multiple foldtext functions available to users.

In addition, other functionality I've added could be left unmapped to keys if some VO users wanted to ignore it, or mapped to different keys from the ones I've specified.  Users who didn't want to take advantage of new functionality would be completely unaffected.  Users who wanted to take advantage of it would be able to.

I don't mean to say that anything I've done is ready for inclusion in a new version of VO.  I haven't really looked back at the code for months, but if I recall correctly some of it depended on the text blocks all being indented one tab stop from their headings.  I believe this is standard for VO users, but some may still be out there who use text flush left with its heading.  In any case, in my opinion it would be preferable for all the functionality to be generalized to work with text indented to any level, which could be done.

In addition, there are a few small bugs that I haven't bothered to fix yet.  Nothing major, but probably would want to address them if they were to be in published version of VO.

It's fine if you don't think they're what you want for VO.   I use them myself and they work well for me.  I was glad to have the base of VO to work from, and I'm happy to contribute what I've done back, if you want it.  I'll email you a new set of files that show most of what I've done, which includes a few more new things since the stuff you've seen, besides the move back to using foldmethod=expr.  You can do with it what you will.  I could also post a message in the newsgroup with a zip or tgz file of my changes.

Regards,

Herb

[Steve Litt]

On Sunday 04 October 2009 21:43:33 David J Patrick wrote:
> Noel Henson wrote:

> > I see. If you look back over the years, this is how VO development seems
> > to be done. We through a bunch of stuff out there, see how people react
> > to it, modify it, determine if it's even useful and then make changes
> > accordingly.
>
> Actually, my current grumbles have to do with this very thing. Herb has
> been putting forth some very sound thinking, over the past couple of
> years with almost no reaction from the VO community. He started by
> articulating clearly his concerns and ideas, and when that had no effect
> , he began to post screenshots of his implementations. Then, when that
> was met with almost no response, he began posting links to screen
> movies, showing his work in action. I was part of the non-chorus, until
> one of his suggestions caught my attention, and I reviewed all of his
> submissions, actually looked at the screenshots and watched the movies.

I think this is a property of Free Software, which for the most part is based
on scratching itches. I have a feeling if you watched each VO user, you'd see
completely different behaviors and usages, because we all have different itches
once you get beyond the basic outliner features. For instance with me, I don't
understand the GTD stuff or the TkDO stuff, and don't perceive myself as having
time to use it. So I wouldn't want it in the basic installation if its code
added to the places a bug could hide out.

For myself, I don't understand why every  Linux user on the planet isn't using
my UMENU, and therefore my EMDL dialect of VimOutliner. UMENU/EMDL are a
central part of my business, but take it from me -- most people have
absolutely no perceived need for either one. They scratch my itch, not the
itch of most people. So I just made EMDL into a specification so anyone else
interested in using it could, and for the same reason I made a standalone EMDL
to UMENU converter script.

VO itself is an example of something that's an addon to, rather than a change
to, another software program. It's just a plugin for Vim and requires no
change to the Vim distribution. As a matter of fact, VO 0.1.3 wasn't even a
plugin -- it was a directory tree of scripts and config files kept entirely
separate from the Vim directory tree. Early VO could run without the Vim
executable having any knowledge of it, and the entire Vim distribution could
be replaced and VO would still run perfectly. Then, as outlining became an
itch for many people, only then was VO moved into the Vim directory tree and
made a plugin.

Then there's the salesmanship problem...

Nobody's using UMENU, so I must not have successfully articulated the need and
practicality of UMENU. I haven't enabled others to see in UMENU what I see in
it, even though I've been writing of its benefits for years.

There's a guy named Phil Barnett in LEAP who gave a 2 hour dog and pony on the
Smoothwall (now called IPCop) firewall appliance. Phil made it look so easy,
and showed its benefits so well, that a few weeks later I built a Smoothwall
box, made it the centerpiece of my network, and used its benefits to ease my
Windows to Linux transition.

A GoLUG guy named Kevin Korb gave a 1.5 hour demo of backing up via rsync. He
made the benefits so obvious and compelling, and made it look easy enough that
a couple weeks later my entire backup methodology changed to an rsync based
method like Kevin's. Another time Kevin gave a djbdns demo that made djbdns
look so easy, straightforward and beneficial that I forever banned BIND from my
computers and used djbdns from then on.

I'm thinking that no itch-scratch will gather mindshare without a piece of
salesmanship like Phil's or Kevin's. Once the salesmanship is done effectively,
many will want the feature and many will want to help code it.

Luckily, having seen Phil's and Kevin's demonstrations, I think I can distill
what made them successful, and write up a tiny document explaining how to
successfully sell a feature or piece of software.

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



_______________________________________________
VimOutliner mailing list
VimOutliner@...
http://www.lists.vimoutliner.org/mailman/listinfo