djk@convent.columbia.edu (David Kurlander) (10/19/88)
I'm doing a survey paper on the various ways that text and graphical editor are extensible. If your favorite editor is extensible in an interesting way, or if you know of some particularly good articles on the subject, please let me know. I do not need any additional information about common editors (eg. Emacs and vi), but I may not be familiar with some of the more eclectic editors. Thanks, David Kurlander djk@vail.columbia.edu
iwm@asun2.ic.ac.uk (Ian Moor) (10/26/88)
The TPU system on VMS is extensible - DEC supply an EDT emulation and the EVE interface written in TPU -- I think the LSE (language sensitive editor) that DEC sells is also written in TPU. There was a good emulation of VI in TPU posted recently. TPU looks a bit like MODULA2/ALGOL68/ADA it has keywords instead of functions :- IF x THEN y ELSE z ENDIF instead of (if x y z) I have seen more and better documentation on using TPU than Emacs lisp (hint). Another interesting extensible editor is XEDIT on IBM's VM/CMS, you think Emacs' dired mode is useful ? Try FILELIST on CMS. Another aspect is that the programming languages that you use to program the editor are also used for writing command files : as if you were to write shell scripts in elisp. There are hooks so that any program like a source level debugger that needs a control language can use REXX.
sommar@enea.se (Erland Sommarskog) (10/30/88)
Ian Moor (iwm@asun2.ic.ac.uk) writes: >The TPU system on VMS is extensible - DEC supply an EDT emulation and the EVE >interface written in TPU -- I think the LSE (language sensitive editor) that >DEC sells is also written in TPU. There was a good emulation of VI in TPU >posted recently. TPU looks a bit like MODULA2/ALGOL68/ADA it has keywords >instead of functions :- > IF x THEN y ELSE z ENDIF instead of (if x y z) >I have seen more and better documentation on using TPU than Emacs lisp (hint). Ah, glad to see someone else mentioning TPU! I have written my customized editor with both Emacs (Unipress) and TPU, and clearly TPU is my favourite. There are two main reasons for this: * TPU has primitives that let you position the cursor anywhere in the window, no matter is there is any text or not. (I.e. if I am in column 50 and goes one line up, I still want to be in column 50 even this line is only 20 characters long.) * Emacs is so goddamm slow! Another thing which appeals to me is that TPU has much less of built-in functions; they are more of basic primitives, which you can use as you like. E.g. I have no use for the built-in move-by- word functions in Emacs, since I define a word differently. TPU doesn't have any word concept at all. It should be added that TPU has many flaws too. I hope to see some of them corrected when I get to play with VMS 5.0. As for layered software using TPU: DEC's VAXNotes is also TPU-based. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.UUCP
kjones@talos.UUCP (Kyle Jones) (11/01/88)
In article <4033@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Another thing which appeals to me is that TPU has much less of >built-in functions; they are more of basic primitives, which you >can use as you like. E.g. I have no use for the built-in move-by- >word functions in Emacs, since I define a word differently. TPU >doesn't have any word concept at all. No version of Unipress Emacs that I have used has a built-in notion of what consitutues a word. It does have a default syntax table which specifies word constituent characters, but these can easily be changed on the fly, or via a per-user initialization file. kyle jones <kjones@talos.UUCP> ...!uunet!talos!kjones
sommar@enea.se (Erland Sommarskog) (11/05/88)
Kyle Jones (kjones@talos.UUCP) writes: >No version of Unipress Emacs that I have used has a built-in notion of >what consitutues a word. It does have a default syntax table which >specifies word constituent characters, but these can easily be changed >on the fly, or via a per-user initialization file. I know about syntax tables, but apparently they don't work. At least not according to the manual. Anyway, doesn't matter how you screw and fix with the syntax tables. (forward-word) will still leave me at the end of next word, instead of the beginning where I want to go. Also, I don't want a move-by-word command pass line borders. If Emacs hadn't had this built-in presumption of what I want, it would have been smaller and faster. Will I'm at it: There is one more feature with TPU that is interesting: If you start up TPU with initiation file at all, *nothing* is defined. CTRL/Y works to interrupt, that's all. Thus, no time is wasted defining keys and functions I don't use. -- Erland Sommarskog ENEA Data, Stockholm Flying is a way of being transported from sommar@enea.se A to B over C and D. Travel you do by train.
jpdres10@usl-pc.usl.edu (Green Eric Lee) (11/15/88)
In article <4052@enea.se> sommar@enea.se (Erland Sommarskog) writes: >Kyle Jones (kjones@talos.UUCP) writes: >>No version of Unipress Emacs that I have used has a built-in notion of >>what consitutues a word. It does have a default syntax table which >>specifies word constituent characters, but these can easily be changed >>on the fly, or via a per-user initialization file. > >you screw and fix with the syntax tables. (forward-word) will >still leave me at the end of next word, instead of the beginning >where I want to go. I haven't used Unipress in years (GNU Emacs spoken here), but I do remember that it has MockLisp extensibility. Simply define a command "next-word" which does ( (forward-word) (back-word) ) and bind it to a keystroke somewhere. > Also, I don't want a move-by-word command pass line borders. What's a line border? Sounds like YOU are making artificial assumptions here! Why should a \n be any different from any other white-space character in a file (as defined by the syntax-table)? In GNU Emacs, I know you COULD write a Lisp function which goes snooping character-by-character and won't pass the end-of-line... but I'd hate to see how slow that'd be (even byte-compiled Lisp is slower than compiled "C"). > If Emacs hadn't had this built-in presumption of what I want, >it would have been smaller and faster. Emacs is large. VERY large. But I have been quite impressed by the speed of GNU Emacs... under heavy load, it's actually FASTER than MicroEmacs (which is 1/10th the size). I recall that Unipress Emacs was no slouch either... only irritating thing about Unipress is that Gosling went hog-wild on his screen redisplay algorithm, meaning that it was a big loss if you had an unoptimized termcap entry that didn't detail, EXACTLY, the cost of each operation (note that most termcap entries are optimized for low line speeds, not for direct-connect 9600 baud, too). Considering that word-forward/word-back etc. are VERY small "C" loops, I really fail to see how they can be the cause of the largeness. Much more likely is "featuritis", and, especially, the command language interpreter. The "Jove" editor implements most of the features of most Emacs variations, including shell windows etc., but has no command interpreter. It is only 120K or so on a 3b2... still larger than "vi", but not really THAT bad considering that it does most of what Unipress or GNU Emacs will do. -- Eric Lee Green P.O. Box 92191, Lafayette, LA 70509 {ames,mit-eddie,osu-cis,...}!killer!elg, killer!usl!elg, etc.
pierson@mist (Dan Pierson) (11/17/88)
In article <97@usl-pc.usl.edu>, jpdres10@usl-pc (Green Eric Lee) writes: >> Also, I don't want a move-by-word command pass line borders. > >What's a line border? Sounds like YOU are making artificial >assumptions here! Why should a \n be any different from any other >white-space character in a file (as defined by the syntax-table)? Sounds like he wants vi-like behavior, some people do. Much as I like it, Emacs behavior is not the revealed truth, in fact the quarter plane model used by the Yale and Rand editors is sometimes very useful. >GNU Emacs, I know you COULD write a Lisp function which goes snooping >character-by-character and won't pass the end-of-line... but I'd hate >to see how slow that'd be (even byte-compiled Lisp is slower than >compiled "C"). It shouldn't really be that bad, just find the appropriate line boundary (e.g. try ^H-f end-of-line) get the char pos, notice if word movement took you past it, and back up and stop moving if so. Sure, this won't be quite as fast as a compiled "C" search, but there aren't very many words on a line of reasonable length so it'll still be much faster than you can see. -- dan In real life: Dan Pierson, Encore Computer Corporation, Research UUCP: {talcott,linus,necis,decvax}!encore!pierson Internet: pierson@multimax.encore.com
irf@kuling.UUCP (Bo Thide) (11/18/88)
In article <4210@encore.UUCP> pierson@mist (Dan Pierson) writes: >In article <97@usl-pc.usl.edu>, jpdres10@usl-pc (Green Eric Lee) writes: > >> Also, I don't want a move-by-word command pass line borders. > >Sounds like he wants vi-like behavior, some people do. Much as I like ^^^^^^^^^^^^^^^^ There seems to be a widespread misconception that moves by words in vi (commands w, W, b, or B) don't pass line borders. THEY DO! At least in HP-UX and 4.2 BSD (try for yourself). Only if you add a blank after the last word on a line will this behaviour be inhibited. ^ Bo Thide'-------------------------------------------------------------- | | Swedish Institute of Space Physics, S-755 91 Uppsala, Sweden |I| [In Swedish: Institutet f|r RymdFysik, Uppsalaavdelningen (IRFU)] |R| Phone: (+46) 18-403000. Telex: 76036 (IRFUPP S). Fax: (+46) 18-403100 /|F|\ INTERNET: bt@irfu.se UUCP: ...!enea!kuling!irfu!bt IP: 192.36.174.1 ~~U~~ -----------------------------------------------------------------sm5dfw
sommar@enea.se (Erland Sommarskog) (11/22/88)
Eric Green (elg@killer.UUCP) writes: >I said: >> Also, I don't want a move-by-word command pass line borders. > >What's a line border? Sounds like YOU are making artificial >assumptions here! If I wrote an editor and made the word commands to never cross line boundaries, I would be guilty of an artificial assumption. However, I was only talking about my own personal taste. The point was that it is no good to build in a concept that doesn't fit every user. Better to offer simple primitives with which the user can implement the higher-level concepts as he want them. >In GNU Emacs, I know you COULD write a Lisp function which goes snooping >character-by-character and won't pass the end-of-line... but I'd hate >to see how slow that'd be (even byte-compiled Lisp is slower than >compiled "C"). That is what I have done. And it's not slower than anything else in this snail to an editor. Hell, I have to wait for echoing of characters sometimes! And right I deleted a line. That took five seconds. Loaded system? Yes, a lot of uucp around, but I work with TPU on a loaded VMS system daily, an d while I'm in the editor I don't even notice this. >only irritating thing about Unipress is that >Gosling went hog-wild on his screen redisplay algorithm, meaning that >it was a big loss if you had an unoptimized termcap entry that didn't >detail, EXACTLY, the cost of each operation (note that most termcap >entries are optimized for low line speeds, not for direct-connect 9600 >baud, too). I mostly run Emacs at 1200 and I see little use of Mr. Goslings algorithms. >Considering that word-forward/word-back etc. are VERY small "C" loops, >I really fail to see how they can be the cause of the largeness. Much >more likely is "featuritis", and, especially, the command language >interpreter. The word functions are of course only an example. The command language interpreter is probably slow, but it shouldn't. That is one of the most important parts of a programmable editor. And for built-in assumptions here's another of my pet peeves. (And in this case Emacs and TPU are equally bad.) If I do an case-insentive search I want the pairs ]} [{ \| to be equivalent just as Aa Bb etc. Simply because they are letters on my screen. (Mayne I should be too hard on Emacs here. There may be a funtion that I've missed.) -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.se "Frequently, unexpected errors are entirely unpredictable" - Digital Equipment
jpayne%flam@Sun.COM (Jonathan Payne) (11/28/88)
You could always write your lisp function do execute the normal word command and then check to see if you went over a line boundery, and THEN go back to the end of the line. Then it would be nice and fast. Buffer position comparisons are nice and fast when the buffer is stored as an array ... JP
jimp@cognos.uucp (Jim Patterson) (11/29/88)
In article <4100@enea.se> sommar@enea.se (Erland Sommarskog) writes: >And for built-in assumptions here's another of my pet peeves. (And >in this case Emacs and TPU are equally bad.) If I do an case-insentive >search I want the pairs ]} [{ \| to be equivalent just as Aa Bb etc. >Simply because they are letters on my screen. (Mayne I should be too >hard on Emacs here. There may be a funtion that I've missed.) GNU Emacs supports essentially this ability via its syntax table. The syntax table allows the printable characters to be classified on a mode-specific basis into such categories as symbol characters, escape characters and string-quote characters. Because it's mode specific, the syntax table when programming C programs, for example, doesn't need to be the same as that for FORTRAN. The category that describes various sorts of parenthesis is the delimiter class; an open-parenthesis is described as an opening delimiter and a close-parenthesis as a closing delimiter. These categories are accessible from the regular-expression pattern matcher using the \sx sequence where 'x' defines the category. For example, \s(\sw+\s) would match any opening delimiter ('\s(') followed by one or word-constituent characters ('\sw+') followed by a closing delimiter ('\s)'). To do what you want, you simply need to define '[' and '{' as opening delimiters, and ']' and '}' as closing delimiters. (They are already in most modes). You can then use '\s(' to match either [ or { and '\s)' for ] or }. -- Jim Patterson Cognos Incorporated UUCP:decvax!utzoo!dciem!nrcaer!cognos!jimp P.O. BOX 9707 PHONE:(613)738-1440 3755 Riverside Drive Ottawa, Ont K1G 3Z4
sommar@enea.se (Erland Sommarskog) (12/02/88)
Jim Patterson (jimp@cognos.UUCP) writes: >I wrote: >>If I do an case-insentive >>search I want the pairs ]} [{ \| to be equivalent just as Aa Bb etc. >>Simply because they are letters on my screen. > >GNU Emacs supports essentially this ability via its syntax table. The >syntax table allows the printable characters to be classified on a >... >To do what you want, you simply need to define '[' and '{' as >opening delimiters, and ']' and '}' as closing delimiters. (They are >already in most modes). You can then use '\s(' to match either [ or { >and '\s)' for ] or }. When I read this I first said to myself "he hasn't understood the problem". Then I looked at it a second time and started to suspect that I was the one the who didn't grasp the solution. You mean that if I type "fiskeb}t" (Eng. fishing boat) at the search prompt, my search routine should translate it to "fiskeb\s)t" before I call (re-search-forward)? I wouldn't say that GNU-Emacs really support this, it's a very obscure trick. And now for the tricky part? How to incorporate \| into this? Preferably also *' and ^~. The problem goes even worse if you want accented letters being equivavlent. I don't know if this is really desired, but I seldom make searches in French texts. In case-insensitive mode TPU concsiders all varieties of "A" (accented, dotted, with ring, upper- and lowercase, I'm speaking eight-bit mode here) as equivalent. Maybe nice for the Frenchmen. For me it is utter folly. What is needed is some mechanism to tell that these characters are equivalent in non-exact searches. -- Erland Sommarskog ENEA Data, Stockholm sommar@enea.se "Frequently, unexpected errors are entirely unpredictable" - Digital Equipment