Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!lll-winken!uunet!mcvax!unido!pcsbst!jkh
From: jkh@pcsbst.UUCP (jkh)
Newsgroups: comp.editors
Subject: re: Folding Editor
Message-ID: <806@pcsbst.UUCP>
Date: 22 Apr 89 23:58:31 GMT
Reply-To: meepmeep!jkh@pcsbst.UUCP ( Jordan K. Hubbard )
Organization: PCS GmbH, Pfaelzer-Wald-Str. 36, 8000 Muenchen; West-Germany
Lines: 71

Hmmm. Ok, I guess I can give you what amounts to a 2 part comment
since my initial reaction to your posting was somewhat bi-partisan.

First off, I like the basic concepts quite a bit. The implementation
will no doubt leave a few things to be desired, but that can be
remedied in time. My first thought was that FOLDED would be highly
useful for viewing various large unix packages that we all know
and love that make heavy use of #ifdefs for portability. Wouldn't
it be nice if you only saw the code that would actually be compiled
for your machine... Well, it seems from reading your document that
folds can only be created interactively, which kind of queers that.
If you had, say, some mechanism for invoking a process on the
current file/buffer that would return a list of regions to "fold"
(say a starting and ending line) I could then whip up a shell script
that would do something like:

	Run the current file through cpp with all the important macros
	*undefined*.

        Duplicate the output and run cpp on the duplicate copy
	with all macros defined.

        Chew through the original output and the new output with diff -c.

	Generate the "folds" based on which lines diff has marked with '-'.

Several years later (:-) I would get a buffer with all the failing
#ifdef's folded out. One could even put each #include in a fold, to be
expanded if the user actually needed to see what was pulled in.

Naturally, I'm not proposing that you add this *exact* type of mechanism,
only that you provide some means of interacting with the outside world
so that such mechanisms can be implemented.

If you've ever worked with a program as heavily #ifdef'd as, say, kcl
or GNU emacs you'll know that this feature can make the difference between
solving a problem or just throwing up your hands in disgust as your
brain's stack overflows.

A generalized communications mechanism would also allow other utilities to make
join/relation decisions for FOLDED as well. I realize that you also want
this to run on your atari ST (which didn't have multi-tasking last I looked),
but it seems a shame to hamstring UNIX sites for that reason alone.. You
could always, uh, #ifdef it in.


My second and more predictable reaction was: "What?? What for you want
me to learn *another* editor?? Get Real!". Naturally, this subsided after
awhile, but this is going to be a major stumbling block. I currently
use GNU emacs which does 99.5% of everything I want to do. My first
(and possibly my final) reaction was to ponder how to implement the same
functionality in E-Lisp. However, if you can't bring the mountain to
Mohammed, why not strive for greater EMACS (or at least vi) compatibility
in FOLDED? It seems that its major strengths lie in additional functionailty,
not clever new ways of binding the keys. I don't see how you would lose
much (or anything) by following the beaten path. I don't think the fact
that it uses the quarter-plane text model or text panning rather than
wrapping will be a serious problem, I'm more interested in just having
the basic keystrokes work.

I'm curious. Other than learning, what motivated you to write an entire
new editor rather than just adding the relation/folding code to an existing
one? It's what I would have done (can you imagine the splash that a folding
version of vi would have made? Yow).

					Jordan Hubbard
					PCS Computer Systems
					Munich, West Germany

				UUCP:   {pyramid,unido}!pcsbst!jkh
				ARPA:	jkh@violet.berkeley.edu