From owner-freebsd-ports Tue Aug 19 05:23:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id FAA01805 for ports-outgoing; Tue, 19 Aug 1997 05:23:53 -0700 (PDT) Received: from gw.muc.ditec.de (gw.muc.ditec.com [195.212.178.3]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id FAA01785; Tue, 19 Aug 1997 05:23:42 -0700 (PDT) Received: (from nobody@localhost) by gw.muc.ditec.de (8.8.5/8.6.9) id OAA00584; Tue, 19 Aug 1997 14:28:07 +0200 (MET DST) Received: from tartufo.muc.ditec.de(134.98.18.2) by gw.muc.ditec.de via smap (V2.0alpha) id sma000578; Tue Aug 19 14:27:46 1997 Received: by tartufo.muc.ditec.de (/\=-/\ Smail3.1.16.1 #16.39) id ; Tue, 19 Aug 97 13:07 MSZ Message-Id: Date: Tue, 19 Aug 97 14:29 MSZ From: me@tartufo.muc.ditec.de (Michael Elbel) To: kline@thought.org Cc: ports@freebsd.org, asami@freebsd.org Subject: Re: XEmacs-19.15 port is bad Newsgroups: lists.freebsd.ports References: <199708190126.SAA21823@tao.thought.org> Reply-To: me@gw.muc.ditec.de X-Newsreader: NN version 6.5.0 #1 (NOV) Sender: owner-freebsd-ports@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In lists.freebsd.ports you write: >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 old 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. Whaddaya say? -- Michael Elbel, DITEC, Muenchen, Germany - me@muc.ditec.de Fermentation fault (coors dumped)