Re: yet another todo editing system

Re: yet another todo editing system

[Joe Corneli]

> > A feature for browsing programs certainly ought to be part of Emacs.

> One way to think about this feature would be to instantiate a function
> prototype (a b c) -- as in, (insert &rest ARGS) -- as something like
> this: ((a "link a") (b "link b") (c "link c")) -- where "link a"
> points to

>> You have lost me here.  You were talking about browsing, and now
>> you're talking about instantiating something.

>> I can't understand what this is all about.

Hoof.  Ok.  Sorry about the vagueness.  I had a head cold and a
terribly slow internet connection when I was writing last night.
Now both are considerably better.

Let me try to clarify what I was talking about.

A central point is that both Todo and Lisp are oriented towards lists.
The fact that my program works exclusively with lists as opposed to
plain text is the constraint inherent to the "structured editing
environment" I mentioned offhandedly a while ago.

When a person writes Lisp code, they are working within a similarly
constrained environment (assuming they want their code to compile).
Lisp code is made up of lists of strings.

Here is an example of a Lisp function I just wrote, set up in a
traditional style and indented by Emacs.

(defun grape ()
  (interactive)
  (switch-to-buffer "*grep*")
  (beginning-of-buffer)
  (next-line +2)
  (let ((lines (simple-count-lines-page))
        (line (simple-what-line)))
    (while (not (equal line lines))
      (switch-to-buffer "*grep*")
      (next-line +1)
      (setq line (+ 1 line))
      (compile-goto-error)
      (find-file-other-frame (buffer-name))
      (other-frame -1))))

And here is a version of the same function as it might be represented by
Todo.  As is typical with Todo, we find the text spread across several
files.  Recall that the syntax of the lines that make up Todo files is
"<char> text <<filename>>", which means "<user-specified markup code>
link description <<file-we-link-to>>".

grape:
< > defun <<defun>>
< > grape
< > nil <<nil>>
< > interactive <<interactive>>
< > switch-to-buffer <<switch-to-buffer.local>>
< > beginning-of-buffer <<beginning-of-buffer>>
< > next-line +2 <<next-line+2>>
< > let <<let.local>>

let.local:
< > let <<let>>
< > VARLIST <<let_VARLIST.local>>
< > BODY <<let_BODY.local>>

let_VARLIST.local:
< > lines <<simple-count-lines-page>>
< > line <<simple-what-line>>

simple-count-lines-page:
-- OMITTED --

simple-what-line:
-- OMITTED --

let_BODY.local:
< > while <<while.local>>

while.local:
< > while <<while>>
< > TEST <<while_TEST.local>>
< > BODY <<while_BODY.local>>

while_TEST.local:
< > not <<not.local>>

not.local:
< > equal <<equal>>
< > line <<let_VARLIST.local>>
< > lines <<let_VARLIST.local>>

while_BODY.local:
< > switch-to-buffer <<switch-to-buffer>>
< > next-line +1 <<next-line+1>>
< > setq <<setq.local>>
< > compile-goto-error <<compile-goto-error>>
< > find-file-other-frame <<find-file-other-frame.local>>
< > other-frame -1 <<other-frame-1>>

setq.local:
< > setq <<setq>>
< > line <<latest_definition_of_line>>
< > + <<+>>
< > 1 
< > line <<latest_definition_of_line>>

latest_definition_of_line:
< > initial value <<let_VARLIST.local>>
< > inside while loop <<setq.local>>

find-file-other-frame.local:
< > find-file-other-frame <<find-file-other-frame>>
< > buffer-name <<buffer-name>>

other-frame-1:
< > other-frame <<other-frame>>
< > -1

switch-to-buffer.local:
< > switch-to-buffer <<switch-to-buffer>>
< > "*grep*"

next-line+1:
< > next-line <<next-line>>
< > 1

next-line+2:
< > next-line <<next-line>>
< > 2

In the above, every file with the suffix "local" is (a representation
of) what I was calling an "instantiation" in my earlier email.  For
instance, the "let" I use in the definition of the function "grape" is
an instantiation of the function "let" defined in Emacs.  This is
slightly different from the "defun" I use.  The "defun" used in the
definiton of "grape" is exactly the same as any other "defun" you might
find in standard Lisp code.  So I don't point to a "local instantiation"
of defun, but rather to the Todo file that describes defun.

I've taken a liberty in the file let_VARLIST.local by making the 
link descriptions the same as the value of the variable that is being
set.  A more consistent version of let_VARLIST.local would be:

let_VARLIST.local:
< > first variable <<let_VARLIST.first_variable.local>>
< > second variable <<let_VARLIST.second_variable.local>>

let_VARLIST.first_variable.local
< > lines
< > simple-count-lines-page <<simple-count-lines-page>>

let_VARLIST.second_variable.local
< > line
< > simple-what-line <<simple-what-line>>

Another potentially confusing point is that I only have one
"switch-to-buffer.local".  In a more complicated function, there might
be several different "instantiations" of switch-to-buffer.  (We might
have (switch-to-buffer "*scratch*") as well as (switch-to-buffer
"*grep*"), for example.)  The file names used by Todo would have to
be adjusted to reflect this multiplicity.

Re: yet another todo editing system

[Joe Corneli]

Sorry, a slight error to correct here:

 while_BODY.local:
 < > switch-to-buffer <<switch-to-buffer>>
 < > next-line +1 <<next-line+1>>
 < > setq <<setq.local>>
 < > compile-goto-error <<compile-goto-error>>
 < > find-file-other-frame <<find-file-other-frame.local>>
 < > other-frame -1 <<other-frame-1>>


should be:

 while_BODY.local:
 < > switch-to-buffer <<switch-to-buffer.local>>
 < > next-line +1 <<next-line+1>>
 < > setq <<setq.local>>
 < > compile-goto-error <<compile-goto-error>>
 < > find-file-other-frame <<find-file-other-frame.local>>
 < > other-frame -1 <<other-frame-1>>

Gud lord!

[Nick Roberts]

Where's the logic in putting gud.el in the progmodes directory? I can see the
point in grouping files which have a natural relationship together but gud.el
is not a mode for a computer language. If I'm looking for something, I quite
often grep the lisp directory, so my rule would be:

If there's not a natural grouping, keep the file in the top-level lisp
directory.

Nick

Re: Gud lord!

[Robert Anderson]

On Sat, 2003-06-07 at 09:12, Stefan Monnier wrote:
> > Where's the logic in putting gud.el in the progmodes directory? I can see the
> > point in grouping files which have a natural relationship together but gud.el
> > is not a mode for a computer language. If I'm looking for something, I quite
> > often grep the lisp directory, so my rule would be:
> 
> I don't have a particular opinion on this except I'd like to remind
> people that CVS deals very poorly with file moves, so it's best
> to refrain from doing them unless there's a really compelling reason.

As an aside, I'd remind people that this is one of a very long list of
reasons why CVS is inadequate for open source development considering
superior alternatives such as arch:
http://regexps.srparish.net/src/arch.

To be handcuffed by a revision control system which is unable to sanely
rename a file - in the year 2003 - seems absurd to me.

Bob

Re: Gud lord!

[Miles Bader]

On Sat, Jun 07, 2003 at 09:43:25AM -0700, Robert Anderson wrote:
> To be handcuffed by a revision control system which is unable to sanely
> rename a file - in the year 2003 - seems absurd to me.

Please call back when there's actually a _stable_ and well-supported
alternative; currently neither arch nor subversion are.

CVS may suck rocks in many ways, but changing this is not something to be
done lightly.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

yet another todo editing system

[Joe Corneli]

Dear SIRS and MADAMS,

In the spirit of leaping before looking, I wrote a program that I call
"todo" in my ever-increasing amounts of Free time this past year.  The
name "todo" is somewhat ironic, because, like any good todo-list editor,
you can do all sorts of things with it; one could say with sincerity
that its not fit for any particular purpose.

And yet... I have found it quite useful for keeping track of all kinds
of things, including my things-to-do.  I've also used it to make a
prototype hypertext math dictionary.  If I had an iPod, I could use it
to put these things on my iPod -- but I don't have an iPod.  I've put
some examples on my webpage instead.  There are currently more features
internal to the program than are exported to HTML through the exporting
feature (in particular, there is an "up" feature that is more
interesting than the "up" feature used in standard web/file browsers).

To clarify the above, I should mention that 99% of the point of this
program is that lists can contain links to other lists.  If you've seen
screenshots of the iPod in action, or if you have an iPod, then you know
the sort of thing I'm talking about here.

So, ok, its time to try giving my program away.  Here is the URL:

  www.ma.utexas.edu/~jcorneli/no_index.html/todo/todo.html

No doubt I haven't gotten all the bugs worked out of it, and certainly I
haven't added all of the features that I think should be there.  I have
tested the program out on several systems and it seems to work - but who
knows!  Its time for other people to try it out.  But another reason I
haven't continued to press ahead is that I realized a while ago that
this program would be much better if it was an Emacs package. (Which is
why I am writing to this list!)  I'm not even sure that there isn't
something else already in Emacs that does more-or-less exactly what my
program does. Recently I've checked out a few of the todo-like modes and
haven't seen anything quite like my program, though there is certainly
some similar stuff -- and if I do decide to port the program to Emacs
Lisp, there will be some nice things to draw on there.

In the mean time, I would appreciate it if you could tell me what you
think. Is there already an Emacs package out there that does what my
program does?  Probably some combination (eg. todo mode and hyperbole)
would do it.  But maybe my version of things has potential on its own.
After all, it is simple.  Would you like to see an Emacs Lisp port?

Joe Corneli

PS.  I have what I think to be a fairly clever name for the Lisp port 
in mind (if I do write one) -- the new name is "Todl".

Re: yet another todo editing system

[Thien-Thi Nguyen]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:

   In the mean time, I would appreciate it if you could tell me
   what you think.

i think i already have enough todo to be trying to answer this
question but hey, vivaldi is on the radio...

   Is there already an Emacs package out there that does what my
   program does?

probably.  you surmise as much yourself.  why not actually finish
your research instead of asking for others to do that for you?
(see Y and Z below.)

   But maybe my version of things has potential on its own.  After
   all, it is simple.  Would you like to see an Emacs Lisp port?

personally, i would like to see a post like "hey, i know there are
N todo systems out there (according to Y and Z research methods),
but none that i've seen has these features: A, B, C -- how can i
incorporate them into existing elisp todo system T, which seems
most likely to be able to support my new features?", posted to
gnu-emacs-help, and then after a bit of time has passed, code
posted to gnu-emacs-sources.

for Y and Z, try google and http://www.emacswiki.org to start.

alternatively, if A, B and C are seemingly not implementable in
elisp, i would like to see questions on how to do so (posted to
gnu-emacs-help); maybe i can learn something from the resulting
discussion.

thi

Re: yet another todo editing system

[Joe Corneli]

Dear Thi,

Maybe I'll be able to supply the post describing extant todo systems and
contrasting them with the features and/or proposed features of my system
soon.  I can see that if this leads to a set of technical questions
about how to implement the new features then gnu-emacs-help would be a
good place to write.

As regards my post to emacs-devel -- I don't want other people to finish
my research for me -- I just prefer to start doing research by talking
to people when possible.  At the very least it sharpens my intuition for
independent searches, sometimes I get an answer right away.

Besides, I thought it worth mentioning what I've been working on!  I'd
be more than happy to supply a more detailed analysis of how I think
it might fit into Emacs.

Joe Corneli

Re: yet another todo editing system

[Thien-Thi Nguyen]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:

   Besides, I thought it worth mentioning what I've been working
   on!  I'd be more than happy to supply a more detailed analysis
   of how I think it might fit into Emacs.

certainly it is worth mentioning, anything is like that in
passing.  whether or not it is worth "selling" (which is the
process you are embarking on) is another question, one for which
you cannot reliably receive feedback from others especially if
they haven't seen the goods!  (here, "goods" includes comparison
of spiffy-new w/ plain-old-previous.)

back in my more entrepreneurial daze i saw a lot of this "will you
fund development of <hypothetical value proposition>?" happening
(between company founders and venture capitalists basically).  it
worked to a large extent in that context where the people w/ money
didn't really understand the technical realities (and only rarely
understood the social, political and market realities) of the
hypothesis, but has less traction in the free software world,
where at least you can be assured of some level of technical
competence (although let me be the first to serve as a glaring
counter example ;-).

so, although i was about to rail against gating one's actions w/
external motivators, i suppose it's not a bad way after all, and
will thus simplify my point to be: the sooner you get technical,
the less verbiage (like this post) you'll have to wade through and
discard to get to valuable feedback.  a variant of "just do it",
if you will.

thi

Re: yet another todo editing system

[Joe Corneli]

Dear Thi,

Well, your point of view seems well-informed.  Mine certainly isn't;
consequentially I probably stand to benefit from wading through a
certain about of "verbiage" and _not_ discarding it.  True enough,
education in the ways of free software wasn't what I was explicitly
looking for - but implicitly it was, at least in part.  I'll take it
when I can get it.

What follows isn't _very_ technical, but its a reasonable overview of
what I want compared with what is out there.  It doesn't look like there
is anything _too_ hard -- but neither does it look like there is
something that does _exactly_ what I want.  These are things I could
use advice on but that I don't necessarily _need_ advice on in order
to proceed.

My methods for finding relevant packages were: (X) seaching EmacsWiki
for 'todo' and following links that came up, particularly links at

     http://www.emacswiki.org/cgi-bin/wiki.pl?CategoryTodo

(Y) reviewing what I learned from a webpage with lots of comments by Kai
Grossjohann that I randomly found during a websearch yesterday at Google
groups for 'emacs rmail email "HTML mail"' -- the tenth item returned
turns out to be an interesting discussion of various todo modes, the
long link is this:

      http://groups.google.com/groups?q=emacs+rmail+email++%22HTML+mail%22&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=m2adjxi9sj.fsf%40mmynste.corp.vha.com&rnum=10

and (Z) downloading and installing everything that seemed particularly
relevant, trying it out, and browsing the documentation.  

Results of this investigation: the package hyperbole seems to supply a
good bit of the same functionality as my "todo" program -- in particular,
if I made a buffer "example" that looks like this:

  this
  is 
  a 
  list

and I had a file "list" in the right path that looks like this:

    Lists are the basic building blocks of Lisp
    They are also the basic building blocks of most Todo modes

then hitting "C-h h a" when my cursor was on the word "list" in the
buffer "example" would cause a new buffer containing the file "list"
to open up in Emacs.   You can see how this can be used to browse
one-word lists.   If I hit "C-h h a" when my cursor is on the line

    Lists are the basic building blocks of Lisp

in the buffer "list", then who knows what will happen.  Presumably I
could write some macros that would get my files to open up so that
hyperbole will automatically parse each line as a "button", so that I
could get the above-quoted line to point to a file "lisp", say.  I
haven't found the details yet, but this doesn't seem like it should be
too hard. I'll have to dig further into the documentation for hyperbole
is all.

For now, it looks like this combination will provide essentially the
same information as the lists that I _exported_ from my todo program.
(Which, for those of you new to this "thread", is available at

    www.ma.utexas.edu/~jcorneli/no_index.html/todo/todo.html

together with several examples and a bit of documentation.) 

What I'm not seeing here is the neat "up" feature that my program 
supplies.  

Description of todo's "up feature":

When you are viewing a list and you submit the command "up", one of
three things happen: if the current list has exactly one "client", that
client is displayed and gets the focus of the program.  If the current
list has more than one client, you are prompted with a list and told to
choose one.  Assuming you manage to do that alright, focus shifts to the
chosen one as above.  Finally, if the current list has no clients you
get an error message.

Clientele information is developed in real time as users add
information to the "todo database".  Each list with clients contains
a "hidden" link to the list of clients, and this list is adjusted
every time the user does something like add a link from file A to 
file B  or delete a link from file A to file B.

This feature is useful for figuring out who cites what.  For example,
what definitions in math dictionary rely on the definition of a group,
or which papers in an annotated bibliography refer to John Doe, 1984.
It might also be useful for doing mathematical computations (assuming
someone wanted to do computations within the framework of the todo
database for some reason).

This "up" business seems serious, but probably by no means fatal.

On to something new. Here is something I would _like_ to have in my
ideal list editor: the ability to take a list element such as

    Lists are the basic building blocks of Lisp

and generate from it a new list something like

    Lists 
    are the 
    basic building blocks 
    of 
    Lisp

where presumably each element of the new list is defined by something in
the extant database of entries (or if not defined at least related
somehow, perhaps just as a representative of a semantic category in the
case of "are the").   I don't see much problem with writing a function
in Emacs that would break a string up in this way (or any number of
other ways) -- so this probably isn't a sticking point, assuming that
everything else I've mentioned so far works.

The example above reminds me of another feature of my program: the
ability to describe each element of a list with a one-letter tag.  Maybe
each element would be marked up with a hint as tothe part of language
that it comes from:

      <N> Cat
      <V> Run
      <a> Fast

or some such thing.  These tags can be used (at least in theory) to
generate markup in the exported document.  Maybe I want to export to
colorful HTML and get each noun to be green, each verb to be yellow, and
each adverb to be blue.  Figuring out how to do this with hyperbole --
and figuring out how to export the files once they are tagged -- seem to
be the last of my problems with "porting" my program.  Porting is in
quotes, because except for exporting to formats that use only very
trivial markup, I haven't yet gotten around to getting this done in my
program.

Anyway, it doesn't seem likely to be too hard to export lists once 
they exist, so I don't think this will be a sticking point.

That means the only thing that poses a real challenge is "up", and that
should be pretty doable.

Joe

PS. Another question is whether it mightn't be nice to make everything
colorful, a la outline more for example; I'll plan to worry about
that later.

Re: yet another todo editing system

[Kai Großjohann]

It seems that maybe Wiki does something similar to what you have.  In
a Wiki, you can make a word a HyperLink by using InnerUpperCase.
Following the HyperLink then lands you in the like-named file.

But I don't grok the "up" feature, so I can't really comment on
that.  It seems like you have bidirectional links, and "up" means to
follow them backwards.  But I'm not sure.
-- 
This line is not blank.

Re: yet another todo editing system

[Joe Corneli]

Dear Kai,

I tried out Emacs Wiki last night.  And yes it is rather like what I
have.

The two most obvious differences are

	    * Wiki is based on a plain text format
whereas
	    * Todo is based on a list format

- and -

	    * Todo can have links with arbitrary text labels
whereas
	    * Wiki CanOnlyHaveLinksWithLabelsLikeThis

Another difference:

	    * Todo encourages fairly arbitrary "markup" 
whereas
	    * Wiki says "The general idea is to write plain ASCII."

As for Todo's "up" feature, you do understand it.  When you insert a
link from page A to page B in Todo, page B automatically adds a "hidden"
link to page A.  This makes it possible for to conveniently determine at
any moment the clients of a given list.  "Up" just means "change focus
to one of the clients".

Joe

Re: yet another todo editing system

[Miles Bader]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:
> whereas
> 	    * Wiki CanOnlyHaveLinksWithLabelsLikeThis

A way to go insane quickly, I'd think...

-Miles
-- 
The secret to creativity is knowing how to hide your sources.
  --Albert Einstein

Re: yet another todo editing system

[Joe Corneli]

> A way to go insane quickly, I'd think

Here is an even easier way to do approximately the same thing:

  M-x replace-regex SPC RET RET
...
  M-x studlify-region

Note, though, that you can run into trouble even more quickly if you 
try to use the result of this algorithm in a Wiki.

Joe

Re: yet another todo editing system

[Miles Bader]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:
>   M-x studlify-region
> 
> Note, though, that you can run into trouble even more quickly if you 
> try to use the result of this algorithm in a Wiki.

I seem to recall having seen Wikis that looked like someone had done
just that (with every link target empty, of course)!

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

Re: yet another todo editing system

[Kai Großjohann]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:

> I tried out Emacs Wiki last night.  And yes it is rather like what I
> have.
>
> The two most obvious differences are
>
> 	    * Wiki is based on a plain text format
> whereas
> 	    * Todo is based on a list format

For a todo application, it might be useful to somehow marry Wiki with
outline mode.

> 	    * Todo can have links with arbitrary text labels
> whereas
> 	    * Wiki CanOnlyHaveLinksWithLabelsLikeThis

How do you distinguish links from non-links in Todo?

> Another difference:
>
> 	    * Todo encourages fairly arbitrary "markup" 
> whereas
> 	    * Wiki says "The general idea is to write plain ASCII."

Hm.  To me, the words "arbitrary" and "markup" don't go well
together.  Markup means that there is a program to interpret the
markup in some fashion.  Wiki tries to make its markup blend well
with natural language text, so that it doesn't stand out so much.

Anything that doesn't have to be interpreted by the Wiki processor
can be freely used.

By saying that Todo encourages arbitrary markup it seems that you
mean that Todo as a program doesn't interpret it.  Well, you can do
that with Wiki, too.

But that said, I still haven't found the right todo application for
me.  Maybe I'm confused as to what I need.  But I've tried a number of
them and still haven't settled on one.

(Btw, organizer-mode might be interesting to you because it supports
a number of links: you can link from a todo item to a message in Gnus
or RMAIL or VM, and to a BBDB record, and so on.  It seems that what
you need most are links -- your Todo is basically all links, right?
So maybe you might like organizer-mode.)
-- 
This line is not blank.

Re: yet another todo editing system

[Joe Corneli]

> How do you distinguish links from non-links in Todo?

< > This is a link <<link>>
< > this is not a link

I usually write the lists from within the program Todo...  so to change
a link into a non-link (or vice versa) is a simple matter.  To go from
non-link to link, you are prompted with a file name made up of
underscore-separated words from the string (eg., this_is_not_a_link).
You are also prompted with a prefix based on the name of the current
file (eg., example_for_kai.this_is_not_a_link).  But you can choose any
filename.

Of course, when you look at the files, the stuff between
the <<>>'s is usually not visible. (There is a toggle to change
from one view to the other.)

> By saying that Todo encourages arbitrary markup it seems that you
> mean that Todo as a program doesn't interpret it.  Well, you can do
> that with Wiki, too.

Markup (in Todo) is useful primarily for two things: 1. sorting the
entries according to type; 2. pretty-printed exporting.  Todo process
the markup when exporting, but currently in a fairly limited way.
Ideally the user would be able to tell Todo how to process the markup,
then the sky would be the limit.

Arbitrary just means that the user gets to make up what the tags mean.
That's why the user should be able to say how to process them.

> organizer-mode

Will check it out...

Oh by the way, I'm going out of town in a few hours, probably won't have
any email for a few days - so if I don't write back promptly to emails
about Todo for a while, it isn't out of rudeness or lack of interest...

Joe

Re: yet another todo editing system

[Alex Schroeder]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:

> 	    * Todo can have links with arbitrary text labels
> whereas
> 	    * Wiki CanOnlyHaveLinksWithLabelsLikeThis

Other wikis also allow [[links in double brackets]] or variations thereof.

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: yet another todo editing system

[Thien-Thi Nguyen]

Joe Corneli <jcorneli@mail.ma.utexas.edu> writes:

   ["up" feature details]

   Anyway, it doesn't seem likely to be too hard to export lists once 
   they exist, so I don't think this will be a sticking point.

what do you think will be the sticking points?

thi

Re: yet another todo editing system

[Alex Schroeder]

I  suggest you start here:

http://www.emacswiki.org/cgi-bin/wiki.pl?CategoryTodo.

Alex.
-- 
http://www.emacswiki.org/cgi-bin/alex.pl

Re: yet another todo editing system

[Richard Stallman]

If someone wants to give a concise description
of how this mode differs from what we've already got,
that would be useful for evaluating its usefulness.

Re: yet another todo editing system

[Joe Corneli]

> If someone wants to give a concise description
> of how this mode differs from what we've already got,
> that would be useful for evaluating its usefulness.

Dear Richard,

I'll do what I can...

For whatever its worth I'll add a few things about what I'd like to 
have in my code but that I haven't added because of beginning to run 
out of steam with Bash.


      Let's tell it how it is, and how it could be
      How it was, and of course, how it should be

            -- From "Lets talk about sex" by  Salt 'n' Pepa


   *  Todo is a list-based hypertext system

   *  Unlike outline-mode, Todo only displays one "level" of
      text at a time.  If I want to write an outline of a paper in
      Todo, the top page would be a list of links to the
      sections.

   *  Todo can be used to "mark up" text.  This is currently done
      by giving each list entry a one-letter tag.  An example
      of the source for a Todo list is:

	 <m> Math <<math_hw>>
	 <h> Physics <<physics_hw>>
	 <h> Astronomy <<astronomy_hw>>
	 <w> Hacking <<hacking>>
	 < > Don't forget to sleep!


      The tags are useful for exporting to other document formats --
      for example, it would be simple to write a macro that would 
      export the above Todo list to HTML that looks like this:

	 <h3>MONDAY</h3>
	 <p>
	        <a href="math_hw.html">Math</a>
	 </p>
	 <h3>THURSDAY</h3>
	 <p>
		<a href="physics_hw.html">Physics</a>
		<a href="astronomy_hw.html">Astronomy</a>
         </p>
	 <h3>WEEKEND<h3>
	 <p>
		<a href="hacking.html">Hacking</a>
	 </p>
	 <p>
		Don't forget to sleep!
	 </p>

   o  I would like to have a simple system for people to specify
      their own macros for exporting -- but to date I have just
      written the ones I've needed into the code.

   o  By exporting all the lists in a "path" (as in, math_hw*), you 
      can build hypertext outlines.  It is not currently possible to
      merge things into one document while exporting, but that would 
      be very useful.

   *  Unlike Emacs Wiki or Hyperbole, Todo provides a highly structured
      text editing/viewing environment.  Everything you see is
      is a list or an "atom"; an atom is either a simple string or a 
      link.  Unlike with these packages, in Todo links do not appear 
      automatically. (At least not currently!) 

      The best you could do to approximate Todo in Wiki would 
      leave you with source files that look like something like
      this:

	 f jane austin 
	 m shakespeare 
	 m baudelaire
	 m baudrillard
	 F AustinPublicLibrary
	 E BookStore

      This could of course be "unstudlified" upon being exported.
      But if I wanted to include a link like
    
	 $\sum_{j=1}{\infty}j^{1/j}$

      then I'd be pretty much hosed if I tried to use Wiki.

      I'm not sure how you would do this stuff with Hyperbole.

   o  Final note about extensions to Todo -- I think it would be
      kind of cool to expand the number of kinds of links, to
      include executables or functions (as in <<!sort-lines>>)
      or tex(t) files (as in <<~/TeX/impossibility_proof.tex>>).

      Eventually I think it would be kind of cool to make Todo
      into a new mode for editing Lisp code...
 

Joe Corneli

Re: yet another todo editing system

[Joe Corneli]

> Unlike Emacs Wiki or Hyperbole, Todo provides a highly structured text
> editing/viewing environment.  Everything you see is is a list or an
> "atom"; an atom is either a simple string or a link.  Unlike with these
> packages, in Todo links do not appear automatically. (At least not
> currently!)

I.e. forward links do not appear automatically; backwards links as
discussed in my eariler email to Kai do appear automatically.

I forgot to mention this "client list" business in my overview -- this
makes Todo different from all other hypertext systems that I know about
(though apparently it is not so unheard of since Kai had a special name
for it, "bidirectional links").  It is useful for browsing a body of
text consisting of e.g. definitions, theorems, and proofs & it makes the
Todo universe quite a bit different from the (primarily) "dendritic"
universe of the file system.  It might turn out to be useful for editing
code, since you could easily see which functions use the current
function -- though of course you can do that with plain ol' grep too.
But one of main the ideas of Todo is to make these kinds of connections
more transparent.

Joe

Re: yet another todo editing system

[Richard Stallman]

       *  Unlike outline-mode, Todo only displays one "level" of
	  text at a time.  If I want to write an outline of a paper in
	  Todo, the top page would be a list of links to the
	  sections.

You could customize Outline mode to do to operate in this way, I
think.

       *  Todo can be used to "mark up" text.  This is currently done
	  by giving each list entry a one-letter tag.  An example
	  of the source for a Todo list is:

	     <m> Math <<math_hw>>
	     <h> Physics <<physics_hw>>

Outline mode has nothing like this feature, but it seems to me
that you could use a macro processor to achieve this
and use Outline mode to do the editing.

       o  By exporting all the lists in a "path" (as in, math_hw*), you 
	  can build hypertext outlines.

I don't understand what that means in concrete terms.  So I cannot
tell whether it would be easy or hard to make Outline mode do this
too.

       *  Unlike Emacs Wiki or Hyperbole, Todo provides a highly structured
	  text editing/viewing environment.

What does that mean?  (I have never used Wiki.)

    > Unlike Emacs Wiki or Hyperbole, Todo provides a highly structured text
    > editing/viewing environment.  Everything you see is is a list or an
    > "atom"; an atom is either a simple string or a link.  Unlike with these
    > packages, in Todo links do not appear automatically. (At least not
    > currently!)

    I.e. forward links do not appear automatically; backwards links as
    discussed in my eariler email to Kai do appear automatically.

I am not sure what "forward links" and "backward links" mean in this
context.  Outline mode does not have anything to do with links.

      It might turn out to be useful for editing
    code, since you could easily see which functions use the current
    function -- though of course you can do that with plain ol' grep too.

A feature for browsing programs certainly ought to be part of Emacs.

Re: yet another todo editing system

[Joe Corneli]

>        o  By exporting all the lists in a "path" (as in, math_hw*), you 
> 	  can build hypertext outlines.
> 
> I don't understand what that means in concrete terms.  So I cannot
> tell whether it would be easy or hard to make Outline mode do this
> too.

I mean that you can export every Todo file with a certain prefix to html
at once very easily.  The command line expression that will do this is

    % todo -l math_hw* -html

If the files you are exporting are linked together in an outline-like
structure (e.g. math_hw.A, math_hw.A.1, math_hw.A.2, math_hw.B, etc., with
the appropriate links from math_hw.A to math_hw.A.1 and math_hw.A.2, etc.)
then the output from the command quoted above will be several HTML pages
that give an outline of the math_hw tree.

A concrete example of a "hypertext outline" is on my webpage at

www.ma.utexas.edu/~jcorneli/inventory/inventory.html

this has a catalog of the things in my apartment shortly after moving in.

 
>     I.e. forward links do not appear automatically; backwards links as
>     discussed in my eariler email to Kai do appear automatically.
> 
> I am not sure what "forward links" and "backward links" mean in this
> context.  Outline mode does not have anything to do with links.

Ok, here is an example:

www.ma.utexas.edu/~jcorneli/inventory/inventory.library.html

contains a "forward link" to

www.ma.utexas.edu/~jcorneli/inventory/inventory.library.bookcase.html

(Only "forward links" have been exported to HTML.)

In my Todo working directory there is a file called

inventory.library.bookcase.clients

that contains exactly one line, viz.,

< > inventory.library <<inventory.library>>

This "backwards link" represents the fact that "inventory.library links to
inventory.library.bookcase".  If I added a link to
inventory.library.bookcase from the file foo, the line

< > foo <<foo>>

would be added automatically to the file
inventory.library.bookcase.clients to represent the new "client", foo.

Todo has a lot to do with links!  You can use Todo to build a hypertext
network with any kind of "graph structure". Importantly, not just a
dendritic structure like you find in outlines.

The "backwards links" are very useful for navigating though the weird
hypertext structures that you can build.
 
>       It might turn out to be useful for editing
>     code, since you could easily see which functions use the current
>     function -- though of course you can do that with plain ol' grep too.
> 
> A feature for browsing programs certainly ought to be part of Emacs.


One way to think about this feature would be to instantiate a function
prototype (a b c) -- as in, (insert &rest ARGS) -- as something like this:
((a "link a") (b "link b") (c "link c")) -- where "link a" points to
whatever fills the first slot of the the prototype in this instantiation.  
The "link bla" stuff would be more-or-less invisible when you were
browsing, but C-<feature> would take you from a link to what actually goes
there.

Eg. you might see something like (insert _COPYING_) in the code.  
C-<feature> would take you from "insert" to its definition or from
"_COPYING_" to its definition.  Or if you write out the text of "COPYING",
you could press M-<feature> to collapse the text down to a link.

(This example is probably pretty silly - but it gives an example for
how a "code browser" might work.)

Joe

Re: yet another todo editing system

[Richard Stallman]

    > I don't understand what that means in concrete terms.  So I cannot
    > tell whether it would be easy or hard to make Outline mode do this
    > too.

    I mean that you can export every Todo file with a certain prefix to html
    at once very easily.

I think that feature is something orthogonal to the features of
Outline mode.  It might make sense as a separate program (or perhaps
there's an existing macro processor you could use).

    >       It might turn out to be useful for editing
    >     code, since you could easily see which functions use the current
    >     function -- though of course you can do that with plain ol' grep too.
    > 
    > A feature for browsing programs certainly ought to be part of Emacs.


    One way to think about this feature would be to instantiate a function
    prototype (a b c) -- as in, (insert &rest ARGS) -- as something like this:
    ((a "link a") (b "link b") (c "link c")) -- where "link a" points to

You have lost me here.  You were talking about browsing, and now
you're talking about instantiating something.

I can't understand what this is all about.