March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Michael Harnois

Configure fails with the above installed. I've established that changing the definition of _XOPEN_SOURCE from 500 to 1 works around the problem. Better minds than I will have to figure out why. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA mdharnois(a)home.com aa0bt(a)aa0bt.ampr.org Some folks you don't have to satirize, you just quote 'em. --Tom Paxton

2 participants
1 comments

M-up and M-down changed? 24 years, 8 months

Hrvoje Niksic

I've noticed that M-up and M-down no longer move by paragraphs, but by sentences instead. OTOH, C-M-up and C-M-down now move by paragraphs. Ben, is that your change? What's the motive behind it? I don't claim that the new behaviour is either better or worse than the old one, but I'm definitely used to the old bindings, so the change comes as a bit unnerving to my XEmacs-trained fingers.

3 participants
2 comments

Re: modules anyone? 24 years, 8 months

William M. Perry

Olivier Galibert <galibert(a)pobox.com> writes: > > I leave the choice to Olivier. > > I'd rather not put it back and leave the rest in the broken state it > was in. Whoever wants to define new types in modules, tell me the > kind of interface you'd like to have and I'll implement it (and ensure > that the dumper deals with it). Remember that we somehow need the > DEFINE/DECLARE/INIT trilogy. You can't do versions as functions very easily since they do a bunch of preprocessor magic. Steve's postgres stuff is definitely going to need this functionality. As would most of the modules I want to work on. :) -Bill P.

2 participants
1 comments

Re: modules anyone? 24 years, 8 months

Hrvoje Niksic

SL Baur <steve(a)beopen.com> writes: > We must be able to define new lcrecord types in modules. The > specific interface doesn't much matter to me, but the functionality > must be there. Both Martin and Olivier agree on that. I'd like to add one more requirement: the API for declaring new types should be the same in modules as in normal XEmacs code. J. Kean Johnston invested much effort in making DEFUN work unchanged in modules (including but not limited to docstring processing), thus allowing normal XEmacs code to be converted to modules without much fuss. We should follow in the same track.

1 participants
0 comments

Re: read-file-name loading cl-macs 24 years, 8 months

Hrvoje Niksic

Jeff Miller <jmiller(a)smart.net> writes: > Hrvoje> One thing that can trigger loading cl-macs in run-time is > Hrvoje> running uncompiled (and thus un-macroexpanded) Lisp. > > but this got me looking more. Turns out the auto-autoload.el was > not byte-compiled. Once I byte-compiled it, no more cl-macs.el > loading Cool. We could have a "stamp out cl-macs loading" week here. :-)

1 participants
0 comments

Re: Progress gauges slowing things down 24 years, 8 months

Hrvoje Niksic

Andy Piper <andy(a)xemacs.org> writes: > At 04:12 PM 3/16/00 +0100, Hrvoje Niksic wrote: > >For some reason, progress gauge takes a very long time to come up and > >disappear. It seems as if there was a (sleep-for 1) hidden in the > >code. > > Its probably the disappearance - there is a sit-for 0.5 in there. > Maybe this should be remove altogether? Yes please.

1 participants
0 comments

Re: 24 years, 8 months

William M. Perry

Andy Piper <andy(a)xemacs.org> writes: > At 03:40 AM 3/16/00 -0800, Kyle Jones wrote: > >Where are we as far as nailing things down for a 21.2 release? > >Stabilizing your widget stuff was one of the pre-release > >objectives. What else? > > Stick a fork in me. > > The progress gauge stuff was the cusp of what I was trying to achieve. > There are bound to be some changes as people potentially try and start to > use this stuff (like user defined layout algorithms) but I'm happy with > what we have at the moment. There are some minor bugs and crashes that I > will work my way through as I have time. > > I think the issue now is making sure 21.2 is totally solid from a > mswindows point-of-view. This has to include finishing up Kirill's > printing support since that gets asked every other day. I think Ben has > fixed a lot of the outstanding UI issues. There is a process issue that I > was hoping Kirill was going to get around to. I also think the packages > via HTTP needs to be fixed, I though Bill nearly had something going for > this. You can use the new URL package for this if you don't want to roll your own. But right now it would break w3-4.0.36, but the new stuff requires the latest gnus 5.8.x. Urk. -Bill P.

2 participants
1 comments

Re: modules anyone? 24 years, 8 months

SL Baur

William M Perry <wmperry(a)aventail.com> writes in xemacs-beta(a)xemacs.org: > Olivier Galibert <galibert(a)pobox.com> writes: >> > I leave the choice to Olivier. >> >> I'd rather not put it back and leave the rest in the broken state it >> was in. Whoever wants to define new types in modules, tell me the >> kind of interface you'd like to have and I'll implement it (and ensure >> that the dumper deals with it). Remember that we somehow need the >> DEFINE/DECLARE/INIT trilogy. > You can't do versions as functions very easily since they do a bunch of > preprocessor magic. Steve's postgres stuff is definitely going to need > this functionality. As would most of the modules I want to work on. :) We must be able to define new lcrecord types in modules. The specific interface doesn't much matter to me, but the functionality must be there.

1 participants
0 comments

Re: modules anyone? 24 years, 8 months

Jan Vroonhof

wmperry(a)aventail.com (William M. Perry) writes: > I've got the ldap and gpm code in the latest CVS snapshot usable. Do we > want to make this a default for 21.2? Are there any other pieces that > should be moved into modules as a proof-of-concept? Steve's postgress code I guess. > For LDAP and GPM it was basically cp ../modules/xxx and a makefile tweek. > Other than that it worked out of the box. Does that also include an option where they still get linked into the core? Would it be possible to leave the source files in src (is also more convenient for grep'ping?) > Someone mentioned a while ago that the portable dumper screwed up > modules... not quite sure I see why. In theory you shouldn't be dumping > out any of those objects, but... More importantly is that Martin made the number of lrecord types a compile time constant. Of course that does not matter for modules that are basically lazy loaded parts of the core. Jan

3 participants
3 comments

Re: read-file-name loading cl-macs 24 years, 8 months

Hrvoje Niksic

Jeff Miller <jmiller(a)smart.net> writes: > the offending lisp seems to be in file called quickurl.el that i > have in there. it was the only package that pulled cl-macs in when > loaded. I think, but am not sure, that it is the usage of "defun*" > in quickurl that make cl-macs get loaded. But now that I now the > (debug) trick maybe i can find out for sure. Is the "quickurl" thing compiled? One thing that can trigger loading cl-macs in run-time is running uncompiled (and thus un-macroexpanded) Lisp.

2 participants
1 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 March 2000