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