Date: Tue, 19 Aug 1997 13:11:38 +0200 From: Michael Elbel <me@muc.ditec.de> To: Satoshi Asami <asami@cs.berkeley.edu> Cc: ports@freebsd.org, kline@thought.org Subject: Re: XEmacs-19.15 port is bad Message-ID: <19970819131138.18519@muc.ditec.de> In-Reply-To: <199708191004.DAA20149@silvia.HIP.Berkeley.EDU>; from Satoshi Asami on Tue, Aug 19, 1997 at 03:04:11AM -0700 References: <199708190126.SAA21823@tao.thought.org> <199708191004.DAA20149@silvia.HIP.Berkeley.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970819131138.18519>