From owner-freebsd-ports Tue Aug 19 04:13:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id EAA28324 for ports-outgoing; Tue, 19 Aug 1997 04:13:39 -0700 (PDT) Received: from gw.vil.ditec.de (gw.vil.ditec.de [192.109.176.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id EAA28319 for ; Tue, 19 Aug 1997 04:13:29 -0700 (PDT) Received: (from nobody@localhost) by gw.vil.ditec.de (8.8.5/8.8.5) id NAA19335; Tue, 19 Aug 1997 13:11:12 +0200 (MET DST) Received: from tick.muc.ditec.de(134.98.18.50) by gw.vil.ditec.de via smap (V2.0) id xma019333; Tue, 19 Aug 97 13:11:04 +0200 Received: (from me@localhost) by tick.muc.ditec.de (8.8.5/8.8.5) id NAA23819; Tue, 19 Aug 1997 13:11:38 +0200 (CEST) Message-ID: <19970819131138.18519@muc.ditec.de> Date: Tue, 19 Aug 1997 13:11:38 +0200 From: Michael Elbel To: Satoshi Asami Cc: ports@freebsd.org, kline@thought.org Subject: Re: XEmacs-19.15 port is bad References: <199708190126.SAA21823@tao.thought.org> <199708191004.DAA20149@silvia.HIP.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.81 In-Reply-To: <199708191004.DAA20149@silvia.HIP.Berkeley.EDU>; from Satoshi Asami on Tue, Aug 19, 1997 at 03:04:11AM -0700 Sender: owner-freebsd-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, Aug 19, 1997 at 03:04:11AM -0700, Satoshi Asami wrote: > * The fix is to backpatch from xemacs-19.14; or else > * move upward to the MULE ports, 20.X. Is this our > * responsibility? or xemacs.org's? Or is this a > * dontcare, just do it? (This is one where I'd roll > * my own fix, rather than burden xemacs.org.... ) > > I think we should fix xemacs-19.14, and have a new port for > xemacs-20.2. Maybe two versions of xemacs20, with mule and without > mule. That's exactly what I'd be doing. Here's the mail I've started before I read your message: In lists.freebsd.ports Gary Kline wrote: >According to Satoshi Asami: >> * After some weeks of using the ports version of xemacs-19.15p7 and >> * trying to get it to work in vi|viper-mode, I gave up and installed the >> * v20.2 release. With identical _dot_ files, this version does work. So >> * I've got my vi that I've been using forever, and the best of the emacs >> * suite. >> >> Did you ask Michael Elbel (the port maintainer)? >> > No, I haven't. This problem, it turns out from > having joined the xemacs mailing list is a known > problem. It is a bug in the x86free code so it > affects viper-mode in both the Linux and BSD realms. > ---Assuming the use of the X86Free code. One gent > who uses Linux and the commercial X package couldn't > understand why I couldn't get viper to work.... > Until someone checked the archives. > > The fix is to backpatch from xemacs-19.14; or else > move upward to the MULE ports, 20.X. Is this our > responsibility? or xemacs.org's? Or is this a > dontcare, just do it? (This is one where I'd roll > my own fix, rather than burden xemacs.org.... ) Unfortunately I haven't been able to follow the xemacs newsgroup and mailinglist lately, what with too much work and changing jobs. I've incindentially stumbled over a problem with XFree86 and xemacs-19.15 and viper before. Maybe it's the same you're seeing? ESC just not working? At that time I've reckoned it was the strange setup I had on the notebook I was using it on. I don't use XFree86 on the desktops here. Anyways, I've found a fix for that: Just use the 19.14 lisp/x11/x-win-xfree86.el and put it in your load-path before anything else or apply the following patch: <<<<<<---snip--- --- /usr/local/lib/xemacs-19.15/lisp/x11/x-win-xfree86.el Wed Dec 18 04:54:22 1996 +++ x-win-xfree86.el Fri May 23 14:13:59 1997 @@ -55,6 +55,6 @@ (while mods (let ((k1 (vector (append (car mods) foo))) (k2 (vector (append (car mods) bar)))) - (define-key key-translation-map k1 k2)) + (define-key global-map k1 k2)) (setq mods (cdr mods)))) (setq mapping (cdr mapping))))) <<<<<<---snip--- > Michael, if you're reading this list, now you know > all that I have. Thanks. Now I'd like some advice - should we put this "fix" in the port? It doesn't seem to disturb anything else, the file certainly only gets loaded if you run XFree86. I'd be voting against simply upgrading xemacs to 20.2. For one they're saying it is still not yet considered an official upgrade path from 19.15. Then the package is *still* larger than 19.15 and I'd frankly hesitate to use it unless I'd need the MULE support. I'm suggesting: a) additional patch to 19.15 so that it works again for everybody b) if I get around to it or some other kind soul adapts the 19.15 port, produce a new xemacs-20 port that contains 20.2 for all those that want the new capabilities and are willing to live with what they'll pay for it. If I'm reading the README right, MULE is right in 20.2, so there'd be no need for a separate port. Whaddaya say? -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped)