August 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: X-error in get_mouse_position 27 years

Pete Ware

Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes: > #else > XtDestroyWidget (w); > + XFlush (XtDisplay(w)); /* make sure the windows are really gone! */ > #endif /* EXTERNAL_WIDGET */ XtDestroyWidget() does not actually destroy the window. As I remember, it marks the widget (and all children) as in the process of being destroyed and puts it on a to-be-deleted list. When the application returns to the main loop and all pending events are handled, then the widget is actually deleted (phase 2). Destroying the actual window is one of the last things done in phase 2. --pete

1 participants
0 comments

Re: X-error in get_mouse_position 27 years

Gunnar Evermann

I hope this is The Right Patch now. For me this fixes the problem on Solaris and Linux. 1998-08-26 Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> * frame-x.c (x_delete_frame): Flush the X output buffer after calling XtDestroyWidget to ensure that the windows are really killed right now. --- frame-x.c~ Sat Jun 13 06:28:48 1998 +++ frame-x.c Wed Aug 26 13:16:49 1998 ＠＠ -2651,6 +2651,7 ＠＠ } #else XtDestroyWidget (w); + XFlush (XtDisplay(w)); /* make sure the windows are really gone! */ #endif /* EXTERNAL_WIDGET */ if (FRAME_X_GEOM_FREE_ME_PLEASE (f))

1 participants
0 comments

Re: Make custom-faces all order more sensible 27 years

Jan Vroonhof

Didier Verna <verna(a)inf.enst.fr> writes: > This sounds really arbitrary to me. I don't consider those faces more > important than others (like gnus ones) because I never customize them. On the > contrary, they are usually the ones I wanna see last. First of all: The really important face is 'default'. I want that that the top. Most people want to customize 'default'. It is the face where all other derive from. The others are really just their since normally sorting alphabetically almost sorts the faces by custom groups, now it does even more. However I do not care either way. The user CAN customize the list. It is a variable. It is just not offered as a customize variable by default since I consider it too advanced. Jan

1 participants
0 comments

Re: `elib_1.0.src.tar.gz' 27 years

Greg Klanderman

Cool, I'll take a look. It may be best to let me fold in the large patches I had applied to our previous pcl-cvs. It'll also give me the chance to properly document them. Greg Woods, who maintains pcl-cvs is interested in our getting mods for XEmacs back to him and folded into his distribution. greg >>>>> "Karl" == Karl M Hegbloom <karlheg(a)inetarena.com> writes: Karl> Karl> I've done that work. The version I uploaded before is ok, but wasn't Karl> built using the normal `srckit' target. I've made a new one that Karl> is, and put md5sum files next to it for good measure. Karl> Karl> I also have uploaded `pcl-cvs-2.0.2.src.tar.gz' to the same Karl> directory. I've rolled in a few of the patches I got through Karl> cvs.xemacs.org and the cvsweb there, but not all. There are a lot of Karl> changes to pcl-cvs. I've renamed the ChangeLog files. Our old one Karl> is now 0X.ChangeLog, and there are two from the upstream dist. I Karl> started a fresh one for from now on. Please see it for the mods I've Karl> made to the AUTHORVERSION. Karl> Karl> Some of the patches I didn't think are right anymore, given things Karl> that have been done with it. Yous will have to review it, of course. Karl> Let me know how I've done. Karl> Karl> http://www.inetarena.com/~karlheg/ELisp Karl> Karl> I like this version of pcl-cvs a lot better! Especially cool is Karl> `cvs-examine'.

1 participants
0 comments

Re: Company sued over comments in code 27 years

Lars Magne Ingebrigtsen

Hrvoje Niksic <hniksic(a)srce.hr> writes: > > But the XEmacs comment are pretty reasonable complaints about the > > current state of software. > > Not true. Much of the "offensive" comments and variables are pure > rants, including but not limited to > `run_the_gcc_developers_over_with_a_steamroller'. Still, they say > nothing about the quality of the code. `run_the_gcc_developers_over_with_a_steamroller' explains nicely why it exists and what its purpose is. If someone from the gcc camp were to sue, uh, someone from the XEmacs camp, it would be trivial to get a gazillion well-respected hackers to act as expert witnesses and say so. (And it's funny.) I just can't see what "fetch watermelon" is supposed to mean. It makes no sense to me. Let them fry. -- (domestic pets only, the antidote for overdose, milk.) larsi(a)ifi.uio.no * Lars Magne Ingebrigtsen

1 participants
0 comments

Re: `elib_1.0.src.tar.gz' 27 years

Greg Klanderman

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> sb> Greg Klanderman <greg(a)alphatech.com> writes in xemacs-beta(a)xemacs.org: >> Karl, >> Our pcl-cvs (XEmacs) package already contains the elib libraries that >> it needs, and it didn't look like pcl-cvs 2.0b2 needed any additional >> ones. sb> sb> Granted that making a separate elib package because pcl-cvs needs it sb> is not a sufficient reason to make it separate. But what about SKK sb> which also needs it? It makes more sense to have SKK require elib sb> than it does to require pcl-cvs, what does CVS have to do with sb> entering Japanese? :-) Of course this makes sense. Somehow I thought Karl intended to add all of elib to the pcl-cvs package, which upon re-reading his email is obviously not the case. >> Also note that the ones in your elib-1.0.tar.gz are identical >> to the ones we already have. So the elib stuff should be fine. sb> sb> Then it will be O.K. with you if we use Karl's package and remove the sb> copies of elib from pcl-cvs? certainly >>>>>>> "Karl" == Karl M Hegbloom <karlheg(a)inetarena.com> writes: Karl> Karl> I've taken the Debian GNU/Linux packaged version of `elib', and Karl> imported it into my personal cvs repository of the XEmacs package Karl> sources. I did this because the newest `pcl-cvs' requires it.

1 participants
0 comments

Re: Make custom-faces all order more sensible 27 years

Didier Verna

Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: > +(defvar custom-special-faces > + "Faces to show first in a customize-faces buffer in this order" > + (mapcar 'symbol-name > + '(default bold italic bold-italic underline highlight > + zmacs-region primary-selection > + secondary-selection text-cursor left-margin right-margin > + blue green red yellow))) > + This sounds really arbitrary to me. I don't consider those faces more important than others (like gnus ones) because I never customize them. On the contrary, they are usually the ones I wanna see last. If you really want to sort the faces in the buffer, let the user provide his own selection. Give him a customizable variable that can be a list of faces, a function returning a list of faces etc etc. --didier

1 participants
0 comments

Re: Macros: Scheme vs Common Lisp 27 years

Holger Schauer

>>>>"MS" == Michael Sperber schrieb am 26 Aug 1998 14:20:32 +0200: MS> (setq bar 23) (defmacro foo () bar) ; this means (foo) expands to MS> the value of BAR Holger> Isn't this meant to mean to refer to the current binding of Holger> bar, which in this case happens to be 23 ? MS> What do you mean by "current"? BAR is supposed to refer to the MS> binding introduced by (setq bar 23), which is the lexically MS> enclosing one. The question is: when is the binding resolved? MS> (defun baz () (foo)) MS> This is the crux of the matter: Does the binding get resolved MS> here? I tried to look it up (from the HyperSpec on defmacro): "Defines name as a macro by associating a macro function with that name in the global environment. The macro function is defined in the same lexical environment in which the defmacro form appears[1]. The parameter variables in lambda-list are bound to destructured portions of the macro call. The expansion function accepts two arguments, a form and an environment. The expansion function returns a form. The body of the expansion function is specified by forms. Forms are executed in order. The value of the last form executed is returned as the expansion of the macro. The body forms of the expansion function (but not the lambda-list) are implicitly enclosed in a block whose name is name." Footnotes(by me): [1] So, I would say, that whenever you "call" a macro, you essentially are calling the macro function which expands the form given to defmacro, where this is defined in the surrounding lexical environment. So, when you do (defmacro foo () bar) You are calling the macro function in the lexical environment established for foo. So, now I had to look up, what exactly "lexial environment" means, in order to see what effects changing bar afterwards may have: "lexical environment n. that part of the environment that contains bindings whose names have lexical scope. A lexical environment contains, among other things: ordinary bindings of variable names to values, lexically established bindings of function names to functions, macros, symbol macros, blocks, tags, and local declarations (see declare). lexical scope n. scope that is limited to a spatial or textual region within the establishing form. ``The names of parameters to a function normally are lexically scoped.''" So, it all breaks down to what is the "textual region within the establishing form" in this case ? It is the top-level form: "If a defmacro form appears as a top level form, the compiler must store the macro definition at compile time, so that occurrences of the macro later on in the file can be expanded correctly. Users must ensure that the body of the macro can be evaluated at compile time if it is referenced within the file being compiled." So, let's compile it ... USER(10): (compile-file "lisp/defmacro-test") ;;; Compiling file lisp/defmacro-test.lisp ; Compiling FOO ; While compiling (:TOP-LEVEL-FORM "defmacro-test.lisp" 139): Warning: Free reference to undeclared variable GEE assumed special. ; While compiling (:TOP-LEVEL-FORM "defmacro-test.lisp" 153): Warning: Free reference to undeclared variable GEE assumed special. ; Compiling FUN Warning: Free reference to undeclared variable GEE assumed special. ; Compiling BAZ ; While compiling (:TOP-LEVEL-FORM "defmacro-test.lisp" 297): Warning: Free reference to undeclared variable GEE assumed special. ;;; Writing fasl file lisp/defmacro-test.fasl Warning: No IN-PACKAGE form seen in lisp/defmacro-test.lisp. (Allegro Presto will be ineffective when loading a file having no IN-PACKAGE form.) ;;; Fasl write complete #p"lisp/defmacro-test.fasl" T And now, see the difference between interpreted and compiled version: USER(12): (load "lisp/defmacro-test.lisp") ; Loading lisp/defmacro-test.lisp gee => 23 (fun) => 23 (baz) => 23 (setq gee 42) (fun) => 42 (baz) => 42 T USER(13): USER(13): (load "lisp/defmacro-test") ; Fast loading lisp/defmacro-test.fasl gee => 23 (fun) => 42 (baz) => 42 (setq gee 42) (fun) => 42 (baz) => 42 T So, to sum things up: yes, what I supposed was a rather hackish solution, which can not be guarenteed to work across CL implementations nor across interpretation/compilation times. One last note: have a look at the following quote from CLtL2: "The defmacro construct arranges to install this expander function, as the global macro definition of name. The expander function is effectively defined in the global environment; lexically scoped entities established outside the defmacro form that would ordinarily be lexically apparent are not visible within the body of the expansion function. X3J13 voted in March 1989 (DEFINING-MACROS-NON-TOP-LEVEL) to clarify that, while defining forms normally appear at top level, it is meaningful to place them in non-top-level contexts. Furthermore, defmacro should define the expander function within the enclosing lexical environment, not within the global environment." Holger -- --- http://www.coling.uni-freiburg.de/~schauer --- ">grep schauer passwd >schauer:x:1075:1075:Holger Schauer, 2790:/home/schauer:/usr/bin/xemacs" "That's just a shell. LILO booting /vmunix.el would be really strange." -- Kristian and Holger in de.comp.os.linux.misc

1 participants
0 comments

External widget may need to be compiled with -DXTHREADS 27 years

Glynn Clements

I thought that I'd have a look at the external widget feature. After a fair amount of debugging core dumps, I figured that you need to use -DXTHREADS if it was used for compiling libXt. It would be useful if someone who understands autoconf better than I do could figure out how to get the value of ProjectThreadsDefines from xmkmf and stick it in the compilation command for src/extw-Xt.c. -- Glynn Clements <glynn(a)sensei.co.uk>

1 participants
0 comments

Re: Company sued over comments in code 27 years

Lars Magne Ingebrigtsen

Pete Ware <ware(a)cis.ohio-state.edu> writes: > But the XEmacs comment are pretty reasonable complaints about the > current state of software. Pick something you'd find offensive (joys > of anal sex, pedophilia, brilliance (or stupidity) of Clinton (or > Reagan), NEA, ...) and imagine variable names that bring that to mind > and comments about it spread throughout the code. Now would you > like to work on that code? Juvenile is a good label for it and > probably reflects the overall quality. Yup. Integrated Systech not only sound like boors; they sound like incompetent boors. Let them fry. I hope Willa Jackson gets oodles and oodles of moolah. One offensively incompetent computer company down; three million more to go. -- (domestic pets only, the antidote for overdose, milk.) larsi(a)ifi.uio.no * Lars Magne Ingebrigtsen

1 participants
0 comments

2025

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