* Re: cc-langs.el [not found] <E19mCBN-0004BX-4J@fencepost.gnu.org> @ 2003-08-22 11:45 ` Martin Stjernholm 2003-08-22 21:21 ` cc-langs.el Miles Bader 2003-08-23 4:01 ` cc-langs.el Richard Stallman 0 siblings, 2 replies; 17+ messages in thread From: Martin Stjernholm @ 2003-08-22 11:45 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel Richard Stallman <rms@gnu.org> wrote: > This code in cc-langs.el uses CL functions at run time. Only if it isn't byte compiled, which isn't recommended. cc-langs is not even loaded when everything is byte compiled. > It won't work. I still don't understand this aversion to the CL functions. I find it absurd that there is an old and well established set of basic tools that can't be used in many situations. The only argument for that position I've heard is that the CL package isn't namespace clean with some package prefix. That argument is weak since it can't conceivably become a practical problem - the functions are so old and well established that they are comparable to the built-in functions. Anyone who would define a mapcan with any other function than the one in CL would be both very silly and break the namespace rules. > (c-lang-defconst c-operator-list > ;; The operators as a flat list (without duplicates). > t (delete-duplicates (mapcan (lambda (elem) (append (cdr elem) nil)) > (c-lang-const c-operators)) > :test 'string-equal)) > > There are further uses of mapcan in the same file. > > Please fix this, then ack by responding to this message. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-22 11:45 ` cc-langs.el Martin Stjernholm @ 2003-08-22 21:21 ` Miles Bader 2003-08-23 4:01 ` cc-langs.el Richard Stallman 1 sibling, 0 replies; 17+ messages in thread From: Miles Bader @ 2003-08-22 21:21 UTC (permalink / raw) Cc: rms, emacs-devel On Fri, Aug 22, 2003 at 01:45:44PM +0200, Martin Stjernholm wrote: > I still don't understand this aversion to the CL functions. I find it > absurd that there is an old and well established set of basic tools > that can't be used in many situations. I can't speak for Richard, but my aversion is because cl is of extremely variable quality -- much of it is very handy, but some of it really sucks (in many cases unavoidably, because it tries to do things that don't fit well into emacs' lisp engine, and unfortunately its all packaged as one big ball of hair. It's trying to provide compatibility that ultimately (1) can't be done exactly, and (2) sometimes causes big performance problems by trying. I would be a lot happier if the functionality were split up somehow, and the uncontroversial bits basically made into a separate package that makes no attempt to be `common-lisp,' but rather just tries to be a useful toolkit for elisp, and is optimized for such. [BTW, I love common-lisp, but cl is not it; sometimes it seems almost a mockery...] -Miles -- Somebody has to do something, and it's just incredibly pathetic that it has to be us. -- Jerry Garcia ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-22 11:45 ` cc-langs.el Martin Stjernholm 2003-08-22 21:21 ` cc-langs.el Miles Bader @ 2003-08-23 4:01 ` Richard Stallman 2003-08-23 13:41 ` cc-langs.el Martin Stjernholm 1 sibling, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-08-23 4:01 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel > This code in cc-langs.el uses CL functions at run time. Only if it isn't byte compiled, which isn't recommended. cc-langs is not even loaded when everything is byte compiled. I did not realize that. So I guess the code does work. I still don't understand this aversion to the CL functions. I find it absurd that there is an old and well established set of basic tools that can't be used in many situations. These functions are not a part of the Emacs Lisp namespace. (And I don't want to add them and make the Lisp manual much bigger.) Anyone who would define a mapcan with any other function than the one in CL would be both very silly and break the namespace rules. Any user can define a function called mapcan with any meaning at all. If he put it in a Lisp package for publication, that name would be a mistake, because he ought to put on a suitable prefix to avoid conflicts. But if he is just writing code for himself, that doesn't apply. ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-23 4:01 ` cc-langs.el Richard Stallman @ 2003-08-23 13:41 ` Martin Stjernholm 2003-08-24 18:00 ` cc-langs.el Richard Stallman 0 siblings, 1 reply; 17+ messages in thread From: Martin Stjernholm @ 2003-08-23 13:41 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel Richard Stallman <rms@gnu.org> wrote: > [CL] functions are not a part of the Emacs Lisp namespace. > (And I don't want to add them and make the Lisp manual much bigger.) I gather your reasoning is: They don't have a namespace prefix and hence they are in the Emacs Lisp namespace, and all functions in the Emacs Lisp namespace must be documented in the elisp manual. Considering the complexity of many elisp applications there's clearly a lack of basic utility functions in the elisp core, specifically functions to operate on the built-in data types, e.g. the map, search and replace functions in the CL package. There are many severe drawbacks when every package with the need have to avoid or reimplement them. Those drawbacks are so basic that I don't think I have to elaborate on that. So why shouldn't Emacs provide that functionality? Because of the size of the manual? That's imho an odd priority, especially considering that the navigational aids provided by Info and other browsing tools easily can handle documentation of at least ten times the size of the elisp manual. Regarding the issue that Miles Bader raised: I don't request that the entire CL library is "blessed"; I'm only talking about the functions that operate on data, i.e. the things in cl-extra.el, cl-seq.el and most of cl.el. Afaik they do their job well (or can at least be fixed to do it well, as there aren't any basic design issues that they try to cover up). The other more questionable stuff could very well remain deprecated. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-23 13:41 ` cc-langs.el Martin Stjernholm @ 2003-08-24 18:00 ` Richard Stallman 2003-08-26 22:03 ` cc-langs.el Martin Stjernholm 0 siblings, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-08-24 18:00 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel Considering the complexity of many elisp applications there's clearly a lack of basic utility functions in the elisp core, specifically functions to operate on the built-in data types, e.g. the map, search and replace functions in the CL package. Some of these functions may indeed be worth adding, and we have occasionally added some of them, but not the whole lot of them at once. ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-24 18:00 ` cc-langs.el Richard Stallman @ 2003-08-26 22:03 ` Martin Stjernholm [not found] ` <E19s8Wc-0005SJ-41@fencepost.gnu.org> 0 siblings, 1 reply; 17+ messages in thread From: Martin Stjernholm @ 2003-08-26 22:03 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel Richard Stallman <rms@gnu.org> wrote: > Some of these [CL] functions may indeed be worth adding, and we have > occasionally added some of them, but not the whole lot of them at > once. I suggest that a fair number of them are considered in one go, so that the core functions get reasonably complete in this regard. It hampers development if every single one has to be advocated individually. Afterall, they have all proven their general usefulness in a CommonLisp context, and Emacs Lisp isn't all that different. To concretize the discussion, I think the following functions are generally useful and haven't got any direct counterparts in the current set: Predicates: eql Map functions: mapcar*, cl-mapc (ought to be aliased to mapc* for consistency), maplist, mapl, mapcan, mapcon, some, every, notany, notevery Number functions: signum, oddp, evenp Sequence functions: subseq, reduce, fill, search, sort*, replace, replace*, remove-if, remove-if-not, delete*, delete-if, delete-if-not, substitute, substitute-if, substitute-if-not, nsubstitute, nsubstitute-if, nsubstitute-if-not, find, find-if, find-if-not, position, position-if, position-if-not, count, count-if, count-if-not, member*, member-if, member-if-not, assoc*, assoc-if, assoc-if-not, rassoc*, rassoc-if, rassoc-if-not, mismatch Tree functions: tree-equal, subst, subst-if, subst-if-not, nsubst, nsubst-if, nsubst-if-not List functions: ldiff, tailp, adjoin Set functions: remove-duplicates, delete-duplicates, union, nunion, intersection, nintersection, set-difference, nset-difference, set-exclusive-or, nset-exclusive-or, subsetp Property list functions: remprop Place functions: incf, decf, pushnew Macro functions: cl-macroexpand-all Control structures: flet, macrolet, assert, define-compiler-macro, defstruct ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <E19s8Wc-0005SJ-41@fencepost.gnu.org>]
* Re: cc-langs.el [not found] ` <E19s8Wc-0005SJ-41@fencepost.gnu.org> @ 2003-08-28 11:03 ` Martin Stjernholm 2003-08-29 15:53 ` cc-langs.el Richard Stallman 0 siblings, 1 reply; 17+ messages in thread From: Martin Stjernholm @ 2003-08-28 11:03 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel Richard Stallman <rms@gnu.org> wrote: > To concretize the discussion, I think the following functions are > generally useful and haven't got any direct counterparts in the > current set: > > Sorry, that is far too much. For what reason? The work of updating the manual? ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-28 11:03 ` cc-langs.el Martin Stjernholm @ 2003-08-29 15:53 ` Richard Stallman 2003-08-29 18:49 ` cc-langs.el Kevin Rodgers 0 siblings, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-08-29 15:53 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel > To concretize the discussion, I think the following functions are > generally useful and haven't got any direct counterparts in the > current set: > > Sorry, that is far too much. For what reason? The work of updating the manual? I don't even want to think about that many different functions, sorry. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-29 15:53 ` cc-langs.el Richard Stallman @ 2003-08-29 18:49 ` Kevin Rodgers 2003-08-29 23:17 ` cc-langs.el Miles Bader 0 siblings, 1 reply; 17+ messages in thread From: Kevin Rodgers @ 2003-08-29 18:49 UTC (permalink / raw) Cc: cc-mode-help Richard Stallman wrote: > > To concretize the discussion, I think the following functions are > > generally useful and haven't got any direct counterparts in the > > current set: > > > > Sorry, that is far too much. > > For what reason? The work of updating the manual? > > I don't even want to think about that many different functions, sorry. Martin's list has 82 functions. In comparison, lisp/files.el defines 83 functions, lisp/simple.el defines 152 function, and src/*.c defines 1,058 (Lisp) functions. The Common Lisp functions have a well-specified interface, and adding new functions (vs. modifying existing functions) should not affect Emacs' behavior. What's to think about? -- Kevin Rodgers ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-29 18:49 ` cc-langs.el Kevin Rodgers @ 2003-08-29 23:17 ` Miles Bader 2003-08-30 19:42 ` cc-langs.el Martin Stjernholm 0 siblings, 1 reply; 17+ messages in thread From: Miles Bader @ 2003-08-29 23:17 UTC (permalink / raw) Cc: cc-mode-help Kevin Rodgers <ihs_4664@yahoo.com> writes: > The Common Lisp functions have a well-specified interface, and adding > new functions (vs. modifying existing functions) should not affect > Emacs' behavior. What's to think about? _Emacs lisp is not common lisp_. That means that however worthy these functions are (and I know they are -- remember, I'm a common-lisp _fan_*), you can't just plop them into elisp wholesale, you've got at least look at them, and how they fit into elisp, and make decisions; interfaces and functions that are right for common-lisp are not necessarily right for elisp. For a lot of functions, that takes a fair amount of time. I realize that for sanity's sake, it would be best to use the same (or at least very similar) interfaces for elisp functions as their common-lisp counterparts, but none-the-less, you can't just plop. -Miles * Personally I'd love it if emacs used common-lisp instead of elisp. But it doesn't. -- We are all lying in the gutter, but some of us are looking at the stars. -Oscar Wilde ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-29 23:17 ` cc-langs.el Miles Bader @ 2003-08-30 19:42 ` Martin Stjernholm 2003-08-31 0:42 ` cc-langs.el Miles Bader 2003-09-01 2:22 ` cc-langs.el Richard Stallman 0 siblings, 2 replies; 17+ messages in thread From: Martin Stjernholm @ 2003-08-30 19:42 UTC (permalink / raw) Cc: bug-cc-mode Miles Bader <miles@gnu.org> wrote: > _Emacs lisp is not common lisp_. > > That means that however worthy these functions are (and I know they are > -- remember, I'm a common-lisp _fan_*), you can't just plop them into > elisp wholesale, you've got at least look at them, and how they fit into > elisp, and make decisions; interfaces and functions that are right for > common-lisp are not necessarily right for elisp. For a lot of > functions, that takes a fair amount of time. That was the intention with my list in this discussion; we collectively take a look on them and then, hopefully, agree on a set to include. I don't see how that could take an awful lot of time, but even if it does it's time well spent imho. Just saying "it's too much, it won't happen, e.o.d." is not good enough; I won't accept that as a reason for having to write cumbersome extra code to avoid these functions. > I realize that for sanity's sake, it would be best to use the same (or > at least very similar) interfaces for elisp functions as their > common-lisp counterparts, /.../ That's a very compelling reason for not meddling with their interfaces. An important point in "blessing" the CL functions instead of inventing something else is that they already been around for quite a while and are used in many places, albeit "only" at compile time in the standard packages. So, to further concretize the discussion let's bring up the specific issues that need to be considered. I can think of the following: o There are functions among the suggested ones that shouldn't be "blessed" for some reason. Well, I've already weeded out the ones that try to fix things like lexical binding and other stuff I suspect aren't reliable enough. Among those who remain that might be dubious are: - define-compiler-macro, if it doesn't work well enough with the compiler (otherwise it appears to be really useful), and - defstruct, which does a lot of stuff that I don't know how well it works (I've got no personal experience with it), and - more? o There might be more functions in the CL package that deserve to be considered. If so, those can be discussed later. o The CL map functions all accept more than one list to iterate over, whereas the built-ins only take one. When the function mapc got added as a built-in it lost that feature (which is a potential compatibility issue). I suggest that the multiple lists feature is kept, partly because it's useful occasionally, partly because it's compatible, and partly because it's no work (provided the functions remain written in lisp). It would lead to a slight inconsistency with the built-in mapcar and mapc, but that's only a minor ugliness that can be fixed later on without compatibility trouble. o The CL sequence and set functions all take keyword arguments like ":test" and ":key". That design is not new in elisp so it shouldn't be a problem per se, and the keywords are consistent and (imho) appropriate. Keeping those keywords introduces an inconsistency with the built-ins sort, remove, delete, member, assoc, and rassoc. The case is the same here as with mapcar and mapc: It's only a bit ugly and can be fixed at any time. Until then the CL counterparts ending with "*" can be used. o All the CL functions default to eql as test predicate, whereas the built-ins delete, remove, member, assoc, and rassoc use equal. This is also an inconsistency issue, but it's more serious since it can't be fixed without potential incompatibilities. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-30 19:42 ` cc-langs.el Martin Stjernholm @ 2003-08-31 0:42 ` Miles Bader 2003-09-01 2:22 ` cc-langs.el Richard Stallman 1 sibling, 0 replies; 17+ messages in thread From: Miles Bader @ 2003-08-31 0:42 UTC (permalink / raw) Martin Stjernholm <mast@lysator.liu.se> writes: > That was the intention with my list in this discussion; we > collectively take a look on them and then, hopefully, agree on a set > to include. I don't see how that could take an awful lot of time, but > even if it does it's time well spent imho. Yeah, it probably couldn't hurt to discuss the various issues in detail (if you've got enough time; rms probably doesn't of course). I'll go over your list soon and mention the various problem areas I've noticed in the past. -Miles -- Saa, shall we dance? (from a dance-class advertisement) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: cc-langs.el 2003-08-30 19:42 ` cc-langs.el Martin Stjernholm 2003-08-31 0:42 ` cc-langs.el Miles Bader @ 2003-09-01 2:22 ` Richard Stallman 2003-09-20 23:31 ` Blessing cl functions Martin Stjernholm 1 sibling, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-09-01 2:22 UTC (permalink / raw) Cc: emacs-devel, bug-cc-mode I am willing to consider a small number of functions for inclusion as standard parts of Emacs. I don't have time to consider a large number, and I can't agree to them without considering them. I do not like the Common Lisp style of using keyword arguments for many common functions. I basically do not have a very high opinion of many of the decisions that were made in Common Lisp. Adding the feature for iterating over multiple lists to mapc and mapcar is fine with me. I left that out only because I did not want to do the work implement it. If you want to write this, and do a clean job, by all means do it. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
* Blessing cl functions 2003-09-01 2:22 ` cc-langs.el Richard Stallman @ 2003-09-20 23:31 ` Martin Stjernholm 2003-09-21 22:33 ` Richard Stallman 0 siblings, 1 reply; 17+ messages in thread From: Martin Stjernholm @ 2003-09-20 23:31 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel [Continuing an old thread here.] Richard Stallman <rms@gnu.org> wrote: > I am willing to consider a small number of functions for inclusion > as standard parts of Emacs. I don't have time to consider a large > number, and I can't agree to them without considering them. Then please take a look at as many as you are able to. I think it bears repeating though, that the lack of such fundamental tools continually hampers development in the small scale. Adding just a few functions every year means almost unbearably slow progress in this regard. > I do not like the Common Lisp style of using keyword arguments > for many common functions. For functions that take a whole set of optional arguments I can't think of any better alternative; keywords are at least better than position-based argument passing. However they do incur higher runtime overhead, but that should be possible to avoid with macros. Common special cases can also be optimized to C level implementations. I can devote some time to it if that would help matters. > I basically do not have a very high opinion of many of the decisions > that were made in Common Lisp. The reasons for going with incompatible solutions would have to be pretty strong, though, since the cl functions are de-facto used in many packages (also those distributed separately). Nonconflicting names would be a necessity to begin with, but even then one has to consider the added confusion with two different libraries for the same thing. The new library would have to be a lot better designwise to motivate its existence, and when it comes to such basic stuff like this I can't see how it can be done much differently. > Adding the feature for iterating over multiple lists to mapc and > mapcar is fine with me. I left that out only because I did not want > to do the work implement it. If you want to write this, and do a > clean job, by all means do it. I could do that, especially if it would mean that the other mapping functions (maplist, mapl, mapcan, mapcon, some, every, notany, and notevery) got in too. None of those have keyword arguments, anyway. (I probably have to extend my copyright assignment agreement first, since it only covers CC Mode currently.) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Blessing cl functions 2003-09-20 23:31 ` Blessing cl functions Martin Stjernholm @ 2003-09-21 22:33 ` Richard Stallman 2003-09-21 23:03 ` Miles Bader 0 siblings, 1 reply; 17+ messages in thread From: Richard Stallman @ 2003-09-21 22:33 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel I could do that, especially if it would mean that the other mapping functions (maplist, mapl, mapcan, mapcon, some, every, notany, and notevery) got in too. None of those have keyword arguments, anyway. I don't like the idea of adding all of them, but a few of them would be ok. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Blessing cl functions 2003-09-21 22:33 ` Richard Stallman @ 2003-09-21 23:03 ` Miles Bader 0 siblings, 0 replies; 17+ messages in thread From: Miles Bader @ 2003-09-21 23:03 UTC (permalink / raw) Cc: bug-cc-mode, emacs-devel On Sun, Sep 21, 2003 at 06:33:37PM -0400, Richard Stallman wrote: > I could do that, especially if it would mean that the other mapping > functions (maplist, mapl, mapcan, mapcon, some, every, notany, and > notevery) got in too. None of those have keyword arguments, anyway. > > I don't like the idea of adding all of them, but a few of them would > be ok. The last time I looked at this, BTW, the main annoyance with adding cl-style multiple-sequence mapping operators seemed to be the interaction with support for mapping over non-list sequences. The current implementation just hands off iteration to a dedicated function for each sequence type, which doesn't work so well for multiple sequences (because each can be a different type). One could get around this by saying that mapping operators only work efficiently when all sequence arguments are of the same type, and in other cases convert additional sequence types to the type of the first before proceeding. -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ^ permalink raw reply [flat|nested] 17+ messages in thread
* RE: cc-langs.el @ 2003-08-26 18:22 Wedler, Christoph 0 siblings, 0 replies; 17+ messages in thread From: Wedler, Christoph @ 2003-08-26 18:22 UTC (permalink / raw) Cc: emacs-devel I fully agree with Martin to add (most of) cl to the elisp core! Martin Stjernholm wrote: > Considering the complexity of many elisp applications there's clearly > a lack of basic utility functions in the elisp core, specifically > functions to operate on the built-in data types, e.g. the map, search > and replace functions in the CL package. Yes, defstruct is also nice... > There are many severe drawbacks when every package with the need have > to avoid or reimplement them. Those drawbacks are so basic that I > don't think I have to elaborate on that. True enough! > Regarding the issue that Miles Bader raised: I don't request that the > entire CL library is "blessed"; [...] Sure, some cl stuff might be questionable, but what I would really like to avoid is to have to beg for every single cl function. I would like to see: cl is added, only the truly questionable stuff is not included. I.e., we will not hear "I don't think this function is useful" as a reason why a cl function is not included. And let's not forget: reinventing the wheel isn't fun. - Christoph ------------------------------------------------------- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-09-21 23:03 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <E19mCBN-0004BX-4J@fencepost.gnu.org> 2003-08-22 11:45 ` cc-langs.el Martin Stjernholm 2003-08-22 21:21 ` cc-langs.el Miles Bader 2003-08-23 4:01 ` cc-langs.el Richard Stallman 2003-08-23 13:41 ` cc-langs.el Martin Stjernholm 2003-08-24 18:00 ` cc-langs.el Richard Stallman 2003-08-26 22:03 ` cc-langs.el Martin Stjernholm [not found] ` <E19s8Wc-0005SJ-41@fencepost.gnu.org> 2003-08-28 11:03 ` cc-langs.el Martin Stjernholm 2003-08-29 15:53 ` cc-langs.el Richard Stallman 2003-08-29 18:49 ` cc-langs.el Kevin Rodgers 2003-08-29 23:17 ` cc-langs.el Miles Bader 2003-08-30 19:42 ` cc-langs.el Martin Stjernholm 2003-08-31 0:42 ` cc-langs.el Miles Bader 2003-09-01 2:22 ` cc-langs.el Richard Stallman 2003-09-20 23:31 ` Blessing cl functions Martin Stjernholm 2003-09-21 22:33 ` Richard Stallman 2003-09-21 23:03 ` Miles Bader 2003-08-26 18:22 cc-langs.el Wedler, Christoph
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.