Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!decuac!hussar.dco.dec.com!mjr From: mjr@hussar.dco.dec.com (Marcus J. Ranum) Newsgroups: comp.unix.internals Subject: hot keys (was: Re: RAM disk.) Message-ID: <1990Oct11.235520.6071@decuac.dec.com> Date: 11 Oct 90 23:55:20 GMT References: <14884@hydra.gatech.EDU> <12454@chaph.usc.edu> Sender: news@decuac.dec.com (Network News) Reply-To: mjr@hussar.dco.dec.com (Marcus J. Ranum) Organization: Digital Equipment Corp., Ultrix Resource Center Lines: 20 In article <12454@chaph.usc.edu> tli@phakt.usc.edu (Tony Li) writes: >This could be easily satisfied by implementing a different user >interface to job control. Or even by programmable function keys. For >example, you might bind one key to be: "^Z%emacs". Poof. > >The difficulty is doing this in a consistent and portable way... Why does it need to be done in a consistent and portable way ? As far as I'm concerned, that kind of kludgery should be done on an individual basis. (read: "keep it out of MY shell|kernel|editor|term") The profusion of absurd command history languages is because it's easier to build that gunk into the shells than to do it correctly, as a layer that runs consistently (or even portably) on top of the shell, editor, mailer, or whatnot. mjr. -- coffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffeecoffee