Skip site navigation (1)Skip section navigation (2)
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
Message-ID:  <m0x0m82-000f3oC@tartufo.muc.ditec.de>
References:  <199708190126.SAA21823@tao.thought.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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)



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0x0m82-000f3oC>