liberte@b.CS.UIUC.EDU (05/06/86)
From: liberte@b.CS.UIUC.EDU (Daniel LaLiberte) Since my offer (on April 1 - not a joke) to coordinate the writing of a GNU Emacs Programmers Manual, I have been pretty busy as a grad student. But I managed to put together this update. To facilitate communication between those working on the manual, I am setting up a mailing list (- not quite ready yet, but I wanted to get this out). Everyone who responded will be on the list unless you tell me otherwise. Anyone else is welcome, of course. If you have trouble getting through to me, try someone else on the list. I will be posting progress reports to info-gnu-emacs (which goes to net.emacs also). In summary, I received 4 offers to do writing, 9 offers to proofread, and 3 other supportive responses. All of the writers are open to writing any section, as are all of the proofreaders open to proofreading anything. This is encouraging, but it also leaves me with the responsibility of assigning sections to people. We'll see how well that works. With so few writers at this time, it is important to prioritize sections. Let's first do sections that are most needed and least covered by other documentation. Specifically, to get people started, I consider the GNU Emacs Lisp section most important. But let's concentrate on features of GNU Emacs Lisp not found in other Lisp dialects. Other sections least covered in the Users Manual are streams, processes, command processing (interactive, keymap internals, etc), and a list of 'hidden' variables. Any other priorities? Of course, you are welcome to join in on the fun when you have time for it. To give you an idea who is working on the manual, below are some extracts of responses including some suggestions [and my comments -DML]. Dan LaLiberte liberte@b.cs.uiuc.edu liberte@uiuc.csnet ihnp4!uiucdcs!liberte ----------------------------------- Writers: >ihnp4!rtgvax!ramin (Pantagruel) I think a GNU Emacs Programmers Manual is a great idea. Do count me in on helping write it. Any arrangements would be fine... I have no preferences on topic... It's a little unclear to me though if the audience would be people using GNU Emacs programming to satisfy their editing needs or people who manage/maintain/port GNU Emacs... Naturally, there would be enormous intersection here... [ I had intended the audience to be the former, i.e., GNU Emacs Lisp programmers. There is also need for a manual about GNU Emacs internal internals, i.e., how to hack Emacs. But first things first. -DML] >Jacob Levy <jaakov%wisdom.bitnet@ucbvax.berkeley.edu> I'd like to see such a manual and will be happy to contribute. >Robert L. Krawitz <rlk@ATHENA.MIT.EDU> I like the idea. I gave a talk over January; you might want my notes and examples. The raw notes are rather popular here at athena; you might like it. ... I think I will have plenty of time to help you out with it soon. [ The notes are an excellent start - full of good examples to use. -DML] >ihnp4!cray!hrp Hal Peterson / Cray Research I want one, I want one! I want one so much that I'd be willing to help out with the work. ----------------------------------------------- Proofreaders: >trent@csvax.caltech.edu (Ray Trent) One suggestion (painful, I know) is that you have someone write the permuted index by hand or at least edit it by hand. God knows it's hard enough to find something in one of these manuals... I'll be happy to do some proofreading for you... >Stephen Gildea <mit-erl!gildea@EDDIE.MIT.EDU> I would like to help by being a proofreader. >Skip Montanaro <montnaro%chenengo.tcpip@csbvax> I am not much of a Lisp programmer, however, I will be happy to proofread sections of the manual. >oddjob!matt@lbl-csam.ARPA (Matt Crawford) I'm a long-time emacs user, but not really a `computer-science' person, so I volunteer for some proofreading and editting. >Keiji Kanazawa <kgk%brown.csnet@CSNET-RELAY.ARPA> I think the project is a great idea. I'd like to contribute to it in some way if possible. I have to decide if I want to allot time to actually write any portion of it. I'd say I'm well acquainted with the way rmail works, as well as the general workings of emacs lisp. I'm definitely willing and able to proofread and offer suggestions. >ihnp4!felix!peregrine!mike (Mike Wexler) I am not familar enough to write about this stuff and don't have much experience with texinfo. What I think I would be good at is trying out sections of the manual from a naive programmers point of view. >John Sechrest <sechrest%oregon-state.csnet@CSNET-RELAY.ARPA> Unfortuantly, I don't have the expertise to help you write part of the manual. But I think it is a very good idea. I would be glad to critique it and make editorial type comments on the manual when you have a rough draft. >ssc-vax!gml@uw-beaver.arpa (Gregory M Lobdell) I would be very interested in such a manual, as the Gnu Users Manual is not very helpful is matters such as this. As to helping it be produced, I can read, I know a little bit about TeX, and I've used various versions of Emacs, most notably Tops-20 Emacs, ZEmacs, Goslings, and GNU. I don't know a heck of a lot about the internals of GNU but I have managed to write some functions of my own when I needed to. I also have a rather strong opinion about manuals. I like the Lisp Machine manuals, especially their indexes. ------------------------------------------ Others: >macrakis@harvard.HARVARD.EDU (Stavros Macrakis) This is an excellent idea, and of course I want one when it comes out...! You might also want to set up Tex macros to standardize the appearance of the manual. For instance, you might set up a `function description' macro with slots for name, arguments (including their types and defaults), description, indexing terms, known interactions and bugs, and efficiency considerations. Unfortunately, I don't have the time to contribute to your project >"Mark A. Ardis" <ardis%wang-inst.csnet@CSNET-RELAY.ARPA> I want a GNU Emacs Programmers Manual. Unfortunately, I do not have the time to contribute a section. A section containing advice and guidelines would be helpful. ... [ Good idea. This section would have to evolve to include things that don't quite fit elsewhere. -DML]