cedet-semantic Mailing List for CEDET (Page 150)
Brought to you by:
zappo
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(6) |
Oct
(5) |
Nov
(2) |
Dec
(44) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(15) |
Feb
(15) |
Mar
(6) |
Apr
|
May
(1) |
Jun
(14) |
Jul
(7) |
Aug
(5) |
Sep
(11) |
Oct
|
Nov
(11) |
Dec
(18) |
2003 |
Jan
(36) |
Feb
(21) |
Mar
(36) |
Apr
(17) |
May
(48) |
Jun
(8) |
Jul
(6) |
Aug
(10) |
Sep
(14) |
Oct
(12) |
Nov
(43) |
Dec
(61) |
2004 |
Jan
(40) |
Feb
(69) |
Mar
(44) |
Apr
(57) |
May
(48) |
Jun
(36) |
Jul
(45) |
Aug
(29) |
Sep
(11) |
Oct
(28) |
Nov
(19) |
Dec
(23) |
2005 |
Jan
(55) |
Feb
(37) |
Mar
(24) |
Apr
(17) |
May
(10) |
Jun
|
Jul
(19) |
Aug
(7) |
Sep
(19) |
Oct
(21) |
Nov
(13) |
Dec
(12) |
2006 |
Jan
(21) |
Feb
(15) |
Mar
(51) |
Apr
(5) |
May
(6) |
Jun
(25) |
Jul
(11) |
Aug
(13) |
Sep
(16) |
Oct
(16) |
Nov
(1) |
Dec
(1) |
2007 |
Jan
|
Feb
|
Mar
(10) |
Apr
(6) |
May
(28) |
Jun
(37) |
Jul
(19) |
Aug
(21) |
Sep
(25) |
Oct
(8) |
Nov
(4) |
Dec
(9) |
2008 |
Jan
(9) |
Feb
(40) |
Mar
(49) |
Apr
(28) |
May
(83) |
Jun
(17) |
Jul
(20) |
Aug
(12) |
Sep
(22) |
Oct
(29) |
Nov
(41) |
Dec
(67) |
2009 |
Jan
(12) |
Feb
(46) |
Mar
(67) |
Apr
(12) |
May
(25) |
Jun
(61) |
Jul
(44) |
Aug
(43) |
Sep
(35) |
Oct
(22) |
Nov
(27) |
Dec
(21) |
2010 |
Jan
(26) |
Feb
(24) |
Mar
(30) |
Apr
(23) |
May
(55) |
Jun
(21) |
Jul
(12) |
Aug
(28) |
Sep
(60) |
Oct
(38) |
Nov
(16) |
Dec
(10) |
2011 |
Jan
(15) |
Feb
(23) |
Mar
(9) |
Apr
(9) |
May
|
Jun
(21) |
Jul
(32) |
Aug
(45) |
Sep
(38) |
Oct
(28) |
Nov
(14) |
Dec
(4) |
2012 |
Jan
(8) |
Feb
(22) |
Mar
(17) |
Apr
(13) |
May
(7) |
Jun
(21) |
Jul
(18) |
Aug
(7) |
Sep
(46) |
Oct
(94) |
Nov
(17) |
Dec
(12) |
2013 |
Jan
(33) |
Feb
(30) |
Mar
(62) |
Apr
(64) |
May
(15) |
Jun
(22) |
Jul
(22) |
Aug
(8) |
Sep
(7) |
Oct
(15) |
Nov
(17) |
Dec
(11) |
2014 |
Jan
(1) |
Feb
(5) |
Mar
(5) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(18) |
Oct
(24) |
Nov
(22) |
Dec
(23) |
2015 |
Jan
(11) |
Feb
(29) |
Mar
(7) |
Apr
(8) |
May
|
Jun
(1) |
Jul
(1) |
Aug
(24) |
Sep
(2) |
Oct
(19) |
Nov
(13) |
Dec
(8) |
2016 |
Jan
(2) |
Feb
(22) |
Mar
(12) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
|
Aug
(6) |
Sep
(14) |
Oct
(7) |
Nov
(1) |
Dec
|
2017 |
Jan
(9) |
Feb
(2) |
Mar
(1) |
Apr
(6) |
May
(12) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
2018 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
|
Oct
(3) |
Nov
(19) |
Dec
(4) |
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Eric M. L. <er...@si...> - 2002-03-02 01:12:58
|
The wife and the kids took a week long vacation without me, and I finally had time to integrate several months of patches and fix reported bugs! They are due back tomorrow so here are some releases: speedbar 0.14beta3 eieio 0.17beta4 semantic 1.4beta14 Here is the news for each: --------- Speedbar: More XEmacs support Configuration variable to control Emacs 21 tooltips. Support spaces in file and tag names. Fixes to help embed Speedbar in ECB. Bug fixes --------- EIEIO: Bug fixes Chart updates (works on terminals) Version verification function slot-boundp works on class allocated attributes You can now declare a class as abstract. More tests --------- Semantic: Documentation updates and enhancements. Application writers example files. New super-smart completion in semantic-ia.el (not hooked up to keybindings or menus yet) Improvements to C++ parser including better template support Improvements to Makefile parser Fixed texinfo parser Debugger improvements Lexical analyzer can pay attention to whitespace if desired. Support for abstract/static types in UML text output New external child adoption mechanism. Imenu/Speedbar support of adopted external children Multipe typing bins for toplevel/in class token streams ------ Enjoy Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org -------- See me & my catapults on The History Channel Saturday, March 16th @ 5pm EST |
From: Kimura F. <fu...@mj...> - 2002-02-21 03:48:00
|
At Wed, 20 Feb 2002 21:40:01 -0500, Eric M. Ludlam <er...@si...> wrote: > > >>> Kimura Fuyuki <fu...@mj...> seems to think that: > >At Tue, 19 Feb 2002 16:43:13 -0500, > >Eric M. Ludlam <er...@si...> wrote: > >> > >> I checked in changes to semantic.el, semantic-make.el, and make.bnf > >> to accommodate what I saw in your patch. It seems to be working for > >> me. Could you get the latest from CVS and try it out? Thanks. > > > >Repository seems to be still old... is it normal? > [ ... ] > > My mistake. You need to get the changes from the v1_4 branch. Aha! I found it. Works fine and much cleaner. Thanks! |
From: Eric M. L. <er...@si...> - 2002-02-21 02:40:23
|
>>> Kimura Fuyuki <fu...@mj...> seems to think that: >At Tue, 19 Feb 2002 16:43:13 -0500, >Eric M. Ludlam <er...@si...> wrote: >> >> I checked in changes to semantic.el, semantic-make.el, and make.bnf >> to accommodate what I saw in your patch. It seems to be working for >> me. Could you get the latest from CVS and try it out? Thanks. > >Repository seems to be still old... is it normal? [ ... ] My mistake. You need to get the changes from the v1_4 branch. Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Kimura F. <fu...@mj...> - 2002-02-21 01:41:16
|
At Tue, 19 Feb 2002 16:43:13 -0500, Eric M. Ludlam <er...@si...> wrote: > > I checked in changes to semantic.el, semantic-make.el, and make.bnf > to accommodate what I saw in your patch. It seems to be working for > me. Could you get the latest from CVS and try it out? Thanks. Repository seems to be still old... is it normal? |
From: Eric M. L. <er...@si...> - 2002-02-19 21:43:56
|
>>> Kimura Fuyuki <fu...@mj...> seems to think that: >At Sun, 17 Feb 2002 20:56:36 -0500, >Eric M. Ludlam <er...@si...> wrote: >> The patch itself seems fine, but I'm trying to understand what some >> of the changes are for. In particular, some of the whitespace stuff >> is throwing me off, though I certainly understand the need to >> differentiate whitespace. I suspect that to do what you want will >> require that the core lexer be able to provide whitespace. > >Sorry for complicated codings ;) > >Actually, sometimes we might need something like >semantic-flex-enable-whitespaces or better solution. I checked in changes to semantic.el, semantic-make.el, and make.bnf to accommodate what I saw in your patch. It seems to be working for me. Could you get the latest from CVS and try it out? Thanks. >> There is a program called `xml-parse' which parses XML files. I've >> been looking at it lately, and may write a filter to convert its >> output to something that is semantic friendly. > >Good news :) > >But currently we have (at least) two XML parsers for Emacs, xml.el and >xml-parse.el, though I don't know which one is better... (xml.el is >bundled with GNU Emacs 21) It has since occurred to me that using xml.el to parse, and converting won't be useful since semantic requires buffer positional information which isn't provided. :( Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Kimura F. <fu...@mj...> - 2002-02-18 05:09:37
|
At Sun, 17 Feb 2002 20:56:36 -0500, Eric M. Ludlam <er...@si...> wrote: > The patch itself seems fine, but I'm trying to understand what some > of the changes are for. In particular, some of the whitespace stuff > is throwing me off, though I certainly understand the need to > differentiate whitespace. I suspect that to do what you want will > require that the core lexer be able to provide whitespace. Sorry for complicated codings ;) Actually, sometimes we might need something like semantic-flex-enable-whitespaces or better solution. > There is a program called `xml-parse' which parses XML files. I've > been looking at it lately, and may write a filter to convert its > output to something that is semantic friendly. Good news :) But currently we have (at least) two XML parsers for Emacs, xml.el and xml-parse.el, though I don't know which one is better... (xml.el is bundled with GNU Emacs 21) |
From: Eric M. L. <er...@si...> - 2002-02-18 02:02:02
|
>>> Kimura Fuyuki <fu...@mj...> seems to think that: >Hi, > >I made some improvements in semantic-make for practice. It can now >handle rather complex makefile like the attached one. Remaining >possible TODOs are: > > - Support BSD-make's makefile > - Support Imakefile > - Move to wisent?? > >My next challenge would be semantic-awk or wisent-awk (not just a >torture!) or -xml or something. Anyone working on these? If there, >please tell me. I take another way. [ ... ] Hi, Thanks for the patch, and sorry about the delay. The patch itself seems fine, but I'm trying to understand what some of the changes are for. In particular, some of the whitespace stuff is throwing me off, though I certainly understand the need to differentiate whitespace. I suspect that to do what you want will require that the core lexer be able to provide whitespace. I'll let you know when I figure it out a bit better. I do not know of an awk parser, or anyone working on one. If awk wraps it's function bodies in some parenthetical form, either parser will work. If it does not, then wisent will be better. Wisent is better in general, though simple languages like the Makefile may be a little easier in the current parser (I can't verify that assumption yet). There is a program called `xml-parse' which parses XML files. I've been looking at it lately, and may write a filter to convert its output to something that is semantic friendly. Have fun Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Kimura F. <fu...@mj...> - 2002-02-15 11:17:50
|
At Fri, 15 Feb 2002 14:27:53 +0900, Kimura Fuyuki <fu...@mj...> wrote: > > I made some improvements in semantic-make for practice. Sorry, I sent a wrong version in previous mail. rule: targets opt-whitespace colons opt-whitespace elements #commands Remove # and C-c C-c, please. *sigh* |
From: Kimura F. <fu...@mj...> - 2002-02-15 05:28:05
|
Hi, I made some improvements in semantic-make for practice. It can now handle rather complex makefile like the attached one. Remaining possible TODOs are: - Support BSD-make's makefile - Support Imakefile - Move to wisent?? My next challenge would be semantic-awk or wisent-awk (not just a torture!) or -xml or something. Anyone working on these? If there, please tell me. I take another way. |
From: Kimura F. <fu...@mj...> - 2002-02-12 01:57:16
|
At Mon, 11 Feb 2002 08:06:16 -0500, Eric M. Ludlam <er...@si...> wrote: > > >>> Kimura Fuyuki <fu...@mj...> seems to think that: > >Hi bovine lovers, > > > >I've found an annoying bug in semantic-bnf-to-bovine. It adds an extra > >space to the parse-table definition every time when invoked. > > > >To fix, apply the following patch or perhaps it's better to call > >indent-region like for the keyword-table. > [ ... ] > > Thanks for the patch. That behavior annoyed me too, but I'd been too > lazy to fix it. I don't call indent-region on the bovine table > because of speed constraints. You can have it indented by using "C-c > c" instead of "C-c C-c." My thought is that no one would bother > really looking at it anyway, so why slow things down. Oh, I wasn't aware of C-c c. Thanks. But I use C-c C-c, because my hacking box is very poor. (K5-100!) |
From: Eric M. L. <er...@si...> - 2002-02-11 13:06:41
|
>>> Kimura Fuyuki <fu...@mj...> seems to think that: >Hi bovine lovers, > >I've found an annoying bug in semantic-bnf-to-bovine. It adds an extra >space to the parse-table definition every time when invoked. > >To fix, apply the following patch or perhaps it's better to call >indent-region like for the keyword-table. [ ... ] Thanks for the patch. That behavior annoyed me too, but I'd been too lazy to fix it. I don't call indent-region on the bovine table because of speed constraints. You can have it indented by using "C-c c" instead of "C-c C-c." My thought is that no one would bother really looking at it anyway, so why slow things down. Thanks again Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Kimura F. <fu...@mj...> - 2002-02-11 06:23:07
|
Hi bovine lovers, I've found an annoying bug in semantic-bnf-to-bovine. It adds an extra space to the parse-table definition every time when invoked. To fix, apply the following patch or perhaps it's better to call indent-region like for the keyword-table. Thanks, |
From: Eric M. L. <er...@si...> - 2002-02-07 16:24:08
|
>>> Thomas Woelfle <Tho...@io...> seems to think that: >Hi *, > >I'd like to write a emacs major-mode for an own little language. >How can I use semantic to parse a file and how to use it to >do syntax-highlighting of the file? [ ... ] Hi, The semantic info manual contains instructions for building a language definition file. There are also some examples, and a skeleton.bnf file. After you have created a parser several features are available, but syntax highlighting is not one of them. While that is a long term goal, there is no active plan for it. Depending on the complexity of you language, you may choose to instead use the experimental wisest parser which will be an important part of semantic 2.0. The current LL parser has limitations which prevent some languages from being parsed correctly, particularly if function or method bodies are not wrapped in some form of parenthetical characters. Good Luck Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Thomas W. <Tho...@io...> - 2002-02-07 15:18:04
|
Hi *, I'd like to write a emacs major-mode for an own little language. How can I use semantic to parse a file and how to use it to do syntax-highlighting of the file? thanks Thomas |
From: Vlad D. <vla...@ho...> - 2002-02-01 09:33:54
|
Thanks for the answer. Since then I saw that there is something like what I want in JDE. There it is solved by letting Java look into the file, but not all languages have that kind of introspection; that's why I was thinking that source code inspection should be a general solution. regards, Vlad _________________________________________________________________ Chatta med vänner online, prova MSN Messenger: http://messenger.msn.se |
From: Vlad D. <vla...@ho...> - 2002-02-01 09:31:57
|
Hi again, this time I have a more down-to-earth question. When I try to compile a .bnf file (any one) I only get a complaint that the setup function can't be found. But it's there... What is the problem? It feels like I tried everything... TIA, Vlad _________________________________________________________________ MSN Photos är det enklaste sättet att dela ut och skriva ut foton: http://photos.msn.se/Support/WorldWide.aspx |
From: Eric M. L. <er...@si...> - 2002-01-31 13:49:03
|
Hi, The senator functions for jump & completion use the tokens from the local buffer for several reasons. 1) That is what was available at the time 2) It is fast 3) Finding tokens from the database results in some confusion since the buffers are not necessarily in memory, and extra work needs to be done to overcome that. On the flip side, some work toward what you want has been done. For example: * Semanticdb search functions have built in knowledge of projects hierarchies. Extending this to include explicit libraries from the system would not be hard. * Semantic and semanticdb search routines can search include files based on include/import statements found in the source files. * The semantic-analyze package already searches and provides a comprehensive list of completions based on type information from semanticdb. The missing pieces are: * Semanticdb searching of OS level libraries * A batch script for building semantic.cache. * Use interface on semantic-analyze * A version of completing read for whole-database completion. Using the existing APIs for completion would result in far too much overhead. Eric >>> "Vlad Dumitrescu" <vla...@ho...> seems to think that: >Hi all, > >I have only recently discovered the Semantic package and freinds, and am= =20 >still in heaven :-) > >However, there is some functionality that either exists and I don't know= how=20 >to use it, or just waits to be implemented. Maybe you van guide me. > >As things work now, one only has token completion for tokens from the=20 >current buffer. What I'd like to do is create a semantic database with a= ll=20 >standard libraries for the current language, and be able to use it in to= ken=20 >completion, maybe even in senator-jump, besides the database for the cur= rent=20 >buffer. > >Is it something to hope for in the near future? If my Lisp skills were n= ot=20 >so rusty, I'd try myself to give a hand. I might anyways :-) so please a= sk. > >best regards, >Vlad > >_________________________________________________________________ >Chatta med v=E4nner online, prova MSN Messenger: http://messenger.msn.se > > >_______________________________________________ >cedet-semantic mailing list >ced...@li... >https://lists.sourceforge.net/lists/listinfo/cedet-semantic > > LocalWords: that --=20 Eric Ludlam: za...@gn..., eric@siege-engine.c= om Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Vlad D. <vla...@ho...> - 2002-01-31 12:55:31
|
Hi all, I have only recently discovered the Semantic package and freinds, and am still in heaven :-) However, there is some functionality that either exists and I don't know how to use it, or just waits to be implemented. Maybe you van guide me. As things work now, one only has token completion for tokens from the current buffer. What I'd like to do is create a semantic database with all standard libraries for the current language, and be able to use it in token completion, maybe even in senator-jump, besides the database for the current buffer. Is it something to hope for in the near future? If my Lisp skills were not so rusty, I'd try myself to give a hand. I might anyways :-) so please ask. best regards, Vlad _________________________________________________________________ Chatta med vänner online, prova MSN Messenger: http://messenger.msn.se |
From: Colin M. <c.m...@al...> - 2002-01-25 17:24:58
|
Alex Schroeder <al...@gn...> writes: > Colin Marquardt <c.m...@al...> writes: > >> IMO, this is requiring too much manual effort, and would not fit too well >> for code changes between release cycles (since you might be hesitant to >> make a new version). One approach I can imagine would be to put the RCS >> Id into a variable and do a substring match on it. That would only make >> it one file to change by hand, and allows a nice, custom error message. > > But then you have to do version string parsing, which is error prone, Well, the format of version numbers from RCS Ids (there was even a placeholder for just version numbers, no?) is sufficiently well documented as to be not a problem I guess, but... > and when files get integrated into Emacs, these Ids will go away, > breaking all the existing code. ...this I hadn't thought of. Hmm. If there was an ideal solution to that problem, it would have been invented and adopted long ago, so who am I to think I could do it right away... :) Cheers, Colin |
From: Alex S. <al...@gn...> - 2002-01-25 17:07:12
|
Colin Marquardt <c.m...@al...> writes: > IMO, this is requiring too much manual effort, and would not fit too well > for code changes between release cycles (since you might be hesitant to > make a new version). One approach I can imagine would be to put the RCS > Id into a variable and do a substring match on it. That would only make > it one file to change by hand, and allows a nice, custom error message. But then you have to do version string parsing, which is error prone, and when files get integrated into Emacs, these Ids will go away, breaking all the existing code. Alex. -- http://www.emacswiki.org/ |
From: Jesper N. <je...@nn...> - 2002-01-25 10:11:07
|
You wrote: > "Eric M. Ludlam" <er...@si...> writes: > >>>> Alex Schroeder <al...@gn...> seems to think that: > >>"Eric M. Ludlam" <er...@si...> writes: > >> > >>> That is a good idea that had come up recently. I am hoping to do > >>> this in the future. > >> > >>The simple thing would be to just provide more features: > >> > >>(provide 'eieio) > >>(provide 'eieio-2.0) > >>(provide 'eieio-2.1) > >>(provide 'eieio-2.2) > >>(provide 'eieio-2.3) > >> > >>And then other code could test this: > >> > >>(require 'eieio-2.2) > > > > I think that might be: > > > > (require 'eieio-2.2 "eieio") > > > > but I get the idea. I can just see a list of about 100 releases 10 > > years from now. ;) > IMO, this is requiring too much manual effort, and would not fit too well > for code changes between release cycles (since you might be hesitant to > make a new version). One approach I can imagine would be to put the RCS > Id into a variable and do a substring match on it. That would only make > it one file to change by hand, and allows a nice, custom error message. A suggestion is to include a function in EIEIO (and all other packages) tha= t tests if this version of EIEIO is compatible with the version number supp= lied as argument. For example in EIEIO you define: (defun eieio-ensure-compatibility (major minor)=20 (cond=20 ((> major eieio-version-major) (error "You must upgrade EIEIO to a new= version!")) ((< major 2) (error "Your EIEIO version is too new :-)!")))) And in the package that uses EIEIO you write: (require 'eieio) (eieio-ensure-compatibility 2 3) ;; Here you put the version of EIEIO you h= ave tested with /Jesper Nordenberg |
From: Colin M. <c.m...@al...> - 2002-01-25 09:43:01
|
"Eric M. Ludlam" <er...@si...> writes: >>>> Alex Schroeder <al...@gn...> seems to think that: >>"Eric M. Ludlam" <er...@si...> writes: >> >>> That is a good idea that had come up recently. I am hoping to do >>> this in the future. >> >>The simple thing would be to just provide more features: >> >>(provide 'eieio) >>(provide 'eieio-2.0) >>(provide 'eieio-2.1) >>(provide 'eieio-2.2) >>(provide 'eieio-2.3) >> >>And then other code could test this: >> >>(require 'eieio-2.2) > > I think that might be: > > (require 'eieio-2.2 "eieio") > > but I get the idea. I can just see a list of about 100 releases 10 > years from now. ;) IMO, this is requiring too much manual effort, and would not fit too well for code changes between release cycles (since you might be hesitant to make a new version). One approach I can imagine would be to put the RCS Id into a variable and do a substring match on it. That would only make it one file to change by hand, and allows a nice, custom error message. Cheers, Colin |
From: Alex S. <al...@gn...> - 2002-01-24 20:37:06
|
"Eric M. Ludlam" <er...@si...> writes: > but I get the idea. I can just see a list of about 100 releases 10 > years from now. ;) Hehe, so what. A hundred new symbols are peanuts. Alex. -- http://www.emacswiki.org/ |
From: Eric M. L. <er...@si...> - 2002-01-24 00:55:09
|
>>> Alex Schroeder <al...@gn...> seems to think that: >"Eric M. Ludlam" <er...@si...> writes: > >> That is a good idea that had come up recently. I am hoping to do >> this in the future. > >The simple thing would be to just provide more features: > >(provide 'eieio) >(provide 'eieio-2.0) >(provide 'eieio-2.1) >(provide 'eieio-2.2) >(provide 'eieio-2.3) > >And then other code could test this: > >(require 'eieio-2.2) I think that might be: (require 'eieio-2.2 "eieio") but I get the idea. I can just see a list of about 100 releases 10 years from now. ;) Eric -- Eric Ludlam: za...@gn..., er...@si... Home: www.ultranet.com/~zappo Siege: www.siege-engine.com Emacs: http://cedet.sourceforge.net GNU: www.gnu.org |
From: Alex S. <al...@gn...> - 2002-01-23 18:50:05
|
"Eric M. Ludlam" <er...@si...> writes: > That is a good idea that had come up recently. I am hoping to do > this in the future. The simple thing would be to just provide more features: (provide 'eieio) (provide 'eieio-2.0) (provide 'eieio-2.1) (provide 'eieio-2.2) (provide 'eieio-2.3) And then other code could test this: (require 'eieio-2.2) Alex -- http://www.emacswiki.org/ |