Gud lord!

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!

[Stefan Monnier]

> 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.

Anyone who's had to track down old changes to ange-ftp or some other such
file that was moved knows that it's a pain when you need to find
the change history "before version 1.1".

I'd be happy to see gud.el reintegrate its lisp/gud.el location for
this reason.


	Stefan "who wasn't particularly thrilled by the move of outline.el
	        for example"


PS: Obviously moving things to `obsolete' is a totally different matter
    since the file name has significance and since those files are
    not expected to see much work on them anyway, so the CVS history
    is not of much importance.

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!

[Robert Anderson]

On Sat, 2003-06-07 at 09:43, Robert Anderson wrote:
> 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.

A better URL: http://regexps.srparish.net/www/

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]

Re: Gud lord!

[Robert Anderson]

On Sat, 2003-06-07 at 14:05, Miles Bader wrote:
> 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.

Define "stable."  I've been using arch without data loss for over a year
on a code base of over a half a million lines.

I'm also curious what you mean by "well supported."  I can't think of a
free software project in existence that has a more dedicated maintainer
than arch does.

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

Certainly not.  I wouldn't suggest a wholesale change to any system, not
matter how "stable."  I would suggest a gateway maintainer for a CVS
head "mirror" in an arch archive, with transition to arch happening
relatively slowly as people learn the system and its benefits at their
own pace.

http://arch.fifthvision.net/bin/view/Main/InteroperatingWithCVS

There is one legitimate complaint, however:  there is no Windows
support, and probably won't be anytime soon.

Bob

Re: Gud lord!

[Stefan Monnier]

> I'm also curious what you mean by "well supported."  I can't think of a

I think it's pretty simple:
- is there a ViewCVS equivalent for Arch ?
- is there a PCL-CVS equivalent for Arch ?
- is there a vc-arch.el ?
- is arch available on all the platforms used by Emacs developers
  and other people trying things out via the anon-CVS repository ?

Don't get me wrong, I think arch is really cool.  But I think before
trying to get us to switch to arch, you should help us write vc-arch.el.
I've recently cooked up vc-mcvs.el and vc-svn.el in a pretty short
amount of time.  I haven't had the time to do it for vc-arch.el, but
it should be pretty easy if you follow the same pattern: take vc-cvs.el
(or vc-svn.el), do s/cvs/arch/ on the file to start with and then
fix things.  I'd be happy to help, of course.


	Stefan

Re: Gud lord!

[Robert Anderson]

On Sat, 2003-06-07 at 15:35, Stefan Monnier wrote:
> > I'm also curious what you mean by "well supported."  I can't think of a
> 
> I think it's pretty simple:
> - is there a ViewCVS equivalent for Arch ?

It's called Perspective.  It doesn't have as many features as ViewCVS,
but that's partly because it doesn't have to, since the underlying
revctl is quite a bit more sane to begin with.

http://arch.fifthvision.net/bin/view/Main/PerspectiveHome

> - is there a PCL-CVS equivalent for Arch ?
> - is there a vc-arch.el ?

There are two arch emacs modes that I know of, in varying stages of
functionality.  One of them is by Walter Landry and one of them is by
Stephen J. Turnbull (who also does Xemacs development and has been
talking about the possibility of using arch for Xemacs).  I cannot give
you specifics on them, mostly because I don't see how an emacs mode is a
boon for arch (I tried Walter's and it didn't click with me).  It seems
easier just to use the command line to me, especially if you have good
dynamic completion code to work with - I wrote such a module for bash,
and I think others exist as well.

> - is arch available on all the platforms used by Emacs developers
>   and other people trying things out via the anon-CVS repository ?

This is probably the biggest hurdle.  The answer is "very likely not." 
Especially if non-cygwin windows support is required.  This is why an
interim interoperation scenario is almost certainly the way to go.

> Don't get me wrong, I think arch is really cool.  But I think before
> trying to get us to switch to arch, you should help us write vc-arch.el.
> I've recently cooked up vc-mcvs.el and vc-svn.el in a pretty short
> amount of time.  I haven't had the time to do it for vc-arch.el, but
> it should be pretty easy if you follow the same pattern: take vc-cvs.el
> (or vc-svn.el), do s/cvs/arch/ on the file to start with and then
> fix things.  I'd be happy to help, of course.

I think you (I) might find that an interface designed for cvs is not
going to work well with arch, because arch's interace is significantly
different than CVS's.  arch is not a CVS work-alike with a couple
extras.  It is fundamentally different. For example, it is not file
oriented, it is "source tree" oriented.  etc.

In any case, I think an emacs mode is a very minor point wrt the value
of adoption.

IMO, the real hurdle here is portability.  Parties interested in
removing that hurdle are invited to arch-users:
http://www.fifthvision.net/open/bin/view/Arch/ArchUsers

Bob

Re: Gud lord!

[Stefan Monnier]

> > Don't get me wrong, I think arch is really cool.  But I think before
> > trying to get us to switch to arch, you should help us write vc-arch.el.
> > I've recently cooked up vc-mcvs.el and vc-svn.el in a pretty short
> > amount of time.  I haven't had the time to do it for vc-arch.el, but
> > it should be pretty easy if you follow the same pattern: take vc-cvs.el
> > (or vc-svn.el), do s/cvs/arch/ on the file to start with and then
> > fix things.  I'd be happy to help, of course.
> 
> I think you (I) might find that an interface designed for cvs is not
> going to work well with arch,

It works with Subversion which is not file oriented either.  And having
looked at the Arch doc a bit, I know that it won't take much work
to get vc-arch.el working.  All you need really is to tell Emacs
how to get the state of a file, how to diff/log/move/delete/update/commit
a file and a few other such things.
If you can't do one of those things on a single file, then burp at the user.

> because arch's interace is significantly
> different than CVS's.  arch is not a CVS work-alike with a couple
> extras.  It is fundamentally different. For example, it is not file
> oriented, it is "source tree" oriented.  etc.

Which is why I'd want a replacement for PCL-CVS rather than just vc-arch.el,
but vc-arch.el would be a first step.

> In any case, I think an emacs mode is a very minor point wrt the value
> of adoption.

Depends on your habits.  I do all my CVS operations from Emacs.
I can't think of working without a PCL-CVS-like view of my workspace.


	Stefan

Re: Gud lord!

[Stephen J. Turnbull]

>>>>> "Robert" == Robert Anderson <rwa@alumni.princeton.edu> writes:

    Robert> One [arch-mode for Emacs] is by Walter Landry and one of
    Robert> them is by Stephen J. Turnbull (who also does Xemacs
    Robert> development and

Landry's arch-mode looks quite complete.  My own mode is not
appropriate, both because it is extremely incomplete, and because it
deliberately enforces a particular discipline of software engineering
that I aspire to, but can't get myself to do as a matter of habit
without a supervisor.  My s.o. refuses to take on that role.  :-)

    Robert> has been talking about the possibility of using arch for
    Robert> Xemacs).

The talk about using arch for XEmacs was before I knew much about
the practical side of arch.  Things are looking much better for the
near future, but I would not want to use the current stable version of
arch on a project as big as an Emacs.  The arch that Emacs would want
to use is just now being developed.  Among other things, there's a new
algorithm being implemented that claims to make the kind of development
that's being done in the repeated cross-pollination of emacs HEAD and
emacs-unicode much easier to track and manage.  But it only has two
users at the moment (literally two, I think).  Tom Lord has suggested
that he doesn't see much in it that existing facilities don't do, but
this hasn't really been proved yet.  I think that puts "paid" to the
notion that arch is "stable" at this point in time.

Also, XEmacs has an important motivation for using arch that Emacs
does not: it would make our package maintainers _much_ happier by
getting rid of the "must be in XEmacs repository" requirement, which
duplicates home-grown repositories in many cases.  This also means
that we may be able to "dip our toes in the water" first, which Emacs
really couldn't.

I think it would be a very good idea for the Emacs community to let
XEmacs take the lead on this one, at least if it's going to happen in
the next 18 months.  After that, there should be some large-project
experience (in terms of MB of code managed, eg, Jonathan Walther's
Xouvert and an XEmacs branch), and maybe some experience with large
projects where the metric is # of developers.

I will likely create an XEmacs arch repository within a month.  If it
works for me, I'll find a way to publish it during the summer so
others can access it.  I'll try to remember to keep notes, so GNU
Emacs can profit from my experience, or (if appropriate), simply cut
your losses at "just five minutes of your time" by ignoring the whole
thing thereafter ;-).

    >> - is arch available on all the platforms used by Emacs
    >> developers and other people trying things out via the anon-CVS
    >> repository ?

    Robert> This is probably the biggest hurdle.  The answer is "very
    Robert> likely not." Especially if non-cygwin windows support is
    Robert> required.  This is why an interim interoperation scenario
    Robert> is almost certainly the way to go.

It doesn't work for me OOTB on Mac OS X, but I haven't tried very
hard.  (I keep suppressing csh in one context after another, and it
keeps popping up in odd places; that may have something to do with
arch on MacOS difficulties since arch really insists on a POSIX sh.)

    Robert> In any case, I think an emacs mode is a very minor point
    Robert> wrt the value of adoption.

Not to Emacs developers.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: Gud lord!

[Juanma Barranquero]

On Wed, 11 Jun 2003 22:36:29 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> I think it would be a very good idea for the Emacs community to let
> XEmacs take the lead on this one, at least if it's going to happen in
> the next 18 months.

Doesn't XEmacs have developers whose only development platform is
Windows?

                                                                Juanma

Re: Gud lord!

[Stephen J. Turnbull]

>>>>> "Juanma" == Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

    Juanma> On Wed, 11 Jun 2003 22:36:29 +0900
    Juanma> "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

    >> I think it would be a very good idea for the Emacs community to
    >> let XEmacs take the lead on this one, at least if it's going to
    >> happen in the next 18 months.

    Juanma> Doesn't XEmacs have developers whose only development
    Juanma> platform is Windows?

Yes.  As far as I know there are only two important ones who do not
use Unix regularly for some purposes, though, and they have a very
limited repertoire of packages they work on.  So we could migrate some
packages to arch with the cooperation of their maintainers, the
package czar, and a couple of other interested parties.  By the time
we would be ready to migrate the core repository, arch will be working
on Windows as well as on other platforms, I'm pretty sure.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: Gud lord!

[Juanma Barranquero]

On Fri, 13 Jun 2003 06:15:20 +0900, "Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> By the time
> we would be ready to migrate the core repository, arch will be working
> on Windows as well as on other platforms, I'm pretty sure.

That's good to hear.


                                                           /L/e/k/t/u

Re: Gud lord!

[Stefan Monnier]

> Landry's arch-mode looks quite complete.  My own mode is not
> appropriate, both because it is extremely incomplete, and because it
> deliberately enforces a particular discipline of software engineering
> that I aspire to, but can't get myself to do as a matter of habit
> without a supervisor.  My s.o. refuses to take on that role.  :-)

I looked for Emacs support on the Arch Wiki but couldn't find any
discussion of it: neither yours nor Landry's.
Can't someone add links for them (I still have no idea where to
find those two beasts) ?


	Stefan

Re: Gud lord!

[Miles Bader]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> I looked for Emacs support on the Arch Wiki but couldn't find any
> discussion of it: neither yours nor Landry's.
> Can't someone add links for them (I still have no idea where to
> find those two beasts) ?

The arch Wiki is pretty badly organized (well, it's a Wiki after all!),
but I found an emacs mode in the web-browsable ArX source tree:

   http://superbeast.ucsd.edu/~landry/ArX/ArX-1.0pre8/tools/emacs/

It looks slightly odd in that it consists of about a zillion files, each
containing a single elisp function, and it appears to be a standalone
minor mode rather than a vc.el backend (I wonder, is this because arch
can't be fit into the vc.el model, or because the author simply didn't
make the effort?).

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

Re: Gud lord!

[Stefan Monnier]

> > I looked for Emacs support on the Arch Wiki but couldn't find any
> > discussion of it: neither yours nor Landry's.
> > Can't someone add links for them (I still have no idea where to
> > find those two beasts) ?
> The arch Wiki is pretty badly organized (well, it's a Wiki after all!),

Organization is not the problem, since I used `search' anyway :-(

> but I found an emacs mode in the web-browsable ArX source tree:
>    http://superbeast.ucsd.edu/~landry/ArX/ArX-1.0pre8/tools/emacs/

Thanks.

> It looks slightly odd in that it consists of about a zillion files, each
> containing a single elisp function,

Yes, it's a real nightmare to browse.
We really need some mode that shows a whole directory in a single buffer,
in an outline-like mode.

> and it appears to be a standalone
> minor mode rather than a vc.el backend (I wonder, is this because arch
> can't be fit into the vc.el model, or because the author simply didn't
> make the effort?).

The fact that the old VC is basically non-extensible and that the
new is not available under XEmacs and that people think "VC is for
RCS" is often the reason.  Even in the vc-svn.el that comes with Subversion,
there are comments in the file about how VC's model doesn't fit Subversion
and blablabla, but nowhere in the code did they need to go through hoops:
it's all very straightforward.  It might not provide the kind of functionality
that Subversion users want, but that's a separate concern.


	Stefan

Re: Gud lord!

[Kai Großjohann]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> Yes, it's a real nightmare to browse.
> We really need some mode that shows a whole directory in a single buffer,
> in an outline-like mode.

I wish I had time to port dired-nst.el to the current version, but
I'm afraid I don't.  :-(

It would be very useful if `i' could insert the subdirs at the
current line, slightly indented.
-- 
This line is not blank.

Re: Gud lord!

[Miles Bader]

On Sat, Jun 07, 2003 at 03:07:47PM -0700, Robert Anderson wrote:
> > Please call back when there's actually a _stable_ and well-supported
> > alternative; currently neither arch nor subversion are.
> 
> Define "stable."  I've been using arch without data loss for over a year
> on a code base of over a half a million lines.

How nice.

Dicsussions of whether to switch to arch or subversion are not uncommon, and
what I've seen so far always manages to bring up `issues' with the various
revision control systems.  It's not always `it lost all my files!'  For
instance in the case of arch, Tom Lord's original implementation is
apparently unusably slow in some cases; I guess there's alternative
implementation (in the works?) but that's still somewhat new (and so to be
treated with caution).  Some other issues with arch that often come include
(1) the somewhat murky rules/conventions for designating source-controlled
files, and (2) the naming conventions, which reflect Tom Lord's somewhat
wacky and idiosyncratic tastes, and put some people off.

Now all these things will eventually be worked out -- but that's the point:
arch is not yet a stable system, it's still undergoing change.  Some people
can deal with that, which is good, 'cause that way the issues _can_ be worked
out.  But emacs is not the project to use for experimenting with revision
control systems.

I certainly am no expert on any of these systems, and am relying on the
`buzz' for my info -- but I think in this case that's proper thing to do.
When some other system is really ready to be used, it will be pretty clear.

[another thing about arch I've wondered about is the use of FTP as a remote
protocol -- though I have no idea whether it's easy/practical to use
something else instead.  For better or for worse, ftp access is problematical
in many cases (including my own!); subversion's standard use of http is much
more practical.]

> I'm also curious what you mean by "well supported."  I can't think of a
> free software project in existence that has a more dedicated maintainer
> than arch does.

Stefan gave a good answer to this.

> Certainly not.  I wouldn't suggest a wholesale change to any system, not
> matter how "stable."  I would suggest a gateway maintainer for a CVS
> head "mirror" in an arch archive

Someone could do that on their own, if they like arch.

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

Re: Gud lord!

[Miles Bader]

On Sat, Jun 07, 2003 at 05:28:04PM -0700, Robert Anderson wrote:
> I'd venture that a lot of such discussion as seen on various well-known
> discussion sites has often bordered on the inane, mostly from hastily
> drawn conclusions about a poorly understood system which does take some
> time to understand and appreciate

You're entitled to your opinion of course, but I've seen enough, from people
that I trust, to feel cautious.

Emacs is a fairly mature system, and has muddled along reasonably well with
CVS's brain-damage, so there's little need to make any quick decisions.  I
think that at some point there'll be an obvious movement by a lot of projects
to adopt either subversion or arch (and I guess there are actually a few more
possible contenders).  I'd guess that Emacs will probably switch too at some
point, and probably won't be the last -- but I don't think it should be among
the first.

Please don't take my comments to mean that I dislike arch -- I don't, from
what little I know about it, it seems like a very interesting and cool system.

In fact, I _like_ the idea of switching to something new and cool because I'm
as annoyed by CVS's bogosities as much as anyone (maybe more than most
people -- as I use a slow modem link, and I understand that arch handles
incremental updates much more efficiently than CVS [sending diffs both ways]),
but again, I think this is a place where some conservatism is warranted.

[Anyway, RMS is the maintainer, and I suspect he may be even more
conservative than me with regard to this issue.]

> > (1) the somewhat murky rules/conventions for designating source-controlled
> > files,
> 
> They are defined by regexps.  I don't think regexps can reasonably be
> considered "murky."

I think the issue was that this decision was based on names at all.  I seem
to recall that there was a way to `register' files as well, but that there
were issues with that as well.

BTW, thank you for posting this, because at the least, it's some impetus to
look more closely at the current state of things.

-Miles
-- 
80% of success is just showing up.  --Woody Allen

Re: Gud lord!

[Robert Anderson]

On Sat, 2003-06-07 at 19:02, Miles Bader wrote:
> You're entitled to your opinion of course, but I've seen enough, from people
> that I trust, to feel cautious.

Cautious is good.  But I'm very interested to hear what you've "seen
from people you trust."  I contribute to arch and I'm always looking for
ways to improve it.

> Emacs is a fairly mature system, and has muddled along reasonably well with
> CVS's brain-damage, so there's little need to make any quick decisions.

I think people felt that way about ed before emacs came around.  etc.

> I'd guess that Emacs will probably switch too at some
> point, and probably won't be the last -- but I don't think it should be among
> the first.

I'd agree with that.  I never said "emacs needs arch today."  I merely
pointed out that stuff like the file renaming handcuffs are removed when
using arch.

> In fact, I _like_ the idea of switching to something new and cool because I'm
> as annoyed by CVS's bogosities as much as anyone (maybe more than most
> people -- as I use a slow modem link, and I understand that arch handles
> incremental updates much more efficiently than CVS [sending diffs both ways]),

For some use cases, it's much better than that, even.  If you're ok
with, say, daily updates from upstream, you can run a cron job to grab a
local mirror overnight, and get fully local disk performance for all
daily work.

> > They are defined by regexps.  I don't think regexps can reasonably be
> > considered "murky."
> 
> I think the issue was that this decision was based on names at all.  I seem
> to recall that there was a way to `register' files as well, but that there
> were issues with that as well.

No offense, but I'm pretty confident that any objections to the basic
architecture here are based on ignorance of what the architecture is,
and what it allows.  The basic reason being that the entire thing can be
made essentially isomorphic to CVS behavior in this area, if that's
really what you want, but it also allows much more flexibility and power
as well.  So it can't really be a step backward, and I'm pretty
confident that it's a powerful step forward.  There is possibly an issue
regarding defaults, but that is much less worrisome than questions about
basic architecture or functionality.

There's two layers here: the outer layer is based on naming conventions
to determine what files are _candidates_ for source, and the inner layer
is based on a "tagging method" (which granted, is possibly confusing
terminology for a CVS-head) which determines which of those files are
versioned.  The simplest "tagging method" is the very CVS-like "explicit
tagging" - which means you have an "add" operation to version a file in
the tree and a "delete" operation to stop versioning a file.  So with a
"naming convention" of "everything is source" and "explicit tagging,"
you're essentially looking at a very CVS-like system for determining
what files to version.  But there's much more to it, and for good
reasons that require considerable background and revctl mind-expansion
for the typical person coming from a CVS background.

Now, regarding this idea of "naming conventions" that people seem to be
skeptical of:  find me a seasoned programmer who doesn't have a script
or alias or some mechanism which is used for finding or grepping through
files he's interested in in a source or project tree.  I've had "sfind"
and "sgrep" and "mktags" (source find/grep, tag source files) scripts
for 10 years, which filter out files which I don't want polluting my
searches for things in my source tree (say, CVS control files or core
files or dot-oh files).  This is the spirit of the "naming conventions"
in arch.  It standardizes and builds this kind of functionality right
into the revctl, per-project.  Think of naming conventions as a
specialized and customizable find command for source trees, because that
is exactly the functionality it provides.  It's loosely related to the
idea of .cvsignore in CVS but much more powerful.

> BTW, thank you for posting this, because at the least, it's some impetus to
> look more closely at the current state of things.

No prob.  I don't mean to push, but I think it's important to remind
people that alternatives exist when they complain about limitations of
their current tools.

Bob

Re: Gud lord!

[Per Abrahamsen]

Robert Anderson <rwa@alumni.princeton.edu> writes:

> Cautious is good.  But I'm very interested to hear what you've "seen
> from people you trust." 

Here is one such message:

  < http://gcc.gnu.org/ml/gcc/2002-12/msg00140.html >

Of course, that is more than 5 month ago by now.

Re: Gud lord!

[Miles Bader]

On Sat, Jun 07, 2003 at 05:28:04PM -0700, Robert Anderson wrote:
> I'd venture that a lot of such discussion as seen on various well-known
> discussion sites has often bordered on the inane, mostly from hastily
> drawn conclusions about a poorly understood system which does take some
> time to understand and appreciate

You're entitled to your opinion of course, but I've seen enough, from people
that I trust, to feel cautious.

Emacs is a fairly mature system, and has muddled along reasonably well with
CVS's brain-damage, so there's little need to make any quick decisions.  I
think that at some point there'll be an obvious movement by a lot of projects
to adopt either subversion or arch (and I guess there are actually a few more
possible contenders).  I'd guess that Emacs will probably switch too at some
point, and probably won't be the last -- but I don't think it should be among
the first.

Please don't take my comments to mean that I dislike arch -- I don't, from
what little I know about it, it seems like a very interesting and cool system.

In fact, I _like_ the idea of switching to something new and cool because I'm
as annoyed by CVS's bogosities as much as anyone (maybe more than most
people -- as I use a slow modem link, and I understand that arch handles
incremental updates much more efficiently than CVS [sending diffs both ways]),
but again, I think this is a place where some conservatism is warranted.

[Anyway, RMS is the maintainer, and I suspect he may be even more
conservative than me with regard to this issue.]

> > (1) the somewhat murky rules/conventions for designating source-controlled
> > files,
> 
> They are defined by regexps.  I don't think regexps can reasonably be
> considered "murky."

I think the issue was that this decision was based on names at all.  I seem
to recall that there was a way to `register' files as well, but that there
were issues with that as well.

BTW, thank you for posting this, because at the least, it's some impetus to
look more closely at the current state of things.

-Miles
-- 
"Whatever you do will be insignificant, but it is very important that
 you do it."  Mahatma Ghandi

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.

Re: Gud lord!

[Richard Stallman]

    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

If we are going to discuss what version control system to use,
let's not do it under the rubric of "open source".

The open source movement was formed by people who rejected our ideals,
as a way of hushing up discussion of them.  Now we have to work hard
to inform people that the free software movement still exists.  To
have a discussion about our work under the heading of "open source"
would be counterproductive; therefore, I never do that.

See http://www.gnu.org/philosophy/free-software-for-freedom.html for
more explanation.

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

    Define "stable."  I've been using arch without data loss for over a year
    on a code base of over a half a million lines.

The people who maintain Savannah don't want to run experimental
programs on it.

Re: Gud lord!

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1127 bytes --]

On Sun, Jun 08, 2003 at 08:21:20PM -0400, Richard Stallman wrote:
>    Define "stable."  I've been using arch without data loss for over a year
>    on a code base of over a half a million lines.
>
>The people who maintain Savannah don't want to run experimental
>programs on it.

Fortunately, they don't have to.  As long as Savannah gives ftp, sftp,
or Web-DAV access to users directories, that is all that is needed.  The
brains and logic of arch are on the client, not the server side.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Gud lord!

[Richard Stallman]

    Fortunately, they don't have to.  As long as Savannah gives ftp, sftp,
    or Web-DAV access to users directories, that is all that is needed.

Would you like to write up a proposal?
I don't think they want to run ftp, since it is easy
to sniff passwords with ftp.

Re: Gud lord!

[Robert Anderson]

On Mon, 2003-06-09 at 16:00, Richard Stallman wrote:
>     Fortunately, they don't have to.  As long as Savannah gives ftp, sftp,
>     or Web-DAV access to users directories, that is all that is needed.
> 
> Would you like to write up a proposal?

For what, in particular?

Bob

Re: Gud lord!

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1240 bytes --]

On Mon, Jun 09, 2003 at 06:28:22PM -0700, Robert Anderson wrote:
>On Mon, 2003-06-09 at 16:00, Richard Stallman wrote:
>>     Fortunately, they don't have to.  As long as Savannah gives ftp, sftp,
>>     or Web-DAV access to users directories, that is all that is needed.
>> 
>> Would you like to write up a proposal?
>
>For what, in particular?

Well, if you could write a short document telling what Savannah needs to
different from their current methodology to support arch, I think that
is what is being asked for.  It could probably be a one-liner: enable
sftp in the ssh daemons configuration.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Gud lord!

[Richard Stallman]

    >     Fortunately, they don't have to.  As long as Savannah gives ftp, sftp,
    >     or Web-DAV access to users directories, that is all that is needed.
    > 
    > Would you like to write up a proposal?

    For what, in particular?

For what the Savannah people would install and do
so as to support use of Arch.

Re: Gud lord!

[Robert Anderson]

On Sun, 2003-06-08 at 17:21, Richard Stallman wrote:
>     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
> 
> If we are going to discuss what version control system to use,
> let's not do it under the rubric of "open source".

My use of "open source" is no "rubric" associated with any particular
group.  But as my audience here may ascribe a certain meaning to that
phrase, I'll try to use a different one here.

>     Define "stable."  I've been using arch without data loss for over a year
>     on a code base of over a half a million lines.
> 
> The people who maintain Savannah don't want to run experimental
> programs on it.

Are ftp, ssh, and apache experimental programs?  Those are the only
programs relevant to the maintainers of Savannah for use of arch.

Bob

Re: Gud lord!

[Richard Stallman]

    > If we are going to discuss what version control system to use,
    > let's not do it under the rubric of "open source".

    My use of "open source" is no "rubric" associated with any particular
    group.

The term "open source" is the name of a movement that was formed in
1998 to reject the free software movement's ideals.  Even if you did
not intend the term to indicate an affiliation with that movement, its
use tends to convey one anyway.

Many open source supporters tell people we are part of the open source
movement.  We are trying to show people that is not so.

Re: Gud lord!

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     > If we are going to discuss what version control system to use,
>     > let's not do it under the rubric of "open source".
> 
>     My use of "open source" is no "rubric" associated with any particular
>     group.
> 
> The term "open source" is the name of a movement that was formed in
> 1998 to reject the free software movement's ideals.

In my opinion, not so much reject as downplay them, in order to
sucker^W convince people to develop free software that wouldn't think
of doing so `merely' for the sake of freedom.

I'd consider some of the capitalization achieved for free software
companies (like RedHat that acquired Cygnus and thus keeps GCC going
financially) to be due to the "Open Software" hype at that time.

> Many open source supporters tell people we are part of the open
> source movement.  We are trying to show people that is not so.

We profit in some ways from it.  Of course, there is also backlash
when business finds itself having problems from exalted expectations.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Gud lord!

[Jonathan Walther]

[-- Attachment #1.1: Type: text/plain, Size: 1313 bytes --]

On Tue, Jun 10, 2003 at 02:54:23PM +0200, David Kastrup wrote:
>I'd consider some of the capitalization achieved for free software
>companies (like RedHat that acquired Cygnus and thus keeps GCC going
>financially) to be due to the "Open Software" hype at that time.

I can't help but wonder, wouldn't Cygnus have continued to develop GCC
and make a decent living at it, even if it hadn't been acquired by
Redhat?

>We profit in some ways from it.  Of course, there is also backlash
>when business finds itself having problems from exalted expectations.

Freedom often isn't "profitable"; what it does do is make our lives
better in myriad intangible, but important ways.

Jonathan

-- 

    It's not true unless it makes you laugh,                           
             but you don't understand it until it makes you weep.      

    -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

                     Geek House Productions, Ltd.

  Providing Unix & Internet Contracting and Consulting,
  QA Testing, Technical Documentation, Systems Design & Implementation,
  General Programming, E-commerce, Web & Mail Services since 1998

Phone:   604-435-1205
Email:   djw@reactor-core.org
Webpage: http://reactor-core.org
Address: 2459 E 41st Ave, Vancouver, BC  V5R2W2

[-- Attachment #1.2: Type: application/pgp-signature, Size: 307 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: Gud lord!

[Richard Stallman]

    > The term "open source" is the name of a movement that was formed in
    > 1998 to reject the free software movement's ideals.

    In my opinion, not so much reject as downplay them, in order to
    sucker^W convince people to develop free software that wouldn't think
    of doing so `merely' for the sake of freedom.

They reject any public statement endorsing our ideals, and their
statements often contradict these ideals.  Some open source supporters
may believe in these ideals privately, but that movement rejects them.

    I'd consider some of the capitalization achieved for free software
    companies (like RedHat that acquired Cygnus and thus keeps GCC going
    financially) to be due to the "Open Software" hype at that time.

Some GCC developers work for Red Hat, but it is a mistake to say that
Red Hat "keeps GCC going".  GCC isn't a Red Hat product and was not a
Cygnus product.  Cygnus used to say things which gave that impression,
and we were frequently angry at them.  Fortunately Red Hat doesn't
seem to try to do that.

Re: Gud lord!

[Juanma Barranquero]

On Sat, 07 Jun 2003 12:12:18 -0400
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> I don't have a particular opinion on this except I'd like to remind
> people that CVS deals very poorly with file moves

I know. In fact, when talking about moving files I specifically asked if
there was a way to keep information for moved files, and the answers
said: "No, the best way is cp, cvs rm, cvs add."

> so it's best
> to refrain from doing them unless there's a really compelling reason.

From Richard Stallman, Wed, 14 may 2003:

> Can anyone suggest Lisp files that ought to be moved to a different
> place under the `lisp' directory?

so people shouldn't be surprised if finally some lisp files get moved. I
didn't see a single reply to that thread that said: "No, please, let's
not move anything unless there's a *very strong* reason, because we'll
lose history and it's going to be a PITA."

> I'd be happy to see gud.el reintegrate its lisp/gud.el location for
> this reason.
> 
> 	Stefan "who wasn't particularly thrilled by the move of outline.el
> 	        for example"

I'm thrilled by every move whose result makes the lisp/ structure and
organization better (for, admitedly, highly subjective definitions of
"better"). Tracking changes in CVS files is harder after they move,
true; but I was under the feeling that lisp/ organization was there to
help users, not developers :)

Fact is, all these changes except the last one (gud.el) were suggested
in the above mentioned thread and no opinions were heard
against. There were complains for a few modules (Lucid related, mostly)
and those didn't move.

And every one of these changes was approved by RMS; gud's move to
progmodes was in fact *asked* by him (I hadn't thought of it).

Every single time that big changes (big == "affecting more than one file")
are suggested in the list (be whitespace cleanup, macro changes, code or
modules reorganization, whatever), there's little or no discussion, no
one really opposes... and then, after the fact, disagreement suddenly
pop ups. I find it quite a bit tiring. (I'm not talking just about
things where I was involved; the same happened for Ken Raeburn's
Guile-related reorganization, for example.)

                                                                Juanma

Re: Gud lord!

[Miles Bader]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:
> Every single time that big changes (big == "affecting more than one file")
> are suggested in the list, there's little or no discussion, no
> one really opposes... and then, after the fact, disagreement suddenly
> pop ups. I find it quite a bit tiring.

Get used to it.

Obviously it's rather _better_ to speak your mind before a change, if
possible, but:

I often don't follow threads which don't seem interesting in their first
few messages, and there have been big changes discussed at the tail-end
of threads which may not even resemble the original topic!  Even if you
go to the trouble of posting an obvious announcement message (like Kim's
recent warnings), I think it's not uncommon for people to miss such
things for whatever reason.

The effects of big changes are often rather hard to miss once they're
done, however.  If there's a problem, there's a problem, and I'd hope
that people will speak up when they see one, regardless of how annoying
it is for the person who made the change.

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

Re: Gud lord!

[Juanma Barranquero]

On 09 Jun 2003 17:11:37 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> Juanma Barranquero <jmbarranquero@laley.wke.es> writes:
> > Every single time that big changes (big == "affecting more than one file")
> > are suggested in the list, there's little or no discussion, no
> > one really opposes... and then, after the fact, disagreement suddenly
> > pop ups. I find it quite a bit tiring.
> 
> Get used to it.

Funny, you seem to be arguing that:

 1) People should complain when they see something wrong, even if it's a
bit (or much) late.

 2) I should get used to this behavior, instead of complaining if I feel
is wrong :)

> I often don't follow threads which don't seem interesting in their first
> few messages, and there have been big changes discussed at the tail-end
> of threads which may not even resemble the original topic!

Yes, I undestand that. But we're now talking about a thread whose *first
message* was one from RMS specifically asking for files to move. People
who do feel strongly against moves (unless *really* justified) should
perhaps have noted so then, shouldn't they?

> The effects of big changes are often rather hard to miss once they're
> done, however.  If there's a problem, there's a problem, and I'd hope
> that people will speak up when they see one, regardless of how annoying
> it is for the person who made the change.

Sure. OTOH, inconveniences when dealing with old changes for a few
modules does not seem like a problem to me (My Very Subjective Opinion,
of course), because there's not that often you have to go through CVS to
see the exact lines changed. ChangeLog entries are still there, after
all, to get a feeling of when/what/why/by whom something changed.


                                                                Juanma

Re: Gud lord!

[Miles Bader]

Juanma Barranquero <jmbarranquero@laley.wke.es> writes:
> Funny, you seem to be arguing that:
>  1) People should complain when they see something wrong, even if it's
>     a bit (or much) late.
>  2) I should get used to this behavior, instead of complaining if I
>     feel is wrong :)

Yeah, but complaining about a change probably does more good (because it
often represents a real problem with the change, which should be fixed)
than complaining about complaining (which arguably does harm).

I understand your annoyance, but I think there are understandable, and
hard-to-change, reasons for such after-the-fact complaints.  Note that
they aren't always due to simple tardiness, but sometimes because the
import of a change simply wasn't apparent until it was actually done.

On the specific issue of CVS logs, I kinda agree with you that Emacs'
use of ChangeLog files makes it less of a problem than with some other
projects.

Actually my main complaints with moving files are slightly different:
moving files around screws with patches and local changes, and patches
made across a move end up being enormous..

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: Gud lord!

[Juanma Barranquero]

On 09 Jun 2003 17:42:38 +0900
Miles Bader <miles@lsi.nec.co.jp> wrote:

> Yeah, but complaining about a change probably does more good (because it
> often represents a real problem with the change, which should be fixed)
> than complaining about complaining (which arguably does harm).

Well, in fact I don't feel I was complaining about complaining. I was
complaining about late-complaining (i.e., the optimum, if totally
unreachable, outcome of my complaining would be people complaining
earlier :)

> Actually my main complaints with moving files are slightly different:
> moving files around screws with patches and local changes, and patches
> made across a move end up being enormous..

That I can understand.

When I updated almost every single file on Emacs to clean up trailing
whitespace, I offered to do the same for emacs-unicode so joining back
the tree (sometime in the future) would be easier. One of the
emacs-unicode developers strongly "suggested" to me Not To Do So; local
changes and slow modem connections where mentioned.

                                                                Juanma

Re: Gud lord!

[Stefan Monnier]

> I'm thrilled by every move whose result makes the lisp/ structure and
> organization better (for, admitedly, highly subjective definitions of
> "better").

So am I.

> Tracking changes in CVS files is harder after they move,
> true; but I was under the feeling that lisp/ organization was there to
> help users, not developers :)

Well, actually, I doubt users care about the directory in which
we place bundled files.

> Yes, I undestand that. But we're now talking about a thread whose *first
> message* was one from RMS specifically asking for files to move.  People
> who do feel strongly against moves (unless *really* justified) should
> perhaps have noted so then, shouldn't they?

I only complained when the first wave of moves (the one discussed)
seemed to be followed by more (in this case the move of gud.el).
I wanted to remind people that there's a tradeoff.
I didn't complain at first, because I can live with a small dose
of moves, and I partly like them as well.

> Sure. OTOH, inconveniences when dealing with old changes for a few
> modules does not seem like a problem to me (My Very Subjective Opinion,
> of course),

How much have you had to change/rewrite old code ?  I'd bet not much,
because when you have to do that, the first thing you need to figure out
is which part of the current behavior was intended and which part
is just accidental or historical, and for that you need the log and
the corresponding diffs.  `vc-annotate' is great for this.

> because there's not that often you have to go through CVS to
> see the exact lines changed. ChangeLog entries are still there, after
> all, to get a feeling of when/what/why/by whom something changed.

The frequency totally depends on what you're trying to do.


	Stefan

Re: Gud lord!

[Juanma Barranquero]

On Mon, 09 Jun 2003 09:37:31 -0400
"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> wrote:

> Well, actually, I doubt users care about the directory in which
> we place bundled files.

Once they know what the module does, sure. But for finding what kind of
modules there are and what are they intended to be used for, structure
helps.

> How much have you had to change/rewrite old code ? I'd bet not much,
> because when you have to do that, the first thing you need to figure out
> is which part of the current behavior was intended and which part
> is just accidental or historical, and for that you need the log and
> the corresponding diffs.  `vc-annotate' is great for this.

In the Emacs project, little. At work, I'm basically 100% of my time
changing/rewriting old code. Some of it in CVS repositories, the rest in
SourceSafe.

> The frequency totally depends on what you're trying to do.

Sure.

                                                                Juanma

Re: Gud lord!

[Stephen J. Turnbull]

>>>>> "Juanma" == Juanma Barranquero <jmbarranquero@laley.wke.es> writes:

    Juanma> Once they know what the module does, sure. But for finding
    Juanma> what kind of modules there are and what are they intended
    Juanma> to be used for, structure helps.

That's a doc bug.  Structure the docs, right?  :-)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.

Re: Gud lord!

[Juanma Barranquero]

On Wed, 11 Jun 2003 22:00:01 +0900
"Stephen J. Turnbull" <stephen@xemacs.org> wrote:

> That's a doc bug.  Structure the docs, right?  :-)

Right :)

OTOH there are quite a few modules for which the only documentation is
in the file's comment section(s).

I agree that having every module documented (info-wise) would diminish
the (user) need for structure in lisp/. Developers would still need it,
though ;)


                                                                Juanma

Re: Gud lord!

[Richard Stallman]

We put everything that pertains specifically to editing and working
on programs into the progmodes directory.

Re: Gud lord!

[Juanma Barranquero]

On Sat, 7 Jun 2003 16:37:06 +0100
Nick Roberts <nick@nick.uklinux.net> wrote:

> Where's the logic in putting gud.el in the progmodes directory?

progmodes does not contain just modes for programming languages, but
programming-support modules too: cmacexp, compile, cpp, cwarn, ebrowse,
etags, executable, glasses, hideif, hideshow, mantemp.

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

As a thread not-so-long ago demonstrated, there's no such a thing as a
"natural grouping" for everyone :-)


                                                                Juanma

Not arch (was Re: Gud lord!)

[Nick Roberts]

 > > If there's not a natural grouping, keep the file in the top-level lisp
 > > directory.
 > 
 > As a thread not-so-long ago demonstrated, there's no such a thing as a
 > "natural grouping" for everyone :-)

The files have already been grouped once, though, by keyword and the user can explore them
using finder-by-keyword (`C-h p'). Surely thats enough. 

Perhaps the finder package should be enhanced so that the files, themselves, can be visited
(and not just the commentary displayed) if that is what the user is likely to want to do.

Nick

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>>