February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Buffer tabs still flickering PLUS gutter example code 24 years, 10 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > diff -u -r1.7.2.10 font-lock.el > --- lisp/font-lock.el 2000/02/19 11:52:58 1.7.2.10 > +++ lisp/font-lock.el 2000/02/26 21:18:28 Did you want to include this...? In particular > -;; Author: Jamie Zawinski <jwz(a)jwz.org>, for the LISPM Preservation Society. > +;; Author: Jamie Zawinski <jwz(a)netscape.com>, for the LISPM Preservation Society. and > +;; <andy(a)xemacs.org> 12-10-99. This still does not work right, I think > +;; after change functions will still get us. The simplest thing to do > +;; is unconditionally turn-off font-lock before revert (and thus nuke > +;; all hooks) and then turn it on again afterwards. This also happens > +;; to be much faster because fontifying from scratch is better than > +;; trying to do incremental changes for the whole buffer. > + > +(defalias 'font-lock-revert-cleanup 'turn-on-font-lock) > +(defalias 'font-lock-revert-setup 'turn-off-font-lock) Some comments (from a casual glance) about your specifier stuff. I agree that the specifier stuff can be hard. (I had to debug frob-face-property!) > +;;; Gutter helper functions > + > +(defun set-gutter-element (gutter-specifier prop val &optional locale tag-set) I don't think this is quite correct: > + "Set GUTTER-SPECIFIER gutter element PROP to VAL in optional LOCALE. > +This is a convenience function for setting gutter elements." > + (let ((spec-list (specifier-spec-list gutter-specifier locale tag-set))) > + (if spec-list > + (add-spec-list-to-specifier > + gutter-specifier > + (mapcar #'(lambda (spec) > + (setcdr (car (cdr spec)) > + (plist-put (cdr (car (cdr spec))) > + prop val)) Note that for each locale there is a LIST of cons pairs. > + spec) spec-list) > + 'remove-all) You don't want to use 'remove-all, that would remove the spec-list from other locales too. Just use nil, which will do the right thing. > + (set-specifier gutter-specifier (list prop val) locale tag-set)))) I don't think this a good idea. You probably want to inherit the other properties from the lower locales. You should call plist-put on the (specifier-instance gutter-specifier locale tag-set) if locale is a domain. You seem to be doing a partial reinvention on frob-face-property. Two points. 1. frob-face-property is ugly because the font specifier of a face is combination of many properties (family, weight etc..). We now recognize that we might have been better off if these properties were independent specifiers. You should be maybe stop here and consider whether you want to take this road. (If understand correctly the number of elements in a gutter isn't fixed so this would be not so easy.) 2. All your helper functions seem to be instances of the same structure. Why not add a generalized version like this to specifier.el: Untested but obvious[ahem]. (defun modify-specifier-instances (specifier func &optional args force default locale tag-set) "Modify all specifications that match LOCALE and TAG-SET by FUNC. For each specification that exists for SPECIFIER, in locale LOCALE that matches TAG-SET, call the function FUNC with the instance as its first argument and with optional arguments ARGS. The result is then used as the new value of the instantiator. If there is no specification in the domain LOCALE matching TAG-SET and FORCE is non-nil, an explicit one is created from the matching specifier instance if that exists or DEFAULT otherwise. If LOCALE is not a domain (i.e. a buffer), DEFAULT is always used. FUNC is then applied like above and the resulting specification is added." (let ((spec-list (specifier-spec-list specifier locale tag-set))) (cond (spec-list ;; Distructively edit the spec-list (mapc #'(lambda (spec) (mapc #'(lambda (inst-pair) (setcdr inst-pair (apply func (cdr inst-pair) args))) (cdr spec))) spec-list) (add-spec-list-to-specifier specifier)) (force (set-specifier specifier (apply func (or (and (valid-specifier-domain-p locale) (specifier-instance specifier)) default) args) locale tag-set))))) Then your function can be rewritten as ;;; Gutter helper functions (defun set-gutter-element (gutter-specifier prop val &optional locale tag-set) "Set GUTTER-SPECIFIER gutter element PROP to VAL in optional LOCALE. This is a convenience function for setting gutter elements." (modify-specifier-instances gutter-specifier #'plist-put (list prop val) 'force nil locale tag-set)) (defun remove-gutter-element (gutter-specifier prop &optional locale tag-set) "Remove gutter element PROP from GUTTER-SPECIFIER in optional LOCALE. This is a convenience function for removing gutter elements." (modify-specifier-instances gutter-specifier #'plist-remprop (list prop) 'force nil locale tag-set)) (defun set-gutter-element-visible-p (gutter-specifier prop &optional visible-p locale tag-set) "Make gutter element PROP VISIBLE-P for GUTTER-SPECIFIER in optional LOCALE. This is a convenience function for hiding and showing gutter elements." I don't quite understand what this function is doing. I hope this helps. I need some sleep. Jan

2 participants
1 comments

Why aren't zero length extents duplicable? 24 years, 10 months

Andy Piper

Zero length extents, attached to text with duplicable set do not get preserved by concat. Why is this? Is there any way of forcing extent duplication in concat, even if extents aren't marked as duplicable? This is from C. Thanks andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
2 comments

more gutter useability improvements 24 years, 10 months

Andy Piper

Thanks to Jan. This improves the useability changes somewhat. andy 2000-02-27 Andy Piper <andy(a)xemacs.org> * gutter-items.el (update-tab-hook): new function to be used for hooks. (create-frame-hook): add update-tab-hook. (record-buffer-hook): ditto. (default-gutter-position-changed): ditto. (default-gutter-position): updating the buffers tab is now handled by a hook. (default-gutter-position-changed-hook): new variable. (gutter-element-visibility-changed-hook): ditto. (set-gutter-element-visible-p): call it. (set-gutter-element): use modify-specifier-instances. Set extents as duplicable before using. (remove-gutter-element): ditto. (set-gutter-element-visible-p): ditto. (init-gutter): new function. (add-tab-to-gutter): use new gutter-element functions rather than setting specifiers directly. (clear-progress): ditto. (abort-progress): ditto. (gutter-buffers-tab-visible-p): renamed from default-gutter-visible-p * specifier.el (modify-specifier-instances): new function from Jan Vroonhof. * x-init.el (init-post-x-win): call init-gutter. * msw-init.el (init-post-mswindows-win): call init-gutter. * menubar-items.el (default-menubar): Update to reflect new gutter variables. * gutter.c (Fset_default_gutter_position): don't default left and right gutter visibility to t. (Fset_default_gutter_position): run default-gutter-position-changed-hook. (syms_of_gutter): add default-gutter-position-changed-hook. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

Re: glibc can call alarm() | wass Re: [CRASH] with socks 24 years, 10 months

Jan Vroonhof

Andreas Jaeger <aj(a)suse.de> writes: > The problem seems to be sysdeps/generic/utmp_file.c. We try to lock > the utmp file and save/restore the alarm values (we don't mess around > with the values - but if XEmacs overwrites alarm...). That's AFAIK > (besides sleep) the only place where glibc uses alarm. This is typical usage, i.e. old_timeout = alarm(0); push new SIGALARM handler alarm(our_time); /* do your thing */ alarm(0); pop SIGALARM handler alarm(old_timeout); The reason XEmacs overrides the alarm() functions is exactly to detect stuff like this because it is often wrong urysohn:/tmp> gcc testlarm.c [1] urysohn:/tmp> ./a.out value from alarm() was : 1 Restored to: 1.000000 s , should be 0.000500 s Repeat to: 0.000000 s , should be 0.000700 s So IMO this is a bug in glibc (should I file one?) 1. This really is a wart in the Unix API. The above code is only correct if our_time << old_timeout (because it doesn't check for the fact that the real timer could very well have expired. For that reason it would be really nice if glibc would refrain from messing with the timers, especially in stuff like get_login() where it is not obvious. 2. If it really wants to mess with the timer (Don't the posix realtime extensions now offer independent timers?), it should do so using getitimer/setitimer because that doesn't loose precision and repeat values. Jan Footnotes: [1] #include <stdio.h> #include <sys/time.h> #include <time.h> int main (int argc, char *argv[]) { struct itimerval mydelay = {{0, 700} , {0,500}}; /* 500 msec, repeat 700 */ struct itimerval newdelay; int inseconds; if (setitimer(ITIMER_REAL,&mydelay,NULL)) { perror("setimer: "); exit(1); } inseconds = alarm(0); alarm(inseconds); getitimer(ITIMER_REAL,&newdelay); alarm(0); printf("value from alarm() was : %i\n",inseconds); printf("Restored to: %li.%6.6li s , should be %li.%6.6li s\n", newdelay.it_value.tv_sec, newdelay.it_value.tv_usec, mydelay.it_value.tv_sec, mydelay.it_value.tv_usec); printf("Repeat to: %li.%6.6li s , should be %li.%6.6li s\n", newdelay.it_interval.tv_sec, newdelay.it_interval.tv_usec, mydelay.it_interval.tv_sec, mydelay.it_interval.tv_usec); } -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

1 participants
0 comments

fake mail? 24 years, 10 months

Ben Wing

When I try to use XEmacs to send mail under MS Windows, it complains about not being able to find the 'fakemail' package. I'm sure I remember hearing about this ... Andy, you even said something about it. Does anyone know where this has gone? -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

2 participants
1 comments

Re: glibc can call alarm() | wass Re: [CRASH] with socks 24 years, 10 months

Andreas Jaeger

>>>>> Jan Vroonhof writes: Jan> Didier Verna <didier(a)xemacs.org> writes: >> didier(p2)% runsocks ./src/xemacs 14:08 02/26/00 >> Fatal error: assertion failed, file /usr/local/src/XEmacs-21.2/src/signal.c, line 340, async_timer_suppress_count > 0 >> zsh: segmentation fault (core dumped) runsocks ./src/xemacs Jan> This is going to get ugly. XEmacs cannot handle library code Jan> playing with timers. Any such code must be wrapped in Jan> stop/start_async_timeouts (void) which unfortunately is also only available Jan> as part of stop/start_interrupts. Jan> A similar problem occurs with modern libesd.so's.. I have a patch for Jan> that. However it seems that your socks library calls the fairly Jan> innocent getlogin and that uses a timeout in glibc(). Apparently on Jan> Linux the timers are fair game for libraries. In addition most of them Jan> seem to be using alarm which has much lower resolution than the itimer Jan> stuff. Jan> We need a better solution for this. Andreas any ideas..? Not directly. For now I just checked what we're doing in glibc. >> #10 0x8094ee4 in assert_failed ( >> file=0x8299500 "/usr/local/src/XEmacs-21.2/src/signal.c", line=340, >> expr=0x82994e0 "async_timer_suppress_count > 0") >> at /usr/local/src/XEmacs-21.2/src/emacs.c:2770 >> #11 0x81bde9d in alarm (howlong=0) >> at /usr/local/src/XEmacs-21.2/src/signal.c:340 >> #12 0x4055045d in getutline_r () from /lib/libc.so.6 >> #14 0x40509b5d in getlogin () from /lib/libc.so.6 >> #15 0x400183c1 in lsEffUser () from /usr/local/lib/libsocks5_sh.so >> #18 0x4002262f in connect () from /usr/local/lib/libsocks5_sh.so >> #26 0x4051664b in getaddrinfo () from /lib/libc.so.6 >> #27 0x81d386d in init_system_name () >> at /usr/local/src/XEmacs-21.2/src/sysdep.c:2361 The problem seems to be sysdeps/generic/utmp_file.c. We try to lock the utmp file and save/restore the alarm values (we don't mess around with the values - but if XEmacs overwrites alarm...). That's AFAIK (besides sleep) the only place where glibc uses alarm. Jan> That means that with socks every call to the networking stuff can call Jan> alarm(). Some more general solution must be found. Jan> Jan Jan> P.S. In the mean time play around with your nsswitch.conf to disable Jan> to the setting that is triggering the alarm call. I don't think that this is might help here. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.rhein-neckar.de

1 participants
0 comments

XEmacs 21.1 (patch 9) executables for NetBSD/sparc 24 years, 10 months

XEmacs Webmaster

Precompiled XEmacs binary-kits based on the XEmacs 21.1.9 release have been prepared for NetBSD/sparc. You can find the binary-kits and associated installation instructions at the following location: <URL:ftp://ftp.xemacs.org/pub/xemacs/binary-kits/netbsd/> For better response, we recommend downloading from one of our archive mirrors in your corner of the world. The most up-to-date list of mirror sites can be found at: <URL:http://www.xemacs.org/Download/> Enjoy.

1 participants
0 comments

glibc can call alarm() | wass Re: [CRASH] with socks 24 years, 10 months

Jan Vroonhof

Didier Verna <didier(a)xemacs.org> writes: > didier(p2)% runsocks ./src/xemacs 14:08 02/26/00 > Fatal error: assertion failed, file /usr/local/src/XEmacs-21.2/src/signal.c, line 340, async_timer_suppress_count > 0 > zsh: segmentation fault (core dumped) runsocks ./src/xemacs This is going to get ugly. XEmacs cannot handle library code playing with timers. Any such code must be wrapped in stop/start_async_timeouts (void) which unfortunately is also only available as part of stop/start_interrupts. A similar problem occurs with modern libesd.so's.. I have a patch for that. However it seems that your socks library calls the fairly innocent getlogin and that uses a timeout in glibc(). Apparently on Linux the timers are fair game for libraries. In addition most of them seem to be using alarm which has much lower resolution than the itimer stuff. We need a better solution for this. Andreas any ideas..? > #10 0x8094ee4 in assert_failed ( > file=0x8299500 "/usr/local/src/XEmacs-21.2/src/signal.c", line=340, > expr=0x82994e0 "async_timer_suppress_count > 0") > at /usr/local/src/XEmacs-21.2/src/emacs.c:2770 > #11 0x81bde9d in alarm (howlong=0) > at /usr/local/src/XEmacs-21.2/src/signal.c:340 > #12 0x4055045d in getutline_r () from /lib/libc.so.6 > #14 0x40509b5d in getlogin () from /lib/libc.so.6 > #15 0x400183c1 in lsEffUser () from /usr/local/lib/libsocks5_sh.so > #18 0x4002262f in connect () from /usr/local/lib/libsocks5_sh.so > #26 0x4051664b in getaddrinfo () from /lib/libc.so.6 > #27 0x81d386d in init_system_name () > at /usr/local/src/XEmacs-21.2/src/sysdep.c:2361 That means that with socks every call to the networking stuff can call alarm(). Some more general solution must be found. Jan P.S. In the mean time play around with your nsswitch.conf to disable to the setting that is triggering the alarm call.

1 participants
0 comments

Re: Weird redisplay crash 24 years, 10 months

Jan Vroonhof

npak(a)kazbek.ispras.ru (Nick V. Pakoulin) writes: > I've applied Andy's patch fixing windows geometry and the crash no longer > happens. We have 2 years of bugs in the bug tracking archives to prove you wrong :-). It just harder to reproduce without Andy's helpful ispell breakage. Jan

1 participants
0 comments

Re: Fix window geometry 24 years, 10 months

Markus Alt

I have no problem to be a crast test dummy - as long as it helps making gutter / buffer tabs more stable! As you should have noticed already, I really like to use them a lot ... (BTW: 21.2.31 looks great to me so far with respect to buffer tabs!) Will try Jan's redisplay patch and see if this cures the problem. Markus Andy Piper <andy(a)xemacs.org> on 02/25/2000 06:24:39 PM Please respond to Andy Piper <andy(a)xemacs.org> To: Markus Alt/Germany/IBM＠IBMDE, xemacs-beta(a)xemacs.org cc: Subject: Re: Fix window geometry At 02:48 PM 2/25/00 +0100, altmark(a)de.ibm.com wrote: > > >What about the ediff control buffer? If you set ediff-window-setup-function >to ediff-setup-windows-multiframe, i.e. use a separate frame for the ediff >control panel, and have gutter visible, XEmacs crashes when the mouse >pointer enters the ediff control buffer (I reported this some time ago: >http://www.xemacs.org/list-archives/xemacs-beta/199911/msg00101.html). > >Does this fix also cover this issue? Or is it a completely different story? No idea, but it looks like you are our crash test dummy... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

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 February 2000