July 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > There aren't supposed to be any autoloads in the core lisp area, however, it > is appropriate to have a custom-load.el. I'm completely lost. The core lisp soure is full of autoload cookies and there IS an auto-autoloads file in this directory. You can even retrieve it via cvs. Are we talking about the same things ?! -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: 21.2.17 changed menubar font from 21.2.15 24 years, 10 months

Jan Vroonhof

Matt Simmons <simmonmt(a)acm.org> writes: > What happened? What can I do to return it to the earlier font? Probably something got mixed up in Andy's Widget work. First thing to do would be to check config.h (maybe compare with the result from b15) to see whether you are indeed still using Lucid menus. Jan

2 participants
1 comments

Re: [PB] Makefile 24 years, 10 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > SL Baur <steve(a)xemacs.org> writes: >> The core lisp part of the build process has never rebuilt >> auto-autoloads.el (or custom-load.el) as a routine part of the >> build. > Are you sure? Positive. Someone, Karl Hegbloom, I think, posted a patch a couple years ago that went part-way, but it never made its way into the sources. There aren't supposed to be any autoloads in the core lisp area, however, it is appropriate to have a custom-load.el. To be done right, it would need to work without an existing auto-autoloads.el file, and that's fairly tricky to do since we would only have temacs at the point where it would need to be generated. It's not impossible, of course, it's just a lot of tedious work. autoload.el would probably have to be rewritten using more primitive functions, for example. -- 金がものを言う (Money talks)

1 participants
0 comments

Re: [PB] Makefile 24 years, 10 months

Didier Verna

SL Baur <steve(a)xemacs.org> writes: > Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > > > For some reason, it seems that touching a .el in the core lisp > > directory and typing `make' doesn't rebuild the autoloads anymore. > > ???? > > You mean it does not rebuild auto-autoloads.elc? The core lisp > part of the build process has never rebuilt auto-autoloads.el (or > custom-load.el) as a routine part of the build. Are you sure? I remember having only to type `gmake' after modifying a core lisp file. So what's the target? Hmm, I'm really surprised. What if you change the doc string of an autoloaded function ? Even removing the DOC didn't lead to an autoloads rebuild. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: [PB] Makefile 24 years, 10 months

SL Baur

Didier Verna <verna(a)inf.enst.fr> writes in xemacs-beta(a)xemacs.org: > For some reason, it seems that touching a .el in the core lisp > directory and typing `make' doesn't rebuild the autoloads anymore. ???? You mean it does not rebuild auto-autoloads.elc? The core lisp part of the build process has never rebuilt auto-autoloads.el (or custom-load.el) as a routine part of the build. -- 善は急げ (strike while the iron is hot)

1 participants
0 comments

Re: [RFC] the rectangle functions 24 years, 10 months

Didier Verna

wmperry(a)aventail.com (William M. Perry) writes: > Didier Verna <verna(a)inf.enst.fr> writes: > > > wmperry(a)aventail.com (William M. Perry) writes: > > > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for > > > it. :) > > > > So this is probably going to be a good test case ... > > Oh yea verily. It might actually help matters. Tables with colored cells > can lead to some weird stuff under both emacsen right now. OK. I'd like people to test this. Interface changes are the following: * apply-on-rectangle: new function. operate-on-rectangle is not used anymore, but since it is documented, I didn't touch it in case external code use it. * The following functions now have an optional prefix letting them intrusively insert spaces the old way: kill-rectangle, delete-rectangle, delete-extract-rectangle, open-rectangle, clear-rectangle. I'm aware that using the prefix that way, the default behavior changes. However, I'd like to see if it breaks something or not because for interactive use, which is I think the most important case, things are more logical in this sense. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

[PB] Makefile 24 years, 10 months

Didier Verna

For some reason, it seems that touching a .el in the core lisp directory and typing `make' doesn't rebuild the autoloads anymore. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: [RFC] the rectangle functions 24 years, 10 months

Didier Verna

wmperry(a)aventail.com (William M. Perry) writes: > Didier Verna <verna(a)inf.enst.fr> writes: > > > wmperry(a)aventail.com (William M. Perry) writes: > > > > > As long as it doesn't screw up Emacs/W3's table rendering, I'd say go for > > > it. :) > > > > So this is probably going to be a good test case ... > > Oh yea verily. It might actually help matters. Tables with colored cells > can lead to some weird stuff under both emacsen right now. Actually, I'm also beginning to think that move-to-column shouldn't use tabs at all when filling lines. Only spaces. The reason is that nothing prevents you from killing a rectangle in one buffer and yanking it at a different column, or in another buffer with different tab widths. There, you're screwed up. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / ENST, INFRES C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. +33 (1) 45 81 73 46 75013 Paris, France Fax. +33 (1) 45 81 31 19

1 participants
0 comments

Re: Recent configure.in bugs fix 24 years, 10 months

Michael Sperber

>>>>> "Vin" == Vin Shelton <acs(a)xemacs.org> writes: >>>>> On Wed, 23 Jun 1999, Olivier Galibert <galibert(a)pobox.com> said: OG> Since we're not using autoheader, any #define-type option added to OG> configure.in MUST be added to src/config.h.in or it will be ignored. OG> OG. OG> PS: I apply that one immediatly. OG> 1999-06-23 Olivier Galibert <galibert(a)pobox.com> OG> * config.h.in: Add missing #undef *_USER_DEFINED. OG> Index: src/config.h.in OG> =================================================================== OG> RCS file: /usr/CVSroot/XEmacs/xemacs/src/config.h.in,v OG> retrieving revision 1.49.2.9 OG> diff -u -r1.49.2.9 config.h.in OG> --- config.h.in 1999/06/18 11:48:55 1.49.2.9 OG> +++ config.h.in 1999/06/23 22:01:06 OG> ＠＠ -798,6 +798,11 ＠＠ OG> #define MAIL_USE_LOCKF OG> #endif OG> +#undef PREFIX_USER_DEFINED OG> +#undef EXEC_PREFIX_USER_DEFINED OG> +#undef MODULEDIR_USER_DEFINED OG> +#undef SITEMODULEDIR_USER_DEFINED OG> +#undef DOCDIR_USER_DEFINED OG> #undef LISPDIR_USER_DEFINED OG> #undef PACKAGE_PATH_USER_DEFINED OG> #undef SITELISPDIR_USER_DEFINED Vin> Do any of these (specifically DOCDIR) need to be applied for 21.1? Vin> I've applied (but not committed) Michael's docdir patch for 21.1.4. Yes. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: 21.2.17 changed menubar font from 21.2.15 24 years, 10 months

SL Baur

Matt Simmons <simmonmt(a)acm.org> writes in xemacs-beta(a)xemacs.org: ... > What happened? What can I do to return it to the earlier font? I don't know what has happened to you, however, it has never worked as simply as you described. I set the menubar font with the X resource: XEmacs*fontSet: -*-helvetica-bold-r-*--12-*-*-*-*-*-*-*,-*-fixed-medium-r-normal--14-* -- 言わぬが花 (Two heads are better than one)

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 July 1999