Xref: utzoo comp.sys.atari.st:15826 comp.editors:748 comp.misc:5860 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!att!cbnewsh!wcs From: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) Newsgroups: comp.sys.atari.st,comp.editors,comp.misc Subject: Re: Folding Editor - Comments Anyone? Message-ID: <276@cbnewsh.ATT.COM> Date: 25 Apr 89 22:49:08 GMT References: <786@stag.UUCP> Reply-To: wcs@cbnewsh.ATT.COM (Bill Stewart 201-949-0705 ho95c.att.com!wcs) Organization: Your typical phone company involved in your typical daydream Lines: 143 In article <786@stag.UUCP> trb@stag.UUCP ( Todd Burkey ) writes: :This is a request for comments on an editor which will soon be released :for public abuse. I hope to release the sources to comp.sources.unix Great! The overall description of capabilities looks like the kind of stuff I'd love to have around. :also has some relational capabilities. These allow the user to associate :lines in their source files with sections of their documentation files :and vice-versa. And both folding and relations are incorporated in such a :fashion that they don't impact the original text files in any way. Try to do this as generally as possible - users will always try to use a system in ways the author never dreamed of, and if things are straight-forward and general it helps a lot. :So what doesn't FOLDED do? Well, the first release will not have an UNDO :feature. The trash can will have to do. It also is dual mode, something While I find modes easy to use, they seem to be hard for people to learn (especially non-programmers, who you may not care about, but who will use your editor if it's friendly.) (On the other hand, UNDO is much easier in modes. In either case, make the trash can big and easy to rummage around in, and make sure *everything* goes in it (e.g. overwritten characters, indents, ..) If you do need modes, make sure to indicate the mode in big letters somewhere on the screen so users know what's happening. Similarly, Lotus/MSWord-like menus may be boring, but they make it easy to just use. And try to make cursor motion accessible from insert mode as well as command-mode. There are two obvious approaches to modelessness - either always be in command-like mode (the emacs approach where "a" is merely a command to stick an "a" into the text), or alternatively to always be in insert-like mode, with commands recognizable because they start with "\" or come from function keys (=> probably start with ESC.) :The first release also won't have any key binding capability. I still :haven't decided upon the best approach to handle user-defined key maps. Key binding can be very useful for you, the developer, so you can try things out without yet another round of compile-run. If you don't provide it, and you do try to avoid having separate insert and command modes, think really hard about how this affects things like arrow-and-function keys on commonly available terminals. : [ boxes, rectangles, quarter-planes, horizontal scroll ] Yay! These are nice to have. :Also, FOLDED does not retain tab characters. ... replaced with white space Booo! This is *EVIL*! If I put in a tab character, I want a tab character, and I will refuse to use any program that thinks I wanted spaces instead! Especially one that trashes tabs on input. I realize this makes editing rectangles tougher, but tabs are reality, especially for us troff/tbl users. When I put in a tab character, *I mean TAB!*. Similarly, make sure you can support characters with the 8th bit on (i.e. non-ASCII) - for many people, these are real characters! Even \0, if you can - then the editor can hack binary files. You may want to make some arbitrary definition about what tabs mean, but leave the characters there. If you *must* do something obscure with them, here's a suggestion: Instead of using your trick of deleting initial white space and keeping an indent-int, leave the characters there, use the int to keep track of where it indented to, and also keep a flag that says whether there are non-initial tabs on the line. If there aren't any (except initials), you can do things fast&easy, but if there are tabs, the user just waits while you count over from the left. You get your speed, I get my tabs, and you only write 25% more code :-) If you really *must* trash tabs on input, here's an alternative: fill it out with spaces, but use a tab instead of a space as the last character, and treat tabs as width-1 internally. At least then the tab characters are still there, and those of use who want to move tbl-columns as rectangles can be only confused instead of totally confused. It's still evil, but it's compassionate evil:-). : No line-wrap Shouldn't be too hard to add, and it makes editing text much easier - but be careful not to have it break things the way vi's line-wrap does (try doing a "p" at the end of a line!) If you do stick with modes, you may want to have wrap only work in insert mode, and provide a command to explicitly rewrap hunks of text in command mode. :The first release of FOLDED has been tested on BSD4.2/3 (Suns, Symetric, :and Apollo), SYSVR3 (ETA-10), and the ATARI ST. It is being ported by ^^^^^^^ Hey, if you've gotta use System V, might as well start out big! : FOLDING :Worried that folding will change your source code? Don't worry, the :act of folding doesn't affect the edited file at all...even when saved. Great! However, what happens if someone edits the program file with emacs in between FOLDED runs? Do you try to recover (unlikely), warn the user (asking whether to discard the fold-control-file), or just assume it's right, causing random folds to show up? :In summary, folding is fully heirarchical (i.e. a fold can contain any number :of folds), it is smart (it can fold based on programming logic blocks and :indentation level), and it is retained from one edit session to the next. :RELATING: There are a lot of parallels to hypertext work here - you should look into it if you haven't yet. :A second relationship type is that of line relations. These are basically :invisible links that relate a line in one buffer to a line in another buffer. Try not to be too literally line-oriented - if you can put marks at arbitrary points in the file, and maintain them across formatting changes, it makes them a lot more useful. Also, what happens if two buffers are different views of the same file? :Since I added relations very late in the development of the editor, I have a :feeling that this area will see the most improvement over the next year. I've :already decided that I need a few more commands to do things like 'move' :and 'view' relationships. :EDITING COMMANDS: One of the things vi does right (mostly) is maintaining orthogonality between actions and objects: aN object is just a cursor-motion, and the way to do something is to specify the verb (e.g. delete) and the motion. Unlike emacs, this means you don't have totally different commands to delete words, sentences, {}groups, ()groups, lines, ..., and you have a lot more flexibility about creating new object-types (such as FOLDS!). -- # Bill Stewart, AT&T Bell Labs 2G218 Holmdel NJ 201-949-0705 ho95c.att.com!wcs # also found at 201-271-4712 tarpon.att.com!wcs