September 1998 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Updated 21.x XEmacs lisp packages 26 years, 2 months

SL Baur

Pekka Marjola <pema(a)iki.fi> writes in xemacs-beta(a)xemacs.org: >>>>>> In <m27lzevq0s.fsf(a)altair.xemacs.org>, >>>>>> On 08 Sep 1998 03:48:35 -0700, >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> (irchat sb> (standards-version 1.0 sb> version "1.00" sb> description "ZENIRC IRC Client." > Hmm? Cut & paste rears its ugly head ...

1 participants
0 comments

Re: OpenWindows autoconf broken 26 years, 2 months

SL Baur

[Earth to Martin's ISP, are you unfucked yet?] Gunnar Evermann <Gunnar.Evermann(a)nats.informatik.uni-hamburg.de> writes in xemacs-beta(a)xemacs.org: ... > - it checks for /usr/X11 (because apparently autoconf doesn't find > this on Linux, HP because of a broken install by the vendor) and > sets x_... if it finds it. This is wrong, at least in the case of Linux. I am having great difficulty finding access to a properly configured HP machine which perhaps speaks for itself. > - run the AC macro. This macro doesn't bother doing anything if > x_... is set, most importantly it does *not* run xmkmf. Unfortunately, xmkmf is delivered broken on many systems. > As Jan pointed out the (relatively) portable way of finding X is to > use xmkmf, which would have worked perfectly in my case, but is never > done because of the preemptive Linux/HP fix. > I guess running xmkmf should be The Right Thing in your situation as > well. You probably have $OPENWINHOME set but presumably have your > X11R6.3 xmkmf in your PATH. Playing devil's advocate, the test has got to be more comprehensive than that. *I* have $OPENWINHOME set in my Linux environment, but there is nothing in $OPENWINHOME/lib that XEmacs needs to link to. On the gripping hand, it would be potentially less destructive adding that directory than something like /usr/local. It's also somewhat dubious to poke too deeply into the builder's environment on a multiuser system/network. > BTW: Didier you always make me feel stupid for running the Sun supplied > stuff, but in many cases I really don't see the need (e.g. cc, > Openwin3.6, ...) and our sysadmins are capable of fskcing up even the > most simple installation of 'free' replacements :-) There are many good reasons for wishing to link against the vendor-supplied libraries. > And I think *you* would be surprised by the number of people who run > *only* the vendor supplied version of everything. :-) I wouldn't be.

2 participants
1 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Christoph Wedler

>>>>>"JV" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: JV> Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: >> That's exactly what font-lock is supposed to do: attaching faces to >> characters matched by specific (parts of) font-lock keywords. JV> Look at what the font-lock does in the end: it ataches faces to JV> regions of the buffer. That sounds like extents to me. JV> That may be implemented now as "regions of chars with certain JV> properties". JV> (Note that the 'add-non-duplicable-text-properties' in questions is JV> called on regions!) Should that mean, whenever regions come into the game, extents are more appropriate? Text props don't have any chance then... ;-) JV> $ a = \alpha + \int d f $ JV> [ -- math face --- ] JV> [ sy ] [sy] I admit it would be nice to have a font-lock like package that handles syntactical structures in this way (we could also set highlight extents and maps and so on...), but the point is: font-lock does not work this way. JV> I am a bit worried about being able to support the 'append keywords JV> efficiently. Exactly, the same for 'prepend. BTW, you get also problems for OVERRIDE = nil, t or keep. Conclusion: using ("real") extents would be nice, but would change font-lock fundamentally. - Christoph

1 participants
0 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Jan Vroonhof

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: > > Should that mean, whenever regions come into the game, extents are more > appropriate? Text props don't have any chance then... ;-) It just that the "yeah but font-lock looks at individual chars" argument looks less powerfull in that contact. > Conclusion: using ("real") extents would be nice, but would change > font-lock fundamentally. And my point is that it possibly better to work on improving font-lock then then work on improving text-prorties as I have the feeling that the latter is just misusing the former since that is is the only thing FSF Emacs has. Especially since it is not yet proven that pure text properties can be made that much faster and that font-lock.el needs work anyway. Our text-propeties interface works well enough for emulation purposes. The big question is: can font-lock.el be improved wihtout changing the interface to programs too much. Jan

1 participants
0 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Christoph Wedler

>>>>>"SJT" == Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes: >>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)srce.hr> writes: Hrvoje> Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: >>> Why is font-lock using text-properties anyway? Isn't what it >>> does much more naturally mapped on extents. Hrvoje> Not really (although it may look that way at the start). Hrvoje> The font-lock code wants to apply certain properties to Hrvoje> parts of the buffer, merging or breaking the extents as Hrvoje> needed. This is exactly what the text-properties are for. SJT> Could you be more specific? The documentation says something quite SJT> different: text-properties are for attaching properties to characters SJT> rather than intervals. That's exactly what font-lock is supposed to do: attaching faces to characters matched by specific (parts of) font-lock keywords. SJT> That seems like exactly the _wrong_ thing to do with strings and SJT> comments, both of which should be locked up in an unbreakable SJT> (from the point of view of font-lock) extent once identified; There are not such things like unbreakable extents in font-lock: parts of previously fontified characters can get additional/new face properties, etc. In fact, two extents are "glumped" if appropriate, e.g., for a TeX sequence like \alpha\beta. SJT> the individual characters in them should never be considered SJT> "locally". ??? SJT> OTOH, I don't see why splitting an extent or merging neighboring SJT> extents (which should be constant time, with relatively high overhead SJT> I suppose) should be more efficient than iterating over a (possibly SJT> lengthy) interval of characters (linear time but possibly lower SJT> overhead, depending on the implementation, although I find it hard to SJT> see why it would be necessarily much less than for extents). This probably depends: the display is faster, the fontification not. - Christoph

2 participants
1 comments

Re: Need internal help please (dynamic loading support) 26 years, 2 months

Jan Vroonhof

"J. Kean Johnston" <jkj(a)sco.com> writes: > along, and works as well with 21 as it was with 20.4. I dont know how close > 201 is to release, but this is an area I know a great deal about (the > technology, not getting it to play nicely with XEmacs). That is is very nice. 21.0 is very close to release, which why new features like this are on the backburner. There already is a 21.2 development branch in the cvs. Checkout www.666.com/xemacs. There dll loading is in the blue sky category, but I for one would be glad if you could make it a reality. > I would like to > make this work, and believe I can with a little internals help. It would > make things go much faster if I could ask questions and get them answered > rather than wading through large doucments. The "internals" manual is not that large and moreover you do not need to read all of it to understand how the lisp linking works. Believe me it saves time. Of course I and others would be more than happy answer questions, it just that the our main expert on things like this (ben(a)xemacs.org) cannot currently type so it less of a strain on him if you read what he wrote in the past first. > Does anyone really care about this or am I the sole torch barer? We[1] care, in fact I would like it a lot if the grahics routines could be loaded on demand. There is just so much other things to do, like getting 21.0 out of the door. One 21.2 is in full fledge things like this will catch on again. Also some of the changes people have in mind for the future could render other things useless. > in dll.c, while its on the right track, is missing lots of things. I thought the ldap stuff made real use of the dll code already. I also think Barry Warsaw has some other work that is not integrated in the 21.x tree. > I already > have them so lets try and save duplication of effort. Here's what I have got: > [list of cool features deleted] How multiplatform is your work (I am thinking unix but note that with XEmacs 21.x there is also w32)? I remember one of the reasons dll loading was kept on te backburner for now was to wait untill things like libtool have stabalised. Finally, don't let all this disencourage you. The dll stuff in 21.0 is marked "subject to change" especially for somebody like you to come in and say "Damn't I know how to do this properly". Jan P.S. And just to warn you: There is another reason the dll stuff in 21.0 won't be advertised. The legal issues involved with dynamic linking. [1] Note I am not an official XEmacs team spokesperson, it just the feeling I get from reading xemacs-beta.

1 participants
0 comments

Need internal help please (dynamic loading support) 26 years, 2 months

Kean Johnston

Hello all. Over the weekend I had what I thought was a bright idea. While Elisp is ummm ... fine and dandy, I figured it would be nice if it were possible to extend XEmacs using dynamically loaded objects. For those applications that are very CPU intensive, it would make more sense (and make for much greater speed) if they were written in C and then loaded into emacs. A faster HTML parser would be a good example. So I styarted hacking about in the source and I now have rudimentary support for this. I have added the commands for loading in .sos and I am doing almost everything right. However, there are some problems. I would like to enlist the help of an XEmacs internals guru to get me over these hurdles, if you think this would be a worthwhile exercise. I already have things set up such that compiling modules is trivial (and will work the same way on all platforms that support dlopen()). Here is what I dont know how to do, or do properly: a) Getting DOC strings for variables defined correctly. When the .so is loaded in, a special function is called which does the moral equivalent of DEFSUBR() or DEFVAR_LISP() et al. I can see the variables defined but I dont know how to go about making the doc string visible. b) When i DEFSUBR() a function that was declared in the .so, and try to execute it, I get a SIGSEGV in Fcommanp when it calls SUBRP(fun). There is deep dark stuff I dont understand too well and would like to. Such as: 1) What is staticpro? 2) When do I need to GCPRO and when not? Whats the difference between GCPRO and NGCPRO? 3) Since this is all dynamic, after Emacs has dumped, how do I avoid purespace? Do I need to? Can I use xmalloc() for internal data? 4) If there is an existing Lisp or even intern function, can I replace its definition with a new one? How? Same thing for variables. Any help at all would be GREATLY appreciated. If it would help to talk by phone rather than email, let me know and I can either call or give you a 1-800 number for you to call me at. If you can help out, I would appreciate it if you could respond privately, as I dont read the whole list very often. I will summarise my findings. Thanks in advance, -- J. Kean Johnston | "Truth and beauty, beauty and truth. This is all we know, Engineer, SPG | and all we need ever know." -- John Keats, Endymion Santa Cruz, CA +---------------------------------------------------------- Tel: 408-427-7569 Fax: 408-429-1887 E-mail: jkj(a)sco.com

3 participants
3 comments

Re: OpenWindows autoconf broken 26 years, 2 months

Gunnar Evermann

Didier Verna <verna(a)inf.enst.fr> writes: > Wrong. Our configure script does more than just configuring > defaults. Martin made a big deal trying to guess as good as possible what the > user wants, not only what the system's default is. For instance, I think you > would be surprised by the number of people not using the basic installation of > X11 provided by Sun, but having some /usr/X11R6/... path installed. So you > have two phylosophies: either you say "This is a Sun, we use Openwin", or you > say "this is a Sun, but the guy has installed /usr/X11R6, and this overrides > the default". I prefer the second approach. I know that configure does more that finding the System's defaults. I really think that Martin did a wonderful job implementing this. But in this case it just works wrong. What happens in configure is the following: - it sees that I have not supplied any -with-x-..=... options and that $OPENWINHOME is set but points to the SUN default of /usr/openwin. Therefore it doesn't bother setting the $x_... vars. (probably reasoning that autoconf will later on find this path anyway). - it checks for /usr/X11 (because apparently autoconf doesn't find this on Linux, HP because of a broken install by the vendor) and sets x_... if it finds it. - run the AC macro. This macro doesn't bother doing anything if x_... is set, most importantly it does *not* run xmkmf. As Jan pointed out the (relatively) portable way of finding X is to use xmkmf, which would have worked perfectly in my case, but is never done because of the preemptive Linux/HP fix. I guess running xmkmf should be The Right Thing in your situation as well. You probably have $OPENWINHOME set but presumably have your X11R6.3 xmkmf in your PATH. BTW: Didier you always make me feel stupid for running the Sun supplied stuff, but in many cases I really don't see the need (e.g. cc, Openwin3.6, ...) and our sysadmins are capable of fskcing up even the most simple installation of 'free' replacements :-) And I think *you* would be surprised by the number of people who run *only* the vendor supplied version of everything. :-) Gunnar -- Gunnar Evermann Natural Language Systems Group, University of Hamburg EMail: Gunnar.Evermann(a)nats.informatik.uni-hamburg.de

1 participants
0 comments

Re: Text properties slow down XEmacs 26 years, 2 months

Jan Vroonhof

Christoph Wedler <wedler(a)fmi.uni-passau.de> writes: > That's exactly what font-lock is supposed to do: attaching faces to > characters matched by specific (parts of) font-lock keywords. Look at what the font-lock does in the end: it ataches faces to regions of the buffer. That sounds like extents to me. That may be implemented now as "regions of chars with certain properties". (Note that the 'add-non-duplicable-text-properties' in questions is called on regions!) > properties, etc. In fact, two extents are "glumped" if appropriate, > e.g., for a TeX sequence like \alpha\beta. That is just an implementation detail. It could very well just be that each of the two codes keeps its own extent. Note at the typical font lock example "A lisp format %s with %s escapes" Now the syntactical view of this is a string with escape chars. This is very clearly expressed with extents "A lisp format %s with %s escapes" [------string-face---------------] [] [] Where [] = is "[scape char face]", or a TeX example $ a = \alpha + \int d f $ [ -- math face --- ] [ sy ] [sy] The XEmacs redisplay code can handle such layering quite well. It is also cheap to insert (it is removing and maybe editing that is difficult). The text-properties view of this is $ a = \alpha + \int d f $ MMMMMMSSSSSSMMMMSSSSMMMMMM which XEmacs implements as $ a = \alpha + \int d f $ [ M ][ S ][ M][ S][ M ] the famous non-overlapping extents. My point is that this non-overlapping stuff is making the code inefficient 1. Finding all extents overlapping a certian region is inefficient outside of redisplay in the current implementation. 2. It is doing unneeded double work. The redisplay code already transforms stacked extents in non-overlapping extent fragments. It can do so much more efficiently since it can work linearly through the extents. I am a bit worried about being able to support the 'append keywords efficiently. Neither c-mode nor elisp-mode has them but font-latex has a whole lot. However it you look at the call-counts you see that it is almost never used on the real files. Jan P.S. If I am not mistaken font-lock is origionally a lucid Emacs thing and predates tex-properties. How did it work back then?

1 participants
0 comments

Re: Updated 21.x XEmacs lisp packages 26 years, 2 months

Pekka Marjola

>>>>> In <m27lzevq0s.fsf(a)altair.xemacs.org>, >>>>> On 08 Sep 1998 03:48:35 -0700, >>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> (irchat sb> (standards-version 1.0 sb> version "1.00" sb> description "ZENIRC IRC Client." Hmm? -- Pekka Marjola * pema(a)iki.fi * http://www.iki.fi/pema/ * PGPid 0x2865206D

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