trb@stag.UUCP ( Todd Burkey ) (01/26/89)
...attempt # 2 In article <666@root44.co.uk> joy@root44.UUCP (Joy Nunn) writes: >We are trying to locate a package called SCREEN which is a UNIX >screen editor for the 68000 family. Apparently this was originally A question and a comment. First the question: What special features does SCREEN have (as compared to vi or emacs)? About two years ago, I proposed a folding editor on the net, but I got several responses from people who were already working on such a beast, so I shelved my protocode (I am lazy and don't like to re-invent the wheel). Recently, after some major programming efforts, I found myself wishing that I had written the editor, so I dug up my code (originally written on the ST), moved it to Unix (ripped out the blitting and color text features :-( ), and after much stumbling around structures, hung terminals, and late night incantations I at least have something that folds and can edit...hence it must be a folding editor :). I never did hear what happened with the other PD folding editor projects. I will be releasing the sources for the folding editor in a month or so (as soon as I give it a name (FOLDED?) and find time to stabilize the code and finish bullet-proofing it.) I've been writing it on BSD systems, but it compiles on the Atari ST (and probably the PC for that matter). I will also check it out on S5R3 before releasing it. The code may be somewhat nauseating to look at, since I program in Pascal for a living and C is still a 'hobby', but I will try to get it commented at least. It is a fairly small editor (about 45K compiled...haven't done much optimizing yet), and is more oriented towards being used as a program editor (C or Pascal) or a think-tank like idea processor. Lots of bells and whistles like exact word substitution (change each occurance of variable i to i_var in your code without screwing up words that contain an 'i'), dynamic searching, built-in help and prompting, multi-buffer marking, region and box copy/move/kill, trashcan and clone buffers, auto-indent, etc. I currently use vi, emacs, and the Apollo DM editor on a daily basis (each on a different system). Each of the editors has its nice features and some equally irratating qualities. In order to preserve my sanity (writing an editor in your spare time for three months becomes somewhat boring) I have intentionally left out a lot of the VI/EMACS/APOLLO_DM_EDITOR features that I rarely use. This is bound to irritate some people, but my goal wasn't to duplicate what already existed. My primary goal was simply to see how hard it would be to write an editor that had folding capability. Writing the folding code was trivial...the complexity it added to writing the rest of the editor was incredible. -Todd Burkey "A member of STdNET-The ST developers' Network" trb@stag.UUCP
gringort@decwrl.dec.com (Joel Gringorten) (01/27/89)
In article <703@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes: > >About two years ago, I proposed a folding editor on the net... > >I will be releasing the sources for the folding editor in a month or so... > My primary goal was simply to > see how hard it would be to write an editor that had folding capability. At the risk of seeming incredibly naive, what is "Folding?" -- -joel
arc1@ukc.ac.uk (A.R.Curtis) (01/31/89)
In article <1036@bacchus.dec.com> gringort@decwrl.dec.com (Joel Gringorten) writes: >In article <703@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes: >> >>About two years ago, I proposed a folding editor on the net... >> >>I will be releasing the sources for the folding editor in a month or so... >> My primary goal was simply to >> see how hard it would be to write an editor that had folding capability. > >At the risk of seeming incredibly naive, what is "Folding?" A fold is way of wrapping up bits of text inside a hidden area, which can either be closed, entered or open (using the occam editor as an example). When closed, all you see is "... <some text>" When open, the fold expands in situ and you can see its contents opened up in the current window/buffer/screen, e.g. {{{ declarations VAL fred IS 9 : INT beep, zoop: BOOL abong : }}} SEQ .. blah blah .. When entered, the fold contents assume a new context on the screen, so that all you see is the contents and nothing of the external code/text (the fold may of course contain other folds...). Folds can be filed, so that in fact they point to a file. When opening/entering a fold, the file is read into the editor as if it were there all the time. So much for the explanation. One thing about all this as far as occam goes is the use of non-printing ASCII characters for fold markers. This means (along with other non-free-text things) that you can't use your favourite editor (vi, emacs whatever) to edit it. The idea then for a free-text folding editor is great. I wrote something very quick and nasty a couple of years ago for GNU emacs, which just hid text between patterns. Which isn't very useful. INMOS have a copy of this, and in fact should be doing a full version of the folding editor (but I haven't heard anything more from them). GNU emacs might be a good starting point in fact, since we can use text maps to define the fold structure (no nasty BEL characters etc) and then OPEN FOLD/ENTER FOLD invoke functions to manipulate this map. The map could either prefix the file (as is done in emacs rmail and news interfaces) or be a separate file altogether (cf. the MAC folding editor which I think uses separate files). Defining and selecting regions would give a nice way of representing the folds. Anyone interested in taking this up? Tony Curtis Disclaimer: my views are not necessarily those of my employer. -- ------------------------------------------------------------------------------- Tony Curtis, Computing Lab. | Phone 0227 764000 Univ. Kent at Canterbury | Ext. 3812 or 7617 Canterbury, Kent CT2 7NF | arc1@uk.ac.ukc
trb@stag.UUCP ( Todd Burkey ) (02/02/89)
[I'm adding the atari.st group to this discussion, since FOLDED will be released on the ST at the same time as the Unix version is...if and when I find time to finish it. Since it sounds like there already is a folding editor for the MAC, I'll probably tweak it for the IBM PC next. -Todd] In article <1385@raven.ukc.ac.uk> arc1@ukc.ac.uk (A.R.Curtis) writes: > >[mentions one type of folding using pointers to text files] >[and...] >GNU emacs might be a good starting point in fact, since we can use >text maps to define the fold structure (no nasty BEL characters etc) >and then OPEN FOLD/ENTER FOLD invoke functions to manipulate this >map. The map could either prefix the file (as is done in emacs rmail >and news interfaces) or be a separate file altogether (cf. the MAC >folding editor which I think uses separate files). Defining and >selecting regions would give a nice way of representing the folds. If anyone is interested, I did implement a simple minded folding mechanism for the Apollo DM editor and vi quite a while back. The approach I used was to simply allow the user to mark a region, and then invoke an external command called 'fold' which took the marked region, created a file for the region in a 'folded' directory, and returned a single line of text to the editor such that: int working_proc() { i=i+1; return(i); } becomes: %include "folded/fld001";/* int working_proc() */ By attaching a similar program to a key that unfolds the 'current' line, and by defining still a third key to toggle between three different fold types (C, Pascal, and Troff), it actually turned out to be a useful tool on the Apollos. If there is enough interest, I will dig out the code and post it. The main reason I decided I needed a folding editor rather than stay with the above methodology was simply that I wanted to be able to use the same folding mechanism on all the systems I program on (plus having a seperate file for each fold tends to get a bit slow and messy). FOLDED does create a control file for each file that has folds in it (I originally tried a single control file per directory, but that gets messy when you want to move things around.) The program also will optionally create a configuration file when you exit it such that the next time you invoke FOLDED it will open all the files you were previously editing and place you at the same locations (I used to do this with Emacs). All these extra files may be a bit messy, but they are a LOT better than trying to deal with embedded characters in your source code. I am not sure how easy a true folding capability would be to add to Emacs. To obtain efficient management of the folded text, you really need to build a linked list of all the folds (assuming you are modifying the Emacs source code...and I'm further assuming that Emacs uses a next/prev list structure for lines). If you are doing a Lisp level implementation of the folding, you may go insane trying to keep the folding process managed using a text map. I felt I was losing it many a night while trying to keep all the lists and pointers sane every time something internal got realloced or freed. Some things I still haven't decided on yet for the editor: 1) is it worth searching inside of folded text as well as out (and if something is 'found', then what is the best way to present it to the user)...maybe just a temporary 'unfoldall' mode would suffice. 2) ditto for global substitutes, deletes, etc. 3) slow terminal support...does anyone out there actually bother to even use visual editors over modems slower than 2400 baud? 4) graphics window support...I am very tempted to put in hooks to allow multiple buffers to pop up seperate windows in something like the Bellcore mgr package (X and NeWS still seem too slow and bulky to bother with). Has anyone out there programmed on top of mgr yet? -Todd Burkey "A member of STdNET-The ST developers' Network" trb@stag.UUCP
t19@np1.hep.nl (Geert J v Oldenborgh) (02/03/89)
It may be of interest to hear that a folding editor for the Atari has been for sale for the last 1.5 year or so. It implements folds as special lines that start with three arbitrary characters (to comment out the line), followed by #[ name: (beginning), #] name: (end). This leaves all folding in the editor, so the speed is OK (instanteneous for all operations). A UNIX port is being beta-tested right now, the PC port is in the same stage. As my linker is much slower than the compiler I tend to have large files and I cannot imagine how awful editing was without folds ... * #[ signature: Geert Jan van Oldenborgh t19@nikhefh.hep.nl * #] signature: