[comp.sys.atari.st] Folded release

trb@stag.UUCP ( Todd Burkey ) (07/05/89)

I am posting this message to let everyone who sent me mail know that
the FOLDED sources were sent off to the comp.sources.unix moderator
about 3-4 weeks ago. I also sent off the binaries for the atari.st
and ibm.pc groups at that time. In the past, it has usually taken
about a month to get things posted, so the stuff should be arriving
any time now.

The version that is coming over the net should be FOLDED 0.9d. This
version is very stable, since I used it on several BSD systems for
several months prior to release. On the backburners, I've rewritten
the user interface already in 0.9e, providing toggle'able 'vi-like'
or 'emacs-like' modes for those people who really hate the 'vi-like'
moded editors. This interim release also allows key remapping. I don't
plan on making another official release of FOLDED until 1.0, but there
is info in the 0.9d release notes on how to get updates.

For those of you who missed earlier postings, FOLDED is a folding editor
that implements a text folding feature similar to that used in many
thought processor programs. I geared FOLDED for use primarily for source
code editing, although I find that I also use it in place of my thought
processor programs (i.e. Think-Tank on the PC, Planner, etc). FOLDED
also has some relational, 'hypertext-like', capabilities. These allow
you to relate lines of source code to lines of documentation and even
provide a 'glossary' concept for structures and variables. And, of
course, FOLDED has the basic plethoria of must-have screen editor
features plus snazzy things like dynamic/variable search, box/region
cut and copy, easy multi-buffer editing, and key training.

FOLDED isn't intended to be the do-it-all type editor, so people who are
addicted to emacs may just want to look at integrating the basic folding
and relational features of FOLDED into emacs. I looked into doing this
with LISP macros a long time ago and decided the end result would be too
bulky and slow (I don't have a real fast Unix system), plus I wanted the
exact same editor functionality on all the computers I use (PC's as well
as Unix boxes). If anyone does hack or patch these features into emacs,
though, let me know...I don't mind being proven wrong.
 
  -Todd Burkey
   pwcs!stag!trb
 

t68@nikhefh.hep.nl (Jos Vermaseren) (07/06/89)

There seems to me something wrong with the idea of storing
fold information in a separate file. Files that are subject to
transport between various machines need to have their `fold file'
transported along. This is no problem if the editor resides on
all machines where the file comes by. Once I make changes on
computers that don't have this folding editor my folds are all
useless. It gets even worse if I have to squeeze my files through 
a stream editor. Again I loose my folds.
There is a much better scheme for folds available already in an
editor that is commercially available (for 2 years). It exists
currently on the ST and in the fall it will be released for PC's.
The fold information is stored in the file itself in such a way
that the user can make it into commentary for whatever language
that he happens to work in. The lines with the fold information
have their information from character 4 on till the first colon.
Anything outside is irrelevant for the folds, so in Fortran one
would start such a line with either a C or a * and in basic rem
would do the trick. In C there is more freedom as the /* and the */
don't have to be in the same line. There is even room to let the
editor know whether the fold is open or closed at the time of writing
the file. The folds can be nested. They can be opened and closed at
the press of a button or a key etc. This gives great flexibility
and carrying files around gives no problems. An occasional visit
of such files to vi or emacs looses nothing of the fold information.

So why would anyone store foldinformation in a separate file?

Jos Vermaseren.

Disclamor: These opinions are not entirely mine. I have met other
people with the same questions.

trb@stag.UUCP ( Todd Burkey ) (07/09/89)

In article <218@nikhefh.hep.nl> t68@nikhefh.hep.nl (Jos Vermaseren) writes:
>There seems to me something wrong with the idea of storing
>fold information in a separate file. Files that are subject to
>transport between various machines need to have their `fold file'
>transported along.

Actually, that isn't always true. One reason I keep fold and
relational info in a seperate file is because I don't want thi
info transported when I send a file to someone. Folding and relations
tend to be a fairly personal thing. I may fold closed all my
procedures that I know work and don't need enhancement, while someone
else may just wish to fold closed comment blocks.

The real reason, though, that FOLDED uses a seperate file is that this
method allows you to work with files that you don't want to (or can't)
write out to. For example, I tend to fold and/or relate files a lot without
making any actual code changes. If I saved the fold or relational information
out to the actual file each time, then 'make' would have a field day
everytime I rebuilt the executable. Also, it would be impossible to
fold or perform relations to files that were owned by someone else
(folding actually becomes very useful when you are working with other
peoples code).

Having seperate files isn't as messy as I had first feared. I used
FOLDED in an environment where for 3 months I was editing files at
home on my Unix system, uucp'ing them to work during the day and using
FOLDED on them on both Sun's and Apollo's, and then uucp'ing them
home. As long as you don't do any major line deleting with a foreign
editor, you are pretty well set. Also, keep in mind that a majority of
programmers out there tend to stay on one machine for most of their
programming...and many don't even have PC's at home.

>There is a much better scheme for folds available already in an
>editor that is commercially available (for 2 years). It exists
>currently on the ST and in the fall it will be released for PC's.
>The fold information is stored in the file itself in such a way
>that the user can make it into commentary for whatever language
>that he happens to work in.

One other drawback to this method is the the confusing printouts
you get (I used this method 3 years ago to implement a simple minded
folding capability...and also implemented folding in vi and the Apollo
DM editor using the same concept). A more critical drawback, to me,
is that pure text files can't be folded when you store the information
back into the text file. This was important to me, since I tend to
use FOLDED as a thought processor and task planner as well as a source
code editor.

A thought for future folding techniques might be to allow the
integration of folding information into a file to be a user option or
possibly based on file extension. The ideal answer might be to someday
come up with a better concept of 'files', but the odds on ever
changing to an alternate file-system methodology is pretty slim,
given the mass of unix, pc-dos, etc pushing the single-file,
single-dataset mindset.

  -Todd Burkey
   pwcs!stag!trb

t68@nikhefh.hep.nl (Jos Vermaseren) (07/11/89)

Subject: Re: Folded release
Newsgroups: comp.editors,comp.sys.ibm.pc,comp.sys.atari.st
References: <1989Jul5.150226.24149@stag.UUCP> <218@nikhefh.hep.nl> <1989Jul9.164159.3144@stag.UUCP>

In article <1989Jul9.164159.3144@stag.UUCP>, trb@stag.UUCP ( Todd Burkey ) writes:
> ....    One reason I keep fold and
> relational info in a seperate file is because I don't want thi
> info transported when I send a file to someone. Folding and relations
> tend to be a fairly personal thing. I may fold closed all my
> procedures that I know work and don't need enhancement, while someone
> else may just wish to fold closed comment blocks.

Coding itself is also rather personal. In a well designed program the
folds will enhance the readability of the code like the commentary does.
Therefore the fold info belongs with the code and not outside the program.
What you are proposing is like putting the commentary in a separate file.

> >The fold information is stored in the file itself in such a way
> >that the user can make it into commentary for whatever language
> >that he happens to work in.
> 
> One other drawback to this method is the the confusing printouts
> you get (I used this method 3 years ago to implement a simple minded
> folding capability...and also implemented folding in vi and the Apollo
> DM editor using the same concept). A more critical drawback, to me,
> is that pure text files can't be folded when you store the information
> back into the text file. This was important to me, since I tend to
> use FOLDED as a thought processor and task planner as well as a source
> code editor.
> 
Not so. The fold information is entirely in ASCII.
It is the folding editor of the OCCAM package which makes a mess of it
by storing the fold info in terms of Ctrl-O and Ctrl-P at the beginning
of lines.

> If I saved the fold or relational information
> out to the actual file each time, then 'make' would have a field day
> everytime I rebuilt the executable.

a: In the above scheme folds can be opened or closed at will (one at a
time or all at the same time). Opening a fold doesn't change anything
externally (only the internal representation in the editor is affected),
so the file doesn't get modified. So make is safe.
b: If it would be as you say a simple touch whatever.o would help you out.
   In an editor that allows procedure definitions you could have it touch
   the corresponding .o file before exiting if only folds were changed.
   I admit that that would be messy, but notice the `if'.

I have still not been convinced that the fold info should be in a separate
file. It is true that if one likes to put the fold info in the file
to which it belongs the convention should be chosen very carefully in
full anticipation of things that might be annoying. The same holds
however for schemes that put the fold info outside the file and I can
think of many more ways in which that is annoying.
(Little example: I have two files rather than one. This doubles the number
of files in my directory. This makes my file system much slower when
the (sub)directory contains a large number of source files. On UNIX I
would have to get my file number quota changed).

Jos Vermaseren

schock@lan.informatik.tu-muenchen.dbp.de (Roland Schock) (07/11/89)

Hello World!
Thats my first attempt for an followup article. I hope it won't fail.

I would like to use this FOLDED here too, but I havn't got a copy yet.
But I've heard the net rumours that this editor uses a seperate file
for the folding information. I think it would be much better if you
store this information in the file itself. This can be done in 
specially formatted comments (in C-style, Pascal-style ... but not
in BASIC-style!). If you don't want to distribute the folding info
in your source, you can delete it with an usual text filter.

A good example for a folding editor is the editor supplied with
the INMOS development system for the transputer system. But it runs
only on the transputer itself and not on my DOS machine and it
doesn't create a plain ASCII source file.

Servus
      Roland Schock


P.S.: If anybody knows about another folding editor, I would like to
      hear about it.

trb@stag.UUCP ( Todd Burkey ) (07/13/89)

In article <219@nikhefh.hep.nl> t68@nikhefh.hep.nl (Jos Vermaseren) writes:
>Coding itself is also rather personal. In a well designed program the
>folds will enhance the readability of the code like the commentary does.
>Therefore the fold info belongs with the code and not outside the program.

I feel that the 'act' of folding enhances the readability...in FOLDED,
a fold may consist simply of a hidden comment block, a conditional
logic block that you know works, or maybe the whole procedure. All you
do to create a fold is press a single key and press a key to undo a
fold, so there isn't any useful extra fold info that the user
provides when making a fold. See may apples and oranges comment later
on...

>> One other drawback to this method is the the confusing printouts
>> you get...
>> ... A more critical drawback, to me,
>> is that pure text files can't be folded when you store the information
>> back into the text file.
>Not so. The fold information is entirely in ASCII.
>It is the folding editor of the OCCAM package which makes a mess of it
>by storing the fold info in terms of Ctrl-O and Ctrl-P at the beginning
>of lines.

I wasn't even thinking of OCCAM...I don't even care to see the minimal
amount of information a fold would entail, scattered through my printouts.
For example:

/* ->folded 33 lines */

would be a sufficient amount of info for FOLDED to have inside the
text. Also, as I mentioned before, this still doesn't help me when I
want to fold parts of a memo or project plan I am writing in cleartext.
I would have to remember to run my files through a filter every time
I wanted to mail, print, or do whatever to them just to get rid of the
'extra' ASCII text.

>> If I saved the fold or relational information
>> out to the actual file each time, then 'make' would have a field day
>> everytime I rebuilt the executable.
>a: In the above scheme folds can be opened or closed at will (one at a
>time or all at the same time). Opening a fold doesn't change anything
>externally (only the internal representation in the editor is affected),
>so the file doesn't get modified. So make is safe.

We are probably comparing apples to oranges here. When FOLDED saves
out a file that has folds in it, the exact users' view of the file
is saved in the fold info file. It sounds like your editor always
starts the user out in a fully folded (and probably optionally fully
unfolded) display each time the pertinent file is called up. FOLDED
uses more dynamic folds. For example, if you fold a block, then fold the
procedure the block was in, and then save the file, the next time you
bring up the file the two levels will still be folded. However, if you
then unfold the outer procedure and save the file again, then the next
time you call up the file all you will see is the single folded block. Just
a difference in 'folding' philosophy.

>...The same holds
>however for schemes that put the fold info outside the file and I can
>think of many more ways in which that is annoying.
>(Little example: I have two files rather than one. This doubles the number
>of files in my directory. This makes my file system much slower when
>the (sub)directory contains a large number of source files.

FOLDED looks to see if a directory called 'foldinfo' exists in your
current directory prior to writing out the fold info file. If that
directory exists, then all info and control files go there. Not the
cleanest methodology, but the best I could come up with that would
work as well under Unix as on the PC's. Again, a future solution to
this discussion of where the fold info should go may simply involve
a compromise between our two methodologies...depending on the types
of files being edited and the style of folding being used.

  -Todd Burkey
   pwcs!stag!trb