April 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: select-window focus problem [was: Re: minor compile.el bug] 26 years

Hrvoje Niksic

greg(a)alphatech.com (Greg Klanderman) writes: > Hrvoje> What the docstring says -- change the frame. If this is not > Hrvoje> the case, then we should add something like "this commands > Hrvoje> doesn't do anything with focus-follows-mouse set to t." But > Hrvoje> I wouldn't do that before giving it *good* thought. > > Hmm, I've never used that because I would never think of having focus > thrown to a frame other than the one the mouse is over. > > What'd it do prior to my patch? I assume it threw emacs focus, but > not the window manager focus. Checking.... yup. I assume that's not > what you want? Or is it? It's not what I want. I want `C-x 5 o' to behave the same regardless of focus-follows-mouse. The reason for this is that `C-x 5 o' is an interactive command. If I press 3 keystrokes for something to happen, I expect it to happen, not to be silently ignored. > Hrvoje> BTW, are you aware that FSF 20.3 sets focus-follows-mouse to t by > Hrvoje> default? Maybe we should copy what they do? > > Copy the default value, or behavior of C-x 5 o? The former, and maybe the latter. I'm not sure what `C-x 5 o' does under FSF with focus-follows-mouse set to t, but I'm fairly certain it is not ignored. -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- You have an unusual magnetic personality. Don't walk too close to metal objects which are not fastened down.

1 participants
0 comments

Re: [CRASH] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 26 years

John Mignault

>>>>> "Jareth" == P E Jareth Hein <jhod(a)gol.com> writes: Jareth> Nope, this is a free-bug gotcha, and was just dealt with Jareth> in my patch <ohvhrurxjn.fsf(a)pentagana.camelot.jp> [patch] Jareth> Fix for image related memory corruption. Apply and lemme Jareth> know if that fixes your problem. I've applied the patch and so far it works fine over a tty via telnet, but I won't be able to test it with X until I get home later today. Will followup then. J -- #!/usr/bin/perl $dot="\x2e";$lt="\x3c";$gt="\x3e";$at="\x40"; print "J Mignault ${lt}mignault${at}nytimes${dot}com${gt}\n";

1 participants
0 comments

Re: [CRASH] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 26 years

P. E. Jareth Hein

John Mignault <jbm(a)panix.com> writes: > Got this from an apparently idling XEmacs. Backtrace is below, followed > by Installation report. I note the sig 11. Hmm. Maybe it's time for > new memory. > Nope, this is a free-bug gotcha, and was just dealt with in my patch <ohvhrurxjn.fsf(a)pentagana.camelot.jp> [patch] Fix for image related memory corruption. Apply and lemme know if that fixes your problem. > Core was generated by `xemacs'. > Program terminated with signal 11, Segmentation fault. > find_solib: Can't read pathname for load map: Input/output error > > #0 0x40245131 in ?? () from /lib/libc.so.6 > (gdb) where > #0 0x40245131 in ?? () from /lib/libc.so.6 > #1 0x8094451 in fatal_error_signal (sig=11) at emacs.c:260 > #2 0xbfffe624 in ?? () > #3 0x80780b7 in xfree (block=0xbffd8400) at alloc.c:433 > #4 0x81202fc in x_finalize_image_instance (p=0x8995980) at glyphs-x.c:388 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ HA! Here's the culprit! -- Jareth Hein

1 participants
0 comments

Re: select-window focus problem [was: Re: minor compile.el bug] 26 years

Pete Ware

Make sure you read the X stuff on input focus! It is perfectly reasonable for the user to be using focus-follows-mouse window manager policy but for an application to shift the focus to another of its windows (aka ^X-5-o should work). Then think about what the emacs variable focus-follows-mouse is supposed to do. My window manager policy is focus follows mouse (I hate click to focus) and I have focus-follows-mouse set to nil -- it all works the way it is supposed to. I remember much discussion about this a year or two ago. --pete

1 participants
0 comments

cvs in xemacs question 26 years

Andy Piper

When I edit XEmacs source files in Xemacs they are shown read-only - presumably because the repository is read-only. How do I switch this off? (Note C-c C-q is not what I want) andy

1 participants
0 comments

Re: select-window focus problem [was: Re: minor compile.el bug] 26 years

Greg Klanderman

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Hrvoje> SL Baur <steve(a)xemacs.org> writes: >> Hrvoje Niksic <hniksic(a)srce.hr> writes: >> >> > Wow, this patch fixes a problem I had with toolbar-news. Cool. >> > However, after applying this, `C-x 5 o' becomes a no-op. Is that >> > supposed to happen (I have `focus-follows-mouse' set to t)? If yes, >> > it looks a bit too harsh... >> >> What is it supposed to do? Hrvoje> Hrvoje> What the docstring says -- change the frame. If this is not the case, Hrvoje> then we should add something like "this commands doesn't do anything Hrvoje> with focus-follows-mouse set to t." But I wouldn't do that before Hrvoje> giving it *good* thought. Hmm, I've never used that because I would never think of having focus thrown to a frame other than the one the mouse is over. What'd it do prior to my patch? I assume it threw emacs focus, but not the window manager focus. Checking.... yup. I assume that's not what you want? Or is it? The right thing with f-f-m true seems for C-x 5 o to physically move the mouse pointer, a la ediff. Hrvoje> BTW, are you aware that FSF 20.3 sets focus-follows-mouse to t by Hrvoje> default? Maybe we should copy what they do? Copy the default value, or behavior of C-x 5 o? What do they do for C-x 5 o? greg

1 participants
0 comments

[CRASH] 21.0 "Pygmy" XEmacs Lucid (beta37) on i586-pc-linux 26 years

John Mignault

Got this from an apparently idling XEmacs. Backtrace is below, followed by Installation report. I note the sig 11. Hmm. Maybe it's time for new memory. J [jbm＠jbm new]$ gdb /usr/local/bin/xemacs core 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 (i386-redhat-linux), Copyright 1996 Free Software Foundation, Inc... Core was generated by `xemacs'. Program terminated with signal 11, Segmentation fault. find_solib: Can't read pathname for load map: Input/output error #0 0x40245131 in ?? () from /lib/libc.so.6 (gdb) where #0 0x40245131 in ?? () from /lib/libc.so.6 #1 0x8094451 in fatal_error_signal (sig=11) at emacs.c:260 #2 0xbfffe624 in ?? () #3 0x80780b7 in xfree (block=0xbffd8400) at alloc.c:433 #4 0x81202fc in x_finalize_image_instance (p=0x8995980) at glyphs-x.c:388 #5 0x80d2c1b in finalize_image_instance (header=0x8995980, for_disksave=0) at glyphs.c:672 #6 0x807a6f6 in sweep_lcrecords_1 (prev=0x8231b94, used=0xbfffe734) at alloc.c:3561 #7 0x807b4e8 in gc_sweep () at alloc.c:4236 #8 0x807b98d in garbage_collect_1 () at alloc.c:4557 #9 0x807bb1d in Fgarbage_collect () at alloc.c:4662 #10 0x80999c6 in funcall_recording_as (recorded_as=136734620, nargs=0, args=0xbfffebd8) at eval.c:3197 #11 0x8099b69 in Ffuncall (nargs=1, args=0xbfffebd8) at eval.c:3238 #12 0x8081676 in Fbyte_code (bytestr=136323108, vector=136323296, maxdepth=11) at bytecode.c:416 #13 0x809a3ee in funcall_lambda (fun=136323480, nargs=0, arg_vector=0xbfffedb8) at eval.c:3597 #14 0x8099b2d in funcall_recording_as (recorded_as=137583896, nargs=0, args=0xbfffedb4) at eval.c:3214 #15 0x8099b69 in Ffuncall (nargs=1, args=0xbfffedb4) at eval.c:3238 #16 0x8081676 in Fbyte_code (bytestr=136319780, vector=136319860, maxdepth=9) at bytecode.c:416 #17 0x8099511 in Feval (form=136319756) at eval.c:3063 #18 0x8097ab3 in condition_case_1 (handlers=136319984, bfun=0x8098ecc <Feval>, barg=136319756, hfun=0x8097b00 <run_condition_case_handlers>, harg=137579332) at eval.c:1653 #19 0x8097c0b in condition_case_3 (bodyform=136319756, var=137579332, handlers=136319984) at eval.c:1715 #20 0x8081a43 in Fbyte_code (bytestr=136319152, vector=136319428, maxdepth=17) at bytecode.c:576 #21 0x809a3ee in funcall_lambda (fun=136320388, nargs=1, arg_vector=0xbffff634) at eval.c:3597 #22 0x8099b2d in funcall_recording_as (recorded_as=137579136, nargs=1, args=0xbffff630) at eval.c:3214 #23 0x8099b69 in Ffuncall (nargs=2, args=0xbffff630) at eval.c:3238 #24 0x8081676 in Fbyte_code (bytestr=136322540, vector=136322608, maxdepth=11) at bytecode.c:416 #25 0x809a3ee in funcall_lambda (fun=136322692, nargs=1, arg_vector=0xbffff748) at eval.c:3597 #26 0x8099b2d in funcall_recording_as (recorded_as=137579584, nargs=1, args=0xbffff744) at eval.c:3214 #27 0x8099b69 in Ffuncall (nargs=2, args=0xbffff744) at eval.c:3238 #28 0x809a86f in call1 (fn=137579584, arg0=136733220) at eval.c:3912 #29 0x80b43e8 in execute_internal_event (event=140329044) at event-stream.c:2974 #30 0x80b5d66 in Fdispatch_event (event=140329044) at event-stream.c:4636 #31 0x8086a1a in Fcommand_loop_1 () at cmdloop.c:574 #32 0x80868ae in command_loop_1 (dummy=136733220) at cmdloop.c:494 #33 0x8097ab3 in condition_case_1 (handlers=136733332, bfun=0x8086898 <command_loop_1>, barg=136733220, hfun=0x8086458 <cmd_error>, harg=136733220) at eval.c:1653 #34 0x808652c in command_loop_3 () at cmdloop.c:256 #35 0x8086548 in command_loop_2 (dummy=136733220) at cmdloop.c:267 #36 0x80977fc in internal_catch (tag=136807620, func=0x8086540 <command_loop_2>, arg=136733220, threw=0x0) at eval.c:1328 #37 0x8086686 in initial_command_loop (load_me=136733220) at cmdloop.c:305 #38 0x8095190 in sort_args (argc=1, argv=0xbffffa48) at emacs.c:1672 #39 0x809583d in main (argc=1, argv=0xbffffa48, envp=0xbffffa50) at emacs.c:2089 > XEmacs Build Report as generated > by build-report-version 1.35 follows: > Contents of /usr/local/src/xemacs-20.5-b33/Installation: > (Output from most recent run of ./configure) uname -a: Linux jbm.dialup.access.net 2.0.31 #1 Sun Nov 9 21:45:23 EST 1997 i586 unknown ./configure '--dynamic' '--with-database=gnudbm' '--with-xpm' '--gung-ho' '--error-checking=none' XEmacs 21.0-b37 "Pygmy" configured for `i586-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-20.5-b33 What installation prefix should install use? /usr/local What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? gcc -g -O2 -Wall -Wno-switch Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) 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/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for X-Face message headers. Compiling in support for GIF image conversion. Compiling in support for JPEG image conversion. Compiling in support for PNG image conversion. Compiling in support for TIFF image conversion. Compiling in native sound support. Compiling in support for GNU DBM. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for OffiX. Compiling in support for proper session-management. Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Compiling in DLL support. movemail will use "dot-locking" for locking mail spool files. Using Lisp_Objects with minimal tagbits. Using indexed lrecord implementation. Compiling in extra code for debugging. Compiling in code for checking XEmacs memory usage. > /usr/local/src/xemacs-20.5-b33/beta.err does not exist! -- #!/usr/bin/perl $dot="\x2e";$lt="\x3c";$gt="\x3e";$at="\x40"; print "J Mignault ${lt}mignault${at}nytimes${dot}com${gt}\n";

2 participants
1 comments

Lstreams, coding and md5 (was: Re: [PATCH] menubar selection in mswindows) 26 years

P. E. Jareth Hein

Hrvoje Niksic <hniksic(a)srce.hr> writes: > Lstreams rule. Look at my latest and greatest md5.c implementation to > see how simple it is to set up a decoding lstream for that purpose. > > In fact, the only thing that I *don't* like with the coding system > stuff are the CODING-SYSTEM arguments scattered all over the place. > For instance, is the CODING-SYSTEM argument to Fmd5 *really* > necessary? I wonder... I put that in there for use with email systems or digital sigs. Visualize having a buffer in SJIS, (which usually is translated to ISO-2022-JP for mailing) and wanting to put a digest on it. I figured that feature would come in handy... I am perfectly willing to be shouted down, however... -- Jareth Hein | jareth(a)camelot-soft.com | ハインジェラス Toolsmith & Program lead | http://www.camelot-soft.com | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."

1 participants
0 comments

[patch] Fix for image related memory corruption 26 years

P. E. Jareth Hein

Okay, I jumped the gun a bit with my last patch. Apply this one instead and things should work fine. 1998-04-28 P. E. Jareth Hein <jareth(a)camelot-soft.com> * glyphs-x.c : slight cleanup and bugfix related to memory corruption and possible leaks. Also fix a visual problem with XPM pointers Index: glyphs-x.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/src/glyphs-x.c,v retrieving revision 1.44 diff -u -r1.44 glyphs-x.c --- glyphs-x.c 1998/04/28 00:24:58 1.44 +++ glyphs-x.c 1998/04/28 19:24:46 ＠＠ -152,7 +152,7 ＠＠ static XImage * convert_EImage_to_XImage (Lisp_Object device, int width, int height, unsigned char *pic, unsigned long **pixtbl, - int *pixcount, int *npixels) + int *npixels) { Display *dpy; Colormap cmap; ＠＠ -201,10 +201,10 ＠＠ if (vis->class == PseudoColor) { unsigned long pixarray[256]; - int n; + int pixcount, n; /* use our quantize table to allocate the colors */ - *pixcount = 32; - *pixtbl = xnew_array (unsigned long, *pixcount); + pixcount = 32; + *pixtbl = xnew_array (unsigned long, pixcount); *npixels = 0; /* ### should implement a sort by popularity to assure proper allocation */ ＠＠ -221,7 +221,7 ＠＠ res = allocate_nearest_color (dpy, cmap, vis, &color); if (res > 0 && res < 3) { - DO_REALLOC(*pixtbl, *pixcount, n+1, unsigned long); + DO_REALLOC(*pixtbl, pixcount, n+1, unsigned long); (*pixtbl)[n] = color.pixel; n++; } ＠＠ -825,16 +825,18 ＠＠ { Lisp_Object device = IMAGE_INSTANCE_DEVICE (ii); Colormap cmap = DEVICE_X_COLORMAP (XDEVICE(device)); - unsigned long *pixtbl; - int pixcount; - int npixels; + unsigned long *pixtbl = NULL; + int npixels = 0; XImage* ximage; ximage = convert_EImage_to_XImage (device, width, height, eimage, - &pixtbl, &pixcount, &npixels); + &pixtbl, &npixels); if (!ximage) - signal_image_error("EImage to XImage conversion failed", instantiator); - + { + if (pixtbl) xfree (pixtbl); + signal_image_error("EImage to XImage conversion failed", instantiator); + } + /* Now create the pixmap and set up the image instance */ init_image_instance_from_x_image (ii, ximage, dest_mask, cmap, pixtbl, npixels, ＠＠ -1523,6 +1525,7 ＠＠ Screen *xs; Colormap cmap; int depth; + Visual *visual; Pixmap pixmap; Pixmap mask = 0; XpmAttributes xpmattrs; ＠＠ -1554,22 +1557,23 ＠＠ #if 1 /* Although I haven't found it documented yet, it appears that pointers are - always colored via the default window colormap... Sigh. However, with - the current color structure, this will blow the doors off as things aren't set up - to differenciate between two colormaps per console. AARGH! */ + always colored via the default window colormap... Sigh. */ if (type == IMAGE_POINTER) { cmap = DefaultColormap(dpy, DefaultScreen(dpy)); depth = DefaultDepthOfScreen (xs); + visual = DefaultVisualOfScreen (xs); } else { cmap = DEVICE_X_COLORMAP (XDEVICE(device)); depth = DEVICE_X_DEPTH (XDEVICE(device)); + visual = DEVICE_X_VISUAL (XDEVICE(device)); } #else cmap = DEVICE_X_COLORMAP (XDEVICE(device)); depth = DEVICE_X_DEPTH (XDEVICE(device)); + visual = DEVICE_X_VISUAL (XDEVICE(device)); #endif x_initialize_pixmap_image_instance (ii, type); ＠＠ -1596,7 +1600,7 ＠＠ xpmattrs.valuemask |= XpmCloseness; xpmattrs.depth = depth; xpmattrs.valuemask |= XpmDepth; - xpmattrs.visual = DEVICE_X_VISUAL (XDEVICE(device)); + xpmattrs.visual = visual; xpmattrs.valuemask |= XpmVisual; xpmattrs.colormap = cmap; xpmattrs.valuemask |= XpmColormap; -- Jareth Hein | jareth(a)camelot-soft.com | ハインジェラス Toolsmith & Program lead | http://www.camelot-soft.com | 開発部チーフ Camelot Software, Ltd. | |（株）キャメロット "Contrary to popular belief, penguins are not the salvation of modern technology. Neither do they throw parties for the urban proletariat."

2 participants
1 comments

[PATCH] compilation buffer lossage 26 years

Hrvoje Niksic

A lot of my compilation buffers (M-x compile or M-x grep) mysteriously die with "exit status 255". I found this very strange, and I tracked it down to a change in compile-internal recently made by Kirill. Another syndrom of the change is that compilation buffers begin like this: cd /home/srce/hniksic/work/emacs/xemacs-packages/lisp/xemacs-base/ egrep -n 'wget:' *.c /dev/null ^Dzsh: no matches found: *.c Notice the `^D' (two characters) and the ^H^H sequence of two control-h characters. It doesn't happen all the time, but it's very annoying. This patch fixes it, but I don't know enough about this code to judge if this is an XEmacs bug, or Kirill somehow missed a Unix process support subtlety. --- compile.el.orig Tue Apr 28 11:38:50 1998 +++ compile.el Tue Apr 28 11:39:11 1998 ＠＠ -660,7 +660,8 ＠＠ command))) (set-process-sentinel proc 'compilation-sentinel) (set-process-filter proc 'compilation-filter) - (process-send-eof proc) + ;; Causes problems; please investigate before using: + ;(process-send-eof proc) (set-marker (process-mark proc) (point) outbuf) (setq compilation-in-progress (cons proc compilation-in-progress))) -- Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia --------------------------------+-------------------------------- A radioactive cat has eighteen half-lives.

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 April 1998