Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!ames!lll-winken!casey@gauss.llnl.gov From: casey@gauss.llnl.gov (Casey Leedom) Newsgroups: comp.windows.x Subject: Re: Autorepeat key problems with X11R4 Message-ID: <61747@lll-winken.LLNL.GOV> Date: 15 Jun 90 16:01:39 GMT References: <9006102005.AA28531@osage.csc.ti.com> <61614@lll-winken.LLNL.GOV> Sender: usenet@lll-winken.LLNL.GOV Reply-To: casey@gauss.llnl.gov (Casey Leedom) Organization: Lawrence Livermore National Laboratory Lines: 24 | From: janssen@parc.xerox.com (Bill Janssen) | | I think that what you wind up proposing is a general escape mechanism | that allows server vendors to implement vendor-specific extension languages | in the server, no two of which need be alike, which presents a read-eval | interface via `xset sm'. | | This seems so dangerous to standardization, portability, etc., that | I'd hate to see it. I don't think that it's as dangerous as you think it is. I think that the desire to remain within standards would be too strong (DEC aside.) I doubt very much that you'd see this becoming a major part of any server. The goal is simply to provide a way to set server parameters and options at run time instead of only at start up. The desire to set the keyboard autorepeat rate is one example. Another might be switching back and forth between mono and color modes. On the other hand, if someone were to implement a full Display PostScript extension to the X server which allowed the setting of server parameters as a side benefit I wouldn't complain at all, so my opinions should be suspect when it comes to demagogue about embedded interpreters not being dangerous. Casey