May 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Input method and dying bug (was: Re: [Success and problem] 21.0 "Oberhasli" ...) 26 years, 6 months

Kazuyuki IENAGA

It is very old article... But I saved this because I have an idea. SL Baur <steve(a)xemacs.org> writes: > > Buld and run fine. Except: > > > 1. --with-xim=xlib, if you kill your XIM while you're running XIM > > featured xemacs, the xemacs will die or hang. > > This might be known problem since from input-method-xlib was > > introduced. > > This is a known problem. I don't think XEmacs can survive any of the > Input Method servers dying. No. As I said before (maybe), the current code lacks of register/unregister the input method. Instead of the implementation, input-method-xlib just opens XIM and attach it to the context. (It is very same with Motif, but Motif does this smart internally) Instead of just opening the XIM, we should set the code to: 1. when opening the context, we should set the callback for XIM that if the XIM is available for the context, use it. XRegisterIMInstantiateCallback 2. when invoking the XIM, we should register the callback that if the XIM is unavailable, then release the XIM. XUnregisterIMInstantiateCallback I'd been having this idea 1 year, but I have no coding power and the enough time for this. Any Xpert?

2 participants
1 comments

Re: is `-name' functional? 26 years, 6 months

Pete Ware

You're confusing class and instance names. xterm -name j -xrm 'XTerm*foreground:red' causes an xterm with a red foreground. Class name is always XTerm. --pete

1 participants
0 comments

Re: is `-name' functional? 26 years, 6 months

William M. Perry

Hrvoje Niksic <hniksic(a)srce.hr> writes: > "Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > > > Hrvoje> I don't know if it ever worked. The funny thing is that I > > Hrvoje> don't even know if it's *supposed* to work. It doesn't > > Hrvoje> work in FSFmacs, for instance. It works for xterm, > > Hrvoje> though. `xterm -name foo' effectively makes xterm ignore > > Hrvoje> all of my resources. > > > > Presumably all your resources are specified with "xterm*...", not > > "XTerm*..."? > > Yup. Should I rename my resources to `xemacs*'? But then you by default get a personal-resource-less xemacs when you run 'xemacs-21.0-b39', etc. Which I find annoying. :) -Bill P.

2 participants
1 comments

fixing temp-buffer-shrink-to-fit 26 years, 6 months

Greg Klanderman

If I correctly recall the situation with temp-buffer-shrink-to-fit, people wanted it to default to t but it was broken. Since I have now added (well the patches might not be applied yet...) primitives to allow doing this right for popper (customizable package implementing a deluxe temp-buffer-shrink-to-fit behavior, a current version of which will find its way into edit-utils shortly), I figured I'd take a quick cut at fixing temp-buffer-shrink-to-fit. This probably needs a bit more work - which is why I'm sending to xemacs-beta. For example temp-buffer-max-height should probably be with respect to the window, not the frame so as not to mess with multi-window configurations. Or maybe it should only shrink the window if originally there was just a single window. I'm not sure what the right thing is short of re-creating all the popper functionality. But it basically does correctly what the code had been trying to do. If someone wants to hack on this more, go for it. greg 1998-05-18 Greg Klanderman <greg(a)alphatech.com> * frame.el (show-temp-buffer-in-current-frame): fix for temp-buffer-shrink-to-fit non-nil. Index: lisp/frame.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/frame.el,v retrieving revision 1.15 diff -u -r1.15 frame.el --- frame.el 1998/05/12 01:06:12 1.15 +++ frame.el 1998/05/19 08:09:05 ＠＠ -1144,20 +1144,34 ＠＠ that would otherwise be introduced by the `pre-display-buffer-function', which is normally set to `get-frame-for-buffer' (which see)." (let ((pre-display-buffer-function nil)) ; turn it off, whatever it is - (let ((window (display-buffer buffer))) - (if (not (eq (last-nonminibuf-frame) (window-frame window))) + (let* ((window (display-buffer buffer)) + (frame (window-frame window))) + (if (not (eq (last-nonminibuf-frame) frame)) ;; only the pre-display-buffer-function should ever do this. (error "display-buffer switched frames on its own!!")) (setq minibuffer-scroll-window window) (set-window-start window 1) ; obeys narrowing (set-window-point window 1) (when temp-buffer-shrink-to-fit - (let* ((temp-window-size (round (* temp-buffer-max-height - (frame-height (window-frame window))))) - (size (window-displayed-height window))) - (when (< size temp-window-size) - (enlarge-window (- temp-window-size size) nil window))) - (shrink-window-if-larger-than-buffer window)) + (let ((max-size (round (* temp-buffer-max-height + (frame-height frame)))) + (size (window-height window))) + (when (< size max-size) + (enlarge-window (- max-size size) nil window)) + (let ((shown (- (window-displayed-text-pixel-height window) + (if (and (> (point-max buffer) (point-min buffer)) + (string= (buffer-substring + (1- (point-max buffer)) + (point-max buffer) + buffer) + "\n")) + (face-height 'default window) + 0)))) + (shrink-window-pixels + (- (window-text-area-pixel-height window) + (max shown (* (1- window-min-height) (face-height 'default window)))) + nil + window)))) nil))) (setq pre-display-buffer-function 'get-frame-for-buffer)

1 participants
0 comments

Problems building on Solaris 2.5.1 26 years, 6 months

Dan Rich

I've run into problems building 21.0-b40 on Solaris. It builds the xemacs binary just fine, but it crashes when trying to rebuild the elc files. I have tried a "make clean", and even removed the .elc files from the lisp directory to make sure that wasn't the problem. This tree has been patched up from b39, but that was a clean download (and there are no .rej files). There's no lisp backtrace, all I get is: Lisp backtrace follows: make: *** [all-elc] Error 139 And here's the output from gdb: GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.16 (sparc-sun-solaris2.5.1), Copyright 1996 Free Software Foundation, Inc... Core was generated by `./src/xemacs -batch -vanilla -l /home/drich/Src/xemacs-21.0-b40/lisp/cleantree'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/dt/lib/libXm.so.3...done. Reading symbols from /opt/local/lib/libtiff.so...done. Reading symbols from /opt/local/lib/libpng.so.2...done. Reading symbols from /usr/openwin/lib/libXpm.so.4.11...done. Reading symbols from /usr/dt/lib/libDtSvc.so.1...done. Reading symbols from /usr/openwin/lib/libtt.so.2...done. Reading symbols from /usr/openwin/lib/libXmu.so.4...done. Reading symbols from /usr/openwin/lib/libXt.so.4...done. Reading symbols from /usr/openwin/lib/libXext.so.0...done. Reading symbols from /usr/openwin/lib/libX11.so.4...done. Reading symbols from /usr/openwin/lib/libSM.so.6.0...done. Reading symbols from /usr/openwin/lib/libICE.so.6.3...done. Reading symbols from /usr/lib/libdl.so.1...done. Reading symbols from /opt/gnu/lib/libncurses.so.3.0...done. Reading symbols from /usr/lib/libkvm.so.1...done. Reading symbols from /usr/lib/libkstat.so.1...done. Reading symbols from /usr/lib/libm.so.1...done. Reading symbols from /usr/lib/libsocket.so.1...done. Reading symbols from /usr/lib/libnsl.so.1...done. Reading symbols from /usr/lib/libelf.so.1...done. Reading symbols from /usr/lib/libc.so.1...done. Reading symbols from /usr/ucblib/libucb.so.1...done. Reading symbols from /usr/lib/libresolv.so.1...done. Reading symbols from /usr/lib/libw.so.1...done. Reading symbols from /usr/lib/libintl.so.1...done. Reading symbols from /usr/lib/libmp.so.1...done. Reading symbols from /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1...done. Reading symbols from /usr/lib/nss_files.so.1...done. #0 0xef074728 in kill () (gdb) where #0 0xef074728 in kill () #1 0x5def4 in fatal_error_signal (sig=11) at emacs.c:262 #2 <signal handler called> #3 0x1e3e8 in mark_object (obj=541931008) at alloc.c:3171 #4 0x363b4 in mark_char_table (obj=20, markobj=0x1e2e0 <mark_object>) at chartab.c:145 #5 0x1e464 in mark_object (obj=540905472) at alloc.c:3181 #6 0x21a34 in mark_buffer (obj=4042240, markobj=0x1e2e0 <mark_object>) at bufslots.h:96 #7 0x1e464 in mark_object (obj=540913152) at alloc.c:3181 #8 0x1940f0 in mark_symbol_value_buffer_local (obj=541407552, markobj=0x1e2e0 <mark_object>) at symbols.c:909 #9 0x1e464 in mark_object (obj=541407552) at alloc.c:3181 #10 0x1e64c in mark_object (obj=4409684) at alloc.c:3235 #11 0x1e5c8 in mark_object (obj=3792896) at alloc.c:3217 #12 0x202c0 in garbage_collect_1 () at alloc.c:4492 #13 0x65cd4 in Feval (form=1079580748) at eval.c:2919 #14 0x130da8 in readevalloop (readcharfun=542641664, sourcename=1616400200, evalfun=0x659b8 <Feval>, printflag=0) at lread.c:1343 #15 0x12f998 in Fload_internal (file=1616400200, no_error=-1606823908, nomessage=-1606823908, nosuffix=-1606823932, codesys=3568640, used_codesys=-1606823932) at lread.c:750 #16 0x66934 in funcall_recording_as (recorded_as=539578260, nargs=5, args=0xefffd264) at eval.c:3193 #17 0x66c50 in Ffuncall (nargs=6, args=0xefffd264) at eval.c:3238 #18 0x2f8d4 in Fbyte_code (bytestr=1613914888, vector=-2144181288, maxdepth=3576832) at bytecode.c:416 #19 0x67f24 in funcall_lambda (fun=540173512, nargs=3, arg_vector=0xefffd5bc) at eval.c:3597 #20 0x66bfc in funcall_recording_as (recorded_as=540173512, nargs=3, args=0xefffd5b8) at eval.c:3214 #21 0x66c50 in Ffuncall (nargs=4, args=0xefffd5b8) at eval.c:3238 #22 0x2f8d4 in Fbyte_code (bytestr=1613397288, vector=-2144699064, maxdepth=3576832) at bytecode.c:416 #23 0x66340 in Feval (form=1076526360) at eval.c:3063 #24 0x63a48 in condition_case_1 (handlers=3555328, bfun=0x659b8 <Feval>, barg=1076526360, hfun=0x63ab4 <run_condition_case_handlers>, harg=-1606823836) at eval.c:1653 #25 0x63c20 in condition_case_3 (bodyform=1076526360, var=-1606823836, handlers=1076526432) at eval.c:1715 #26 0x2fd94 in Fbyte_code (bytestr=1613397208, vector=-2144699144, maxdepth=3576832) at bytecode.c:576 #27 0x67f24 in funcall_lambda (fun=539655780, nargs=1, arg_vector=0xefffdd4c) at eval.c:3597 #28 0x66bfc in funcall_recording_as (recorded_as=539655780, nargs=1, args=0xefffdd48) at eval.c:3214 #29 0x66c50 in Ffuncall (nargs=2, args=0xefffdd48) at eval.c:3238 #30 0x68570 in call1 (fn=539655780, arg0=1615127384) at eval.c:3912 #31 0xf9564 in mapcar1 (leni=73, vals=0x0, fn=539655780, seq=1079021404) at fns.c:3237 #32 0xf9850 in Fmapc (fn=539655780, seq=1079021404) at fns.c:3320 #33 0x66a1c in funcall_recording_as (recorded_as=539574888, nargs=2, args=0xefffe088) at eval.c:3197 #34 0x66c50 in Ffuncall (nargs=3, args=0xefffe088) at eval.c:3238 #35 0x2f8d4 in Fbyte_code (bytestr=1613397648, vector=-2144698712, maxdepth=3576832) at bytecode.c:416 #36 0x67f24 in funcall_lambda (fun=539655864, nargs=2, arg_vector=0xefffe3dc) at eval.c:3597 #37 0x66bfc in funcall_recording_as (recorded_as=539655864, nargs=2, args=0xefffe3d8) at eval.c:3214 #38 0x66c50 in Ffuncall (nargs=3, args=0xefffe3d8) at eval.c:3238 #39 0x2f8d4 in Fbyte_code (bytestr=1613397776, vector=-2144698584, maxdepth=3576832) at bytecode.c:416 #40 0x67f24 in funcall_lambda (fun=539655996, nargs=1, arg_vector=0xefffe9b4) at eval.c:3597 #41 0x66bfc in funcall_recording_as (recorded_as=539655996, nargs=1, args=0xefffe9b0) at eval.c:3214 #42 0x66c50 in Ffuncall (nargs=2, args=0xefffe9b0) at eval.c:3238 #43 0x2f8d4 in Fbyte_code (bytestr=1613689052, vector=-2144407076, maxdepth=3576832) at bytecode.c:416 #44 0x67f24 in funcall_lambda (fun=539947984, nargs=0, arg_vector=0xefffeb68) at eval.c:3597 #45 0x676fc in apply_lambda (fun=539947984, numargs=3576832, unevalled_args=-1606823932) at eval.c:3501 #46 0x664f4 in Feval (form=1078551404) at eval.c:3085 #47 0x63a48 in condition_case_1 (handlers=3555328, bfun=0x659b8 <Feval>, barg=1078551404, hfun=0x3d270 <cmd_error>, harg=-1606823932) at eval.c:1653 #48 0x3d2fc in top_level_1 (dummy=-1606823932) at cmdloop.c:206 #49 0x635bc in internal_catch (tag=-1606745988, func=0x3d2c4 <top_level_1>, arg=-1606823932, threw=0x0) at eval.c:1328 #50 0x3d404 in initial_command_loop (load_me=250564) at cmdloop.c:285 #51 0x5f3f8 in xemacs_21_0_b40_sparc_sun_solaris2_5_1 (argc=8, argv=0xeffff264, envp=0xeffff288, restart=3577416) at emacs.c:1683 #52 0x5fbac in main (argc=0, argv=0xeffff264, envp=0xeffff288) at emacs.c:2100 (gdb) quit And the ever important Installation file: uname -a: SunOS sandman 5.5.1 Generic_103640-14 sun4u sparc SUNW,Ultra-1 ./configure '--site-libraries=/opt/local/lib' '--site-includes=/opt/local/include' '--with-sound=both' '--with-mule' '--dynamic' '--prefix=/usr/local/beta' XEmacs 21.0-b40 "Saanen" configured for `sparc-sun-solaris2.5.1'. Where should the build process find the source code? /home/drich/Src/xemacs-21.0-b40 What installation prefix should install use? /usr/local/beta What operating system and machine description files should XEmacs use? `s/sol2.h' and `m/sparc.h' What compiler should XEmacs be built with? gcc -g -O2 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes Should XEmacs use the relocating allocator for buffers? yes What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/dt/include /usr/openwin/include Where do we find X Windows libraries? /usr/dt/lib /usr/openwin/lib Additional header files: /opt/local/include Additional libraries: /opt/local/lib Runtime library search path: /opt/local/lib:/usr/dt/lib:/usr/openwin/lib:/opt/gnu/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in both network and native sound support. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in Mule (multi-lingual) support. Compiling in XIM (X11R5+ I18N input method) support. Using raw Xlib to provide XIM support. Compiling in support for CDE. Compiling in support for ToolTalk. Compiling in support for OffiX. Compiling in support for Drag'n'Drop ( OffiX CDE ). Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Motif dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- Any ideas?

1 participants
0 comments

[Success] b41-pre1 on Linux/Intel 26 years, 6 months

Kazuyoshi Furutaka

[i686-GNU-linux] Source : patched up from 21.0 beta40 Patch : patch 2.4 Make : GNU Make version 3.76.1 CC : pgcc-2.90.27 980315 (egcs-1.0.2 release) OS : Linux 2.0.34pre13 (RedHat 5.0) X : X11R6.3 (Accelerated-X ver.4.1 w/ XFree86 3.3.1) gdb : GDB 4.16 -- Kazuyoshi Furutaka furutaka(a)tokai.pnc.go.jp furutaka(a)jb3.so-net.ne.jp

1 participants
0 comments

Re: mail-abbrevs change ? 26 years, 6 months

SL Baur

Jeff Miller <jmiller(a)smart.net> writes: > It used to be when I typed in an alias in a vm-mail buffer, then hit the > down arrow key, the alias would expand. > Now it doesn't expand the alias, though using tab seems to work > i see that mail-abbrevs.el was one of the files changes in the latest > package updates. > was this a deliberate or accidental changes? Deliberate. mail-abbrevs no longer installs itself on load (as per Lisp package coding standards we've been starting to enforce). To initialize the keymaps, you need to call `mail-abbrev-init-keys': (mail-abbrev-init-keys mail-mode-map) (mail-abbrev-init-keys message-mode-map)

3 participants
2 comments

Re: OpenBSD support for XEmacs 21.0b40 26 years, 6 months

Hans-Guenter Weigand

> >>>>> "Hans" == Hans Guenter Weigand <hgweigand(a)wiesbaden.netsurf.de> writes: > >Hans> -#if ! defined (__NetBSD__) && ! defined (__linux__) >Hans> +#if ! defined (__NetBSD__) && ! defined (__linux__) && !defined >Hans> (__OpenBSD__) > >This multiple BSD problem is unfortunately kind of gross. Aren't all >the *BSD versions essentially identical from the point of view of >configure? If so, maybe we want to have some preprocessor symbol >that's equivalent to > >defined (__NetBSD__) || defined (__OpenBSD__) || defined (__bsdi__) || ...... > >How many variants are there? I count four (with freebsd). There are four. OpenBSD has not diverged too much from NetBSD, yet. Most times it is sufficient to add __OpenBSD__ where you find __NetBSD__. This will surely change in the future, and it possibly has already for some architectures. This is my very naive approach, which leads to a working XEmacs, at least on a Sparc. >In any case, platform-specific tests are evil, and would be better if >replaced by feature tests in configure.in. This is the direction we >are moving in, long-term. And I am voting for it, too. But I'm not an experienced hacker. It is the first time I deal with autoconf/configure. It is a huge, powerful system, it takes some time to get through. Platform-specific == operating-system-specific? Some of the architectures OpenBSD supports need special treatment in some cases, so #ifdef __OpenBSD__ is not always a solution. So I join this movement. :) BTW, sparc.h needs some cleanup. A comment already says what's to do. A sun-specific (solaris-specific?) definition needs to be moved to sun.h. This removes the #ifdef kludge in sparc.h, too. >Martin > >This is not a veto. Thanks! I understand this patch as an initial trigger, not as a final solution. -hgw

1 participants
0 comments

Re: [Success] 21.0 "Russian White" XEmacs Lucid (beta39) on i386-pc-c ygwin32 26 years, 6 months

Adrian Aichner

>>>>> "Jason" == Jason R Mastaler <jason(a)4b.org> writes: Jason> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> I've made a note of the new mailing list and a future version of >> build-report will probably offer a choice whether to send to >> xemacs-beta (mainly to ask for help) or to xemacs-beta-reports (mainly >> for those boring reports starting out with [Success]) ;-> Hello Jason, Steve, All! Would it be reasonable for build-report.el to send build-reports announcing [SUCCESS] to xemacs-build-reports(a)xemacs.org and those reporting [FAILURE] to xemacs-beta(a)xemacs.org? As an alternative, would it be reasonable to query the user for the destination E-mail address with a history set to a list of valid E-mail addresses (initial-content could be xemacs-build-reports(a)xemacs.org)? What I have right now is this: (defcustom build-report-destination '( "XEmacs Build Reports List <xemacs-build-reports(a)xemacs.org>" "XEmacs Beta List <xemacs-beta(a)xemacs.org>" ) "*The mail address XEmacs Build Reports should go to." :type '(repeat string) :group 'build-report) (compose-mail (read-string "Build Report Destination: " (car build-report-destination) 'build-report-destination) ...) Any suggestions are highly welcome! Best regards, Adrian Jason> Oops, ignore my last message, I hadn't read this far yet. -- Adrian Aichner Applications Engineer Teradyne GmbH Semiconductor Test Group Telephone +49/89/41861(0)-208 Dingolfinger Straße 2 Fax +49/89/41861-217 D-81673 MÜNCHEN E-mail aichner(a)ecf.teradyne.com

1 participants
0 comments

[Failure] xemacs-21.0-b40 on DU4.0D with CDE 26 years, 6 months

Kevin Oberman

DU4.0D on Alpha Personal Workstation 500AU with CDE, Motif, xpm. ./configure --without-gcc --cflags=-O2 --with-gnu-make --site-includes=/usr/local/include Configures and built with no problems, but temacs fails to load, hanging with the following messages: cd ./lib-src && make CC='cc' CFLAGS='-O2' LDFLAGS='' CPPFLAGS='' all make[1]: Entering directory `/home/oberman/utils/xemacs-21.0-b40/lib-src' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/oberman/utils/xemacs-21.0-b40/lib-src' cd ./lwlib && make CC='cc' CFLAGS='-O2' LDFLAGS='' CPPFLAGS='' all make[1]: Entering directory `/home/oberman/utils/xemacs-21.0-b40/lwlib' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/home/oberman/utils/xemacs-21.0-b40/lwlib' cd ./src && make CC='cc' CFLAGS='-O2' LDFLAGS='' CPPFLAGS='' all make[1]: Entering directory `/home/oberman/utils/xemacs-21.0-b40/src' EMACSBOOTSTRAPLOADPATH="/usr/users/oberman/utils/xemacs-21.0-b40/src/../lisp/:/usr/users/oberman/utils/xemacs-21.0-b40" ./temacs -batch -l /usr/users/oberman/utils/xemacs-21.0-b40/src/../lisp/update-elc.el Loading /usr/users/oberman/utils/xemacs-21.0-b40/src/../lisp/update-elc.el... Loading find-paths.el... (17584) Loading packages.el... (28784) Loading setup-paths.el... (7112) Loading dump-paths.el... (0) At this point the load hangs in a CPU loop forever. I suspect that I need to do some setting up of packages, but I found the instructions in INSTALL fuzzy. This is my first build of beta-21.0 and, as a result, I have not downloaded any packages. The INSTALL at least implies that I should be able to build with only the lisp code included, but that may not be the case. I was going to try downloading some packages that I want to use, but I think any user trying to install 21.0 would quickly get confused by the installation experience I had. Of course, it may actually be a bug. R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman(a)es.net Phone: +1 510 486-8634

3 participants
4 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 1998