liwen@software.org (Andy Liwen) (03/02/90)
We are running SR10.2 on several nodes and are in the process of initiating installation of SR10.2 on the rest of the nodes in our net (about 150). I am working with EMACS to discover how to set up keybindings through the integrated X server. Is there any way to have EMACS recognize all the keys on the keyboard? I hasten to add that we want EMACS to run as an X client. E-mail replies appreciated. BTW, I am also curious if anyone has experimented with shared library optimization of EMACS's load time under 10.2. Any help at optimizing load time of EMACS would also be appreciated. -- Andrew B. Liwen voice 703/742-7289 Software Productivity Consortium,Inc. FAX 703/742-7200 SPC Building -- 2214 Rock Hill Road liwen@software.org Herndon, Virginia 22070 ..!uunet!sunny!liwen
oj@apollo.HP.COM (Ellis Oliver Jones) (03/02/90)
In article <612@software.software.org> liwen@software.org (Andy Liwen) writes: >Is there any way to have EMACS recognize all the keys on the keyboard? I'm no emacs gnuru, but I do know that you have to set up the keyboard config file to tell the share-mode dm to pass keys through to X. Notice that the share-mode server runs, by default, with this command line or one very much like it: /etc/Xapollo -K /usr/X11/lib/keyboard/keyboard.config -D1 s+r- This is done near the end of /etc/rc . The default keyboard.config file has a lot of uncommented "exclude" lines in it, which means that the keys mentioned in those lines are completely inaccessible to X. Edit the keyboard.config file (I exclude nothing but "shell" personally) to put in !!!!! comments. (You could also edit /etc/rc to point to some other file, but BEWARE! it's really `node_data/etc/rc , and if you want things to work the same on diskless nodes, you better ALSO edit /etc/templates/rc .) Then mention the keyboard.config file in the /install/preserve.list file, so it won't get hosed next time somebody installs an OS. And, when you're reading /etc/rc , just pretend you didn't see any references to /etc/daemons/xdm . Please don't be tempted to try xdm on sr10.2...... unless you like debugging your node what we call the Phase II shell. As Mr. Wizard sometimes says on TV, "Don't Try This At Home, Kids!" /Ollie Jones (speaking for myself, not necessarily for HP)
oj@apollo.HP.COM (Ellis Oliver Jones) (03/02/90)
In article <612@software.software.org> liwen@software.org (Andy Liwen) writes: >Is there any way to have EMACS recognize all the keys on the >keyboard? Ooops, almost forgot, the keyboard.config stuff is explained in the manpage Xapollo(1).
achille@cernvax.UUCP (achille petrilli) (03/03/90)
In article <48f1134c.20b6d@apollo.HP.COM> oj@apollo.hp.com writes: >to /etc/daemons/xdm . Please don't be tempted to try xdm on sr10.2...... >unless you like debugging your node what we call the Phase II shell. >As Mr. Wizard sometimes says on TV, "Don't Try This At Home, Kids!" Could you tell me why I shouldn't try to use xdm under sr10.2 ? I actually ran xdm under sr10.2 on a dn2500 and it even worked ! This means I got the X login window and I could login into it, etc. Why shouldn't I use xdm ? I'm puzzled. >/Ollie Jones (speaking for myself, not necessarily for HP) Achille Petrilli
oj@apollo.HP.COM (Ellis Oliver Jones) (03/04/90)
In article <1606@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: >Why shouldn't I use xdm ? Some reasons our policy is "don't try this at home:" (1) We're not yet happy with default xdm configurations. (2) Changes to the way users log in require a great deal of testing, more than we had time for in the SR10.2 release. (3) Changes to the way users log in also require extensive user documentation (in "Getting Started" manuals and the like) not to mention training for the telephone support Customer Service people. If you are prepared to deal with these issues yourself, there's no reason you can't use xdm. We are preparing new software to deal with these issues, but it's not released yet, sorry to say. /Ollie Jones (speaking for myself, not necessarily for HP)
kts@quintro.uucp (Kenneth T. Smelcer) (03/05/90)
In article <1606@cernvax.UUCP> achille@cernvax.UUCP (achille petrilli) writes: >In article <48f1134c.20b6d@apollo.HP.COM> oj@apollo.hp.com writes: >>to /etc/daemons/xdm . Please don't be tempted to try xdm on sr10.2...... >>unless you like debugging your node what we call the Phase II shell. >>As Mr. Wizard sometimes says on TV, "Don't Try This At Home, Kids!" >> >>/Ollie Jones (speaking for myself, not necessarily for HP) > >Could you tell me why I shouldn't try to use xdm under >sr10.2 ? > [ Achille ran xdm on a dn2500 without problems ] >Achille Petrilli I've been running my dn3000 (10.2) using xdm in an X only environment for a couple weeks now, without any problems. The X11R4 apollo documentation actually states that using xdm is the only way to run R4 on Apollo/HP workstations, but it is an unsupported way to do things. What I think Ollie is talking about is that if you have a problem with the node's software, you have two choices. You either have to fix it across the network, or bring the node up in service mode and use the Phase II shell to figure out what's wrong. I don't consider this a serious problem, because if the DM setup was messed up, you'd still only have two choices. You just have to be careful. One question: is there any way to start up DM without it creating the standard login pads? I'd like it to work like the X server does now, just running as a standard background task. Any ideas? -- --=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-- Ken Smelcer Glenayre Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet
dpg@citi.umich.edu (David Gorgen) (03/05/90)
In article <1990Mar4.200610.603@quintro.uucp> kts@quintro.UUCP (Kenneth T. Smelcer) writes: > I've been running my dn3000 (10.2) using xdm in an X only environment > for a couple weeks now, without any problems. The X11R4 apollo documentation > actually states that using xdm is the only way to run R4 on Apollo/HP > workstations, but it is an unsupported way to do things. I wrote that man page, and that isn't what I meant to say. Perhaps I wasn't clear enough. Here is the relevant excerpt: Xapollo now can operate in place of the Apollo Display Manager, as well as from within the DM (as in the past). Standalone operation should be achieved via use of the xdm (1) client. The xdm (1) program has many configuration options, and the defaults may not work for your environment; please read its man page before trying this. The following discussion explains how to set up a node for standalone X. Please note that Apollo does not officially support running systems without the Display Manager. You may have difficulties in following these instructions; if so, you're on your own. I didn't mean "Standalone operation should be achieved via use of xdm" to say that only standalone operation is recommended. What I could have added to emphasize the fact that Xapollo will still run as before (from within the DM environment) is that using the xinit (1) program is the best way to do that. As Ollie has already said, the obstacles to official support of a no-DM environment are more organizational (documentation, support staff training) than technical. (In my personal opinion, of course.) I have been personally running a no-DM SR10.2 node with pre-release and released X.V11R4 for three months, with no problems. -- Dave Gorgen / GTD-East (formerly Apollo Computer), Hewlett-Packard Company located at: University of Michigan, CITI dpg@citi.umich.edu (Center for Information Technology Integration) 313-998-7482 or -7479