May 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Notes on the PROBLEMS file 24 years, 11 months

Tor Arntsen

>Second, in the Irix section, it says: > > *** Motif dialog boxes lose on Irix. > > Larry Auton <lda(a)control.att.com> writes: > Beware of not specifying > > --with-dialogs=athena > > if it builds with the motif dialogs [boom!] you're a dead man. FWIW, I have always built with the following (19.10 => 20.4): with-menubars=lucid --with-scrollbars=lucid --with-dialogs=motif and never had a single problem. Irix 5.2, 5.3, 6.2 but not yet 6.5 (I still use the prebuilt xemacs on the SGI freeware CD and I don't know which options it was built with). I'm not saying that there aren't any problems with the motif dialogs, I'm merely saying that you don't necessarily run into them. At least "dead man" sounds a bit strong-worded :-) -Tor

1 participants
0 comments

Re: Assertion failure in mule-charset.h? 24 years, 11 months

Hrvoje Niksic

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > > Jan> The problem is what to do with stuff like x-iso8859-1.el > > Jan> then. > > > > It should be Mule-ized. > > Yes. And now do it such that all of the following are true (which they > currently are). > > 1. Loading the .elc is fast > 2. The .el file is used by both versions. > 3. The .elc can be used by both versions. I believe this is possible, but slightly ugly. My code that creates an ISO 8859-2 char looks approximately like this: (defun latin2-char (code) (if (and (> code 128) (featurep 'mule)) (make-char 'latin-iso8859-2 (- code 128)) (int-char code))) This means that you can take an 8-bit integer code (which is portable across everything) and a charset, and make them into an appropriate Mule character. > Having a conditionally compiled in mule is good however it makes > things like this hard. Basically the will need to be some load time > character set conversion defined such that it is the identity on > latin1 XEmacs. Yes. The right thing to do this is to port `make-char' to non-Mule XEmacs. Me and Olivier Galibert have hashed it out how it needs to be done, now only someone needs to implement it (it's trivial[1]). [1] Trivial as in real programmers' trivial. The dictionary goes like this: trivial == might take me some time to do, but it's not hard. easy == might take me quite some time to do, but it's not too hard. straightforward == possibly very hard and time-consuming, but the algorithm is known in advance. hard == undoable, except by a real programmer.

1 participants
0 comments

Re: New Lisp package kits for egg-its, skk, and APEL 24 years, 11 months

SL Baur

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> apel-1.12 >> Add poem-xfc.el, bytecode portability fix > You need to regenerate everything that loads apel too. In particular > you need 'tm' which is where the problems were in the first place. O.K. They're on the way. I incrementally rebytecompiled apel itself and that was probably a mistake. The updated packages will be Gnus, rmail, tm and apel.

1 participants
0 comments

Re: New Lisp package kits for egg-its, skk, and APEL 24 years, 11 months

Jan Vroonhof

SL Baur <steve(a)xemacs.org> writes: > apel-1.12 > Add poem-xfc.el, bytecode portability fix You need to regenerate everything that loads apel too. In particular you need 'tm' which is where the problems were in the first place. Jan

1 participants
0 comments

Re: Assertion failure in mule-charset.h? 24 years, 11 months

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Jan> The problem is what to do with stuff like x-iso8859-1.el > Jan> then. > > It should be Mule-ized. Yes. And now do it such that all of the following are true (which they currently are). 1. Loading the .elc is fast 2. The .el file is used by both versions. 3. The .elc can be used by both versions. Having a conditionally compiled in mule is good however it makes things like this hard. Basically the will need to be some load time character set conversion defined such that it is the identity on latin1 XEmacs. Doing this fast will probably make the code ugly. Jan

1 participants
0 comments

Re: Documentation bug 24 years, 11 months

Didier Verna

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > The "erroneous" part is that Didier made some fixes to the locale > handling code in input-method-xlib.c that didn't make it into > input-method-xfs.c; so --with-xfs can actually mess up some aspects of > locale handling. No, really ? I can't remember having done anything in only one of those files. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: .emacs mystery 24 years, 11 months

SL Baur

T Kurosaka <- Sun Professional Services" <kuro(a)Japan.Sun.COM>> writes in xemacs-beta(a)xemacs.org: ... > When I start up xemacs in the windowing mode (i.e. w/o -nw), > the minibuffer has the following error message: > Wrong type argument: console-tty-p #<x-console on "localhost:0" 0: > (The Input Method Status area hides the rest of the message.) Do `M-x view-lossage' or select Edit -> Show Message Log from the menu bar to get the full text. > I tried -debug-init but I didn't get any extra info from this. > Running xemacs with -q does not produce this error message. Then it is probably coming from your .emacs. Can you email it to me? > Running xemacs with -q, then pressing "Load .emacs" does not > produce this error message either. This is a mystery. > What is more mysterious is that "Load .emacs" button re-appear > when I use Mew. Any suggestion on how to debug this situation > will be appreciated. Where is Sun Japan located, btw? Tokyo?

1 participants
0 comments

bug: set-terminal-coding-system doesn't work? 24 years, 11 months

T. Kurosaka - Sun Professional Services

Sorry for so many reports (or screams for help :-) today. This is the last one for today. I ran xemacs -nw within an EUC terminal emulator window, and: M-x set-terminal-coding-system euc-japan worked fine for displaying the Japanese text. I then typed: M-X set-keyboard-coding-system euc-japan then I entered some Japanese characters. No characters were inserted and I've got: No word found to check! error in the minibuffer. What is it? -kuro

1 participants
1 comments

Re: Documentation bug 24 years, 11 months

SL Baur

Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org: ... O.K. You made your point. The current wording will stand as is. > I have tested this lightly, it works, but I don't have time to submit > a patch (I'm not synched to a recent version in either the stable or > development branch and there's other experimental stuff---failed---I > need to clean out) until next week at the earliest. That timing is O.K. with me. Alternatively, you could send me the diffs on the files you named and let me pick out the xfontset related portions. I'm going to be off the Internet Thursday and Friday, but if you can get me something by close of business-ish today I can work on it and test it off-line.

1 participants
0 comments

*yaa-hooo*. IBM finally fixed it!!! 24 years, 11 months

Valdis Kl=?iso8859-4?Q?=BA?=tnieks

The long-standing (since AIX 4.3.0 came out in late 1997) problem with Xt wedges seems to be fixed. X11.base.lib.4.3.2.5 is the fix level required. Minimal testing shows that: a) 'xemacs -nw' no longer spins chewing CPU. b) --with-dragndrop=no doesn't seem to be required - I suspect library indigestion with IBM's Motif/CDE libs calling MIT X11R6.4 Xt and X11 libs. I need to be doing more testing on (b) to make sure all of that is clean now. I will be sending a patch for the PROBLEMS file to xemacs-patches shortly. /Valdis APAR NUMBER: <IX89470> RESOLVED AS: PROGRAM ERROR ABSTRACT: <IX89470>: LIBXT.A INCORRECT HANDLING OF EXCEPTIONS IN XTAPPADDINPUT ORIGINATING DETAILS: Applications may malfunction when using XtAppAddInput with XtInputExceptMask. LOCAL FIX AS REPORTED BY ORIGINATOR: RESPONDER SUMMARY: Applications using XtAppAddInput with XtInputExceptMask can generate exception callbacks even when there is no execption. Also, applications can hang intermitently when processing alternate input when using XtAppProcessEvent. RESPONDER CONCLUSION: Fix a macro in libXt's POLL code. Fix hang in XtAppProcessEvent. APAR INFORMATION: Reported to correct a PTF in error: NO Reported as a highly pervasive problem: NO PE Apar?: NoPE HIPER Apar?: NoHIPER Status: CLOSED PER Component Name: AIX 4.3.0 Version: 430 Component ID: 5765C3403 Submitted: 99/04/16 Closed: 99/04/23 Last Modified: 99/05/14 ChangeTeam: TX2727 FIX INFORMATION: Reported release thought to contain the error: R430 APAR is fixed by one or more of the following PTFs: U464241 Applicable Component Levels: R430 PSY U464241 UP A R430 PSY U464241 UP A

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta May 1999