srt@maui.cs.ucla.edu (Scott Turner) (06/29/89)
The recent discussion of whether or not mEmacs is programmable has
triggered me to think a bit about whether or not one wants, on a
micro, a programmable editor at all.
There are two major advantages to a programmable editor. First, it
allows multiple users to extend their editor in whatever ways they
desire, independent of other users. This avoids the problem of every
user on a multi-user machine having their own editor. Second, it
allows a single user to customize his editor to the current
application. That is, he can load his C-Mode macros while hacking C
code, the TeX macros while writing text in TeX and so on.
The first reason isn't important in many micros situations. Many
micros are primarily one-user machines. In this case, the user is
free to permanently set up his editor any way he'd like, obliviating
the need for a programmable editor.
The second reason can be important on a single-user machine,
although primarily if the user has a wide-range of editing tasks and
if the editor programs for those tasks are large. In a situation
where there are only a few tasks and the editor programs are
reasonable, they can be built in to the code.
In light of this, what is needed more than a programmable editor is
one that can be programmed at build-time. In some sense, any editor
is build-time programmable - you can always hack the source code.
(And I do :-) But it would be nicer to have simple facilities for
some of the common editor programming tasks. A "keydefs.h" file
which could be modified to change the key definitions, for instance.
A facility for including/excluding code based on the tasks to which
the editor will be applied. And so on.
There are two advantages to this. First, such an editor will have a
quicker start-up time, since it will not have to read initialization
files. And that's important under an OS like MS-DOS where there is no
job control and an editor may be started many times in a session.
Second, such an editor will as small and efficient as possible, since
unused portions of the editor won't be included in the executable.
I've been assuming that the build-time programming occurs at the
source code level, but another possibility is a macro language and a
dump facility, such as GNU Emacs. The disadvantage of this is speed.
The interpreted macro language will never be as fast as native source
code. (Incidentally, does Freemacs have a dump feature?)
-- Scott Turner
Scott R. Turner
UCLA Computer Science "I just want OUTTA here"
Domain: srt@cs.ucla.edunwd@j.cc.purdue.edu (Daniel Lawrence) (06/29/89)
In article <25295@shemp.CS.UCLA.EDU> srt@cs.ucla.edu (Scott Turner) writes: > > The recent discussion of whether or not mEmacs is programmable has >triggered me to think a bit about whether or not one wants, on a >micro, a programmable editor at all. > > There are two major advantages to a programmable editor. First, it >allows multiple users to extend their editor in whatever ways they >desire, independent of other users. This avoids the problem of every >user on a multi-user machine having their own editor. Second, it >allows a single user to customize his editor to the current >application. That is, he can load his C-Mode macros while hacking C >code, the TeX macros while writing text in TeX and so on. > > The first reason isn't important in many micros situations. Many >micros are primarily one-user machines. In this case, the user is >free to permanently set up his editor any way he'd like, obliviating >the need for a programmable editor. > But you are missing a point here. MANY users are not tied to a specific machine. Editing macroes that can be used portably between a one user machine, and a mainframe allow the user to design their own editing environment which is independant of the particular machine they are currently on. > The second reason can be important on a single-user machine, >although primarily if the user has a wide-range of editing tasks and >if the editor programs for those tasks are large. In a situation >where there are only a few tasks and the editor programs are >reasonable, they can be built in to the code. > I have seen simply too many requests for too many different editing environments to resonable compile them all into the editor at one time. Arguable, on a micro, a user could use conditional compilation to configure an editor... but again the question of portability across platforms comes up. > In light of this, what is needed more than a programmable editor is >one that can be programmed at build-time. In some sense, any editor >is build-time programmable - you can always hack the source code. >(And I do :-) But it would be nicer to have simple facilities for >some of the common editor programming tasks. A "keydefs.h" file >which could be modified to change the key definitions, for instance. >A facility for including/excluding code based on the tasks to which >the editor will be applied. And so on. > Specifically for MicroEMACS... there is a EBIND.H header file containing the initial key bindings for the key definitions. Also ESTRUCT.H allows you to keep or discard certain sets of features. Changes to this are rather easy and would allow a user to configure their own editor. > There are two advantages to this. First, such an editor will have a >quicker start-up time, since it will not have to read initialization >files. And that's important under an OS like MS-DOS where there is no >job control and an editor may be started many times in a session. Good programming probably negates this argument. The amount of time needed to read in apx 60 lines of key rebindings at startup time in MicroEMACS is apx .1 of a second (on a 286 PS/2 model 60). Even on a 4 hz XT I doubt this is more than .5 seconds. >Second, such an editor will as small and efficient as possible, since >unused portions of the editor won't be included in the executable. > Key bindings occur in a relativily small static binding table. (MicroEMACS defaults [check the constants in estruct.h] to 300 bindings, occupying 8 * 300 = 2400 bytes on the PC. This is negligible from both a size and efficiency standpoint. Your point is valid for the various environments being macro loaded however. > I've been assuming that the build-time programming occurs at the >source code level, but another possibility is a macro language and a >dump facility, such as GNU Emacs. The disadvantage of this is speed. >The interpreted macro language will never be as fast as native source >code. (Incidentally, does Freemacs have a dump feature?) > > -- Scott Turner > From my understanding of MSDOS, a dump facility would be difficult at best. The executing source code no longer retains the information on where "fixups" need to occur in the executable image in order to load it into different places in RAM. While the original EXE file could be scanned for the code fixups, such an image would also need some way of generating the proper data fixups for the currently declared variables, and heap space. Sounds like a real mess. (And, needless to say, VERY machine dependent). Alternativly, when I needed to produce a mail reader for a large project at Purdue, where I work, I wrote a 1400+ line macro to prototype it. Then, translating the macro to C code, I quite easily linked it in to EMACS, adding a single entry to the tables in EFUNC.H and EBIND.H to make the code accessable. Many times I have put together a "CUSTOM" uEMACS with special commands for special purposes. I am thinking that if the interest is expressed here, I could work on a new chapter for the uEMACS manual which would explain how to do this to others (It's really quite simple.) > > Scott R. Turner > UCLA Computer Science "I just want OUTTA here" Daniel Lawrence voice: (317) 742-5153 arpa: dan@midas.mgmt.purdue.edu The Programmer's Room Fido: 1:201/10 - (317) 742-5533
hollen@zeta.megatek.uucp (Dion Hollenbeck) (06/29/89)
From article <25295@shemp.CS.UCLA.EDU>, by srt@maui.cs.ucla.edu (Scott Turner): > > The recent discussion of whether or not mEmacs is programmable has > triggered me to think a bit about whether or not one wants, on a > micro, a programmable editor at all. > [...good stuff deleted ...] > In light of this, what is needed more than a programmable editor is > one that can be programmed at build-time. [...more deleted...] > There are two advantages to this. First, such an editor will have a > quicker start-up time, since it will not have to read initialization > files. And that's important under an OS like MS-DOS where there is no > job control and an editor may be started many times in a session. > Second, such an editor will as small and efficient as possible, since > unused portions of the editor won't be included in the executable. > [...more deleted..] I agree with you to the advantages of being able to customize and editor in the source code and then re-compile/link to get the executable small, fast-loading and customized. The important point you seem to overlook is that the MAJORITY of people who own PC's and are sophisticated enough to know that a customizable editor would be nice DO NOT OWN COMPILERS, much less know how to program! Even someone like myself, who is a professional programmer, may not have the appropriate compiler and does not have the $200 to get it. Case in point, I purchased ANNA BOOKS XT BIOS source code. It is wonderful!! The only problem is that even though making changes to BIOS source code is a trivial exercise for me, it is set up to be compiled/assembled with MSC 5.0 and I only have 4.0. I am not about to upgrade to 5.0 just to compile one program and I cannot spend the time to write and debug all the functions from the 5.0 standard library which are new since 4.0. I feel that this situation makes the mechanism of GNU Emacs the most desirable. The user gets a completely compiled working version of the editor. He also has a language (Emacs LISP) in which he can extend the editor, debug the text code, and when it is all bug-free, byte-compile it for faster loading. I think that you are missing the point by not seeing the greater picture. Even if as you say, you are going in and out of your editor all day long, lets look at some figures. Assume that it takes 20 seconds to load the editor (which is a VERY long time to load any application program on a PC). Let us also assume that you add a text file which contains your new editor extensions and that extends the editor load time to 30 seconds. You spend 10 minutes programming. Your load time even when 150% of the original only consumes 5% of your use time. But, you retort, I load my editor, change a couple characters, exit, load it again, change a couple..... and so forth. If you have this kind of use, an extensible editor is not what you should be using. You should be using a really small, fast, fairly dumb editor. If you need the sophisticated capabilities of an editor like Emacs (my preference on a Sun workstation on UNIX where I have scads if MIPS) or Multi-Edit (my preference for the PC by a large margin) you should not be bothered by the SMALL extra overhead of loading custom configuration files. On the other hand, if you are doing a cycle of edit, compile, test, edit, compile..... you should be able to do this from inside your editor (both Emacs and Multi-Edit provide these capabilities) and if you can't, I would suggest you have chosen the wrong editor for the task. My opinion is that you can get everything you want in an editor if you have made the right choice of editors and that for some people, the right choice is more than on editor for more than one kind of task. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 uunet!megatek!hollen or hollen@megatek.uucp
rogers@falcon.SRC.Honeywell.COM (Brynn Rogers) (06/29/89)
In article <599@megatek.UUCP> hollen@zeta.megatek.uucp (Dion Hollenbeck) writes: [ stuff deleted] >But, you retort, I load my editor, change a couple characters, exit, >load it again, change a couple..... and so forth. If you have this kind >of use, an extensible editor is not what you should be using. You should I have switched to epsilon. one of the nice features jumping to the dos shell (push). In most applications this leaves you with most of your memory hogged by the editor (or whatever), but epsilon shrinks itself down to about 5k bytes. This leaves plenty of room to run your super mongo compiler with mega make. when done you just exit back to epsilon. (I have a batch file to run epsilon if it is not running, exit back to it if it is.) Brynn Rogers Honeywell S&RC rogers@src.honeywell.com nic.MR.net!srcsip!rogers
les@chinet.chi.il.us (Leslie Mikesell) (06/30/89)
In article <599@megatek.UUCP> hollen@zeta.megatek.uucp (Dion Hollenbeck) writes: >But, you retort, I load my editor, change a couple characters, exit, >load it again, change a couple..... and so forth. If you have this kind >of use, an extensible editor is not what you should be using. You should >be using a really small, fast, fairly dumb editor. >My opinion is that you can get everything you want in an editor if you >have made the right choice of editors and that for some people, the >right choice is more than on editor for more than one kind of task. Exactly! What we need is a truly tiny editor that is suitable for things like quick fixes in source files, replies to mail, etc. One window, one buffer, all text in memory would be fine, with perhaps a few dozen commands (unfortunately RE search & substitute has to be in there..). What it *really* needs, though is the ability to transparently pass its file to the "real" editor when you decide you need to use the more complex functions. That is, it should be able to exec the larger version and maintain its positioning in your current file. It should also be able to read the keymappings that the larger editor uses for its subset of commands. Does anything like this exist? Les Mikesell
oz@yunexus.UUCP (Ozan Yigit) (07/01/89)
In article <25295@shemp.CS.UCLA.EDU> srt@cs.ucla.edu (Scott Turner) writes: > In light of this, what is needed more than a programmable editor is >one that can be programmed at build-time. In some sense, any editor >is build-time programmable - you can always hack the source code. Indeed, there are alternative approaches, as used in DEC's TPU. I believe this is a very nice compromise, and allows specialized editors to be built in a language specialized for editor-building. [I will not argue whether DEC did everything right in TPU, but the idea is very sound.] This was of course the way the original Emacs was built: on top of Teco "editor builder's editor". This is well worth contrasting to the current approach of adding an interpreter/compiler into a fairly fixed editor shell. One may argue pro/cons of each approach, but it is certain that there are many, many ways to build editors, whether or not they are personalized and/or specialized. Not surprisingly, Gnu/Goslings/Unipress/CCA-Emacs ways of doing things is not the *final word* on this area. oz -- They are like the Zen students who, Usenet: oz@nexus.yorku.ca when the master points at the moon, ......!uunet!utai!yunexus!oz continue to stare at his finger.... Bitnet: oz@[yulibra|yuyetti] P. da Silva Phonet: +1 416 736-5257x3976