From: Joe Corneli <jcorneli@mail.ma.utexas.edu>
Cc: emacs-devel@gnu.org
Subject: Re: yet another todo editing system
Date: Mon, 16 Jun 2003 19:21:52 -0500 (CDT) [thread overview]
Message-ID: <Pine.LNX.4.20.0306161919360.1438-100000@linux170.ma.utexas.edu> (raw)
> > 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.
next reply other threads:[~2003-06-17 0:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-17 0:21 Joe Corneli [this message]
2003-06-19 6:08 ` yet another todo editing system Joe Corneli
-- strict thread matches above, loose matches on Subject: below --
2003-06-07 15:37 Gud lord! Nick Roberts
2003-06-07 16:43 ` Robert Anderson
2003-06-07 21:05 ` Miles Bader
2003-06-07 22:59 ` yet another todo editing system Joe Corneli
2003-06-08 7:51 ` Thien-Thi Nguyen
2003-06-08 8:52 ` Joe Corneli
2003-06-08 10:37 ` Thien-Thi Nguyen
2003-06-08 12:32 ` Joe Corneli
2003-06-08 20:05 ` Kai Großjohann
2003-06-09 7:29 ` Joe Corneli
2003-06-09 7:34 ` Miles Bader
2003-06-09 8:01 ` Joe Corneli
2003-06-09 8:16 ` Miles Bader
2003-06-09 9:27 ` Kai Großjohann
2003-06-09 10:54 ` Joe Corneli
2003-06-09 11:41 ` Alex Schroeder
2003-06-09 19:43 ` Thien-Thi Nguyen
2003-06-08 12:48 ` Alex Schroeder
2003-06-09 0:21 ` Richard Stallman
2003-06-09 10:05 ` Joe Corneli
2003-06-09 10:29 ` Joe Corneli
2003-06-15 15:59 ` Richard Stallman
2003-06-16 1:44 ` Joe Corneli
2003-06-16 17:57 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.20.0306161919360.1438-100000@linux170.ma.utexas.edu \
--to=jcorneli@mail.ma.utexas.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).