adam@mtund.UUCP (Adam V. Reed) (10/13/86)
Kenneth Ng: > Now for a little soap box time. It seems to me that one of the > most powerful features of a text editor is the ability to write > custom programs with a language the editor can understand. The > three editors mentioned above have such features. Therefore > practically any needed function can be added easily. This is the > one feature I find so lacking in VI(1). The macro facility kinda > has this, but I haven't seen the functionality of a real programming > language in this editor. Not unless you consider C, and the Korn shell, and every language available under Unix [tm], something other than "real" programming languages. The "!" command (which can be included in map micros) lets you filter any subset of a file through any pipeline. For example, the vi command to alphabetize lines 23 through 77 is ":23,77!sort^M". There is nothing to stop you from writing a custom C program to use in vi macros, but usually there already are Unix tools around to do the job. Note that the output of a filter can be placed in a buffer and executed (there are spelling correction macros that use this capability). Being able to use the shell, or a programming language of one's choice, instead of having to learn a custom editor macro language, is one of the tremendous advantages of working under Unix. I once implemented a syntax-directed editor as a set of vi macros filtering text through a few shell scripts and one C program, in a quarter of the time it would have taken to write an SDE from scratch. When a novice complains that some part of Unix is not powerful enough, the cure is RTFM. Adam Reed
guy@sun.UUCP (10/18/86)
> Being able to use the shell, or a programming language of one's > choice, instead of having to learn a custom editor macro language, > is one of the tremendous advantages of working under Unix. I once > implemented a syntax-directed editor as a set of vi macros filtering > text through a few shell scripts and one C program, in a quarter of the > time it would have taken to write an SDE from scratch. When a novice > complains that some part of Unix is not powerful enough, the cure > is RTFM. Yeah, but what if they're, impossible though it may seem, *right*? Reading the manual won't help.... Yes, there are lots of wonderful things you can do with pipelines and filters, blah blah blah. However, it is not the case that you can do *everything* with them. Consider implementing an editor that performs some complex function on every keystroke, such as the "text mode" in many EMACS implementations. It will do word wrapping as you type; it won't reformat the paragraph as you type, so it's a nuisance to insert into a paragraph, but it beats the h*ll out of having to type the newlines yourself when you get near the end of a line. I sincerely doubt you'll get anything near acceptable performance if you run a filter every time you type a character. As for *having* to learn a "custom" editor macro language, you don't *have* to learn anything if you want to use EMACS. It has a "filter-region" command, that takes a marked region and runs it through a filter, so you *can* do that sort of thing when it's appropriate. The difference here is that you don't have to when it *isn't* appropriate. The fair comparison here would *not* be between writing an SDE from scratch and using "vi" macros, it would be between writing one using "vi" macros and writing one in an EMACS extension language. NOTE: this was not intended as another boring "EMACS is better than 'vi' because I'm used to EMACS and not used to 'vi'" (or *vice versa*) content-free postings of the sort that have been cluttering the net recently. I have my own opinion on the subject, and it's as worthless as everybody else's opinion; EMACS is better for *me*, but that doesn't in any way indicate whether it's better for anyone else. If you are more productive using "vi" than using EMACS, and somebody tells you "no, you'd be better off using EMACS because it's modeless" or "because it has an extension language" or whatever, they're full of it. It is, instead, pointing out that while certain problems can be solved elegantly by gluing UNIX tools together, other problems are better solved using different techniques. Some of UNIX's more ardent admirers tend to dismiss useful ideas that don't fit into their idea of "the UNIX way of doing things", and this is a serious mistake. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)