* CL package suggestion @ 2012-04-03 16:52 Ilya Shlyakhter 2012-04-03 16:58 ` Glenn Morris 0 siblings, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-03 16:52 UTC (permalink / raw) To: emacs-devel [-- Attachment #1: Type: text/plain, Size: 714 bytes --] hello, i'd like to make a suggestion for the CL package. right now its non-macro parts can't be used at runtime. as a result, each package defines their own equivalents, e.g. org-remove-if. could Emacs add a copy of the CL package with some standard prefix, e.g. ecl? then with (require 'ecl) you get ecl-remove-if etc. the ecl or whichever prefix has to avoid conflict with known emacs packages, but that's it. the issues with polluting the global namespace / conflicting with people's private remove-if versions would not apply. the alternative is that for each package i write i copy code i need from CL (with acknowledgement of course) and add my package's prefix. that doesn't seem ideal. thanks, ilya [-- Attachment #2: Type: text/html, Size: 965 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-03 16:52 CL package suggestion Ilya Shlyakhter @ 2012-04-03 16:58 ` Glenn Morris 2012-04-03 17:00 ` Glenn Morris 0 siblings, 1 reply; 19+ messages in thread From: Glenn Morris @ 2012-04-03 16:58 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel Ilya Shlyakhter wrote: > could Emacs add a copy of the CL package with some standard prefix, e.g. > ecl? This was discussed extensively recently, and somebody volunteered to do basically that: http://lists.gnu.org/archive/html/emacs-devel/2012-02/msg00249.html Nothing happened, now it is too late for Emacs 24.1. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-03 16:58 ` Glenn Morris @ 2012-04-03 17:00 ` Glenn Morris 2012-04-03 17:09 ` Ilya Shlyakhter 0 siblings, 1 reply; 19+ messages in thread From: Glenn Morris @ 2012-04-03 17:00 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel Glenn Morris wrote: > now it is too late for Emacs 24.1. Though to be honest, it probably was too late already in February. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-03 17:00 ` Glenn Morris @ 2012-04-03 17:09 ` Ilya Shlyakhter 2012-04-03 18:58 ` Stefan Monnier 0 siblings, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-03 17:09 UTC (permalink / raw) To: Glenn Morris; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 283 bytes --] I'm just glad this is being considered :) It'd be great to see this in 24.2 . On Tue, Apr 3, 2012 at 1:00 PM, Glenn Morris <rgm@gnu.org> wrote: > Glenn Morris wrote: > > > now it is too late for Emacs 24.1. > > Though to be honest, it probably was too late already in February. > [-- Attachment #2: Type: text/html, Size: 573 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-03 17:09 ` Ilya Shlyakhter @ 2012-04-03 18:58 ` Stefan Monnier 2012-04-04 1:56 ` Ilya Shlyakhter 0 siblings, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2012-04-03 18:58 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel > I'm just glad this is being considered :) It'd be great to see this in > 24.2 . Patch welcome (and BTW, I'd prefer the "cl-" prefix over the "ecl-" prefix). It's never too early to start. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-03 18:58 ` Stefan Monnier @ 2012-04-04 1:56 ` Ilya Shlyakhter 2012-04-04 13:06 ` Stefan Monnier 0 siblings, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-04 1:56 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 661 bytes --] Agree about cl- being better than ecl- . Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two calls indistinguishable to the byte compiler? If they are, and calling cl-remove wouldn't trigger a warning, wouldn't remove-if calls also become warning-less? And if they would, isn't it simpler to just allow calling remove-if? :) ilya On Tue, Apr 3, 2012 at 2:58 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > > I'm just glad this is being considered :) It'd be great to see this in > > 24.2 . > > Patch welcome (and BTW, I'd prefer the "cl-" prefix over the "ecl-" > prefix). > It's never too early to start. > > > Stefan > [-- Attachment #2: Type: text/html, Size: 1088 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-04 1:56 ` Ilya Shlyakhter @ 2012-04-04 13:06 ` Stefan Monnier 2012-04-09 1:39 ` Ilya Shlyakhter 2012-04-09 4:54 ` Ilya Shlyakhter 0 siblings, 2 replies; 19+ messages in thread From: Stefan Monnier @ 2012-04-04 13:06 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel > Agree about cl- being better than ecl- . > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two calls > indistinguishable to the byte compiler? The name is different, so the compiler can definitely tell the difference. > If they are, and calling cl-remove wouldn't trigger a warning, > wouldn't remove-if calls also become warning-less? Not necessarily, no. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-04 13:06 ` Stefan Monnier @ 2012-04-09 1:39 ` Ilya Shlyakhter 2012-04-09 1:41 ` Ilya Shlyakhter 2012-04-09 4:54 ` Ilya Shlyakhter 1 sibling, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-09 1:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 851 bytes --] Right now, the cl package itself seems to violate the rule against calling its functions at runtime. E.g. (define-compiler-macro assoc* (&whole form a list &rest keys) ;; ... (if (floatp-safe (cl-const-expr-val a)) ;; ... floatp-safe is a function in package cl, and the compiled code will call it at runtime. Am I missing something? On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > > Agree about cl- being better than ecl- . > > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two > calls > > indistinguishable to the byte compiler? > > The name is different, so the compiler can definitely tell the difference. > > > If they are, and calling cl-remove wouldn't trigger a warning, > > wouldn't remove-if calls also become warning-less? > > Not necessarily, no. > > > Stefan > [-- Attachment #2: Type: text/html, Size: 1402 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 1:39 ` Ilya Shlyakhter @ 2012-04-09 1:41 ` Ilya Shlyakhter 0 siblings, 0 replies; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-09 1:41 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1071 bytes --] I'm sorry, the example I gave is fine -- that code of course is executed at compile-time only. On Sun, Apr 8, 2012 at 9:39 PM, Ilya Shlyakhter <ilya_shl@alum.mit.edu>wrote: > Right now, the cl package itself seems to violate the rule against calling > its functions at runtime. > E.g. > > (define-compiler-macro assoc* (&whole form a list &rest keys) > ;; ... > (if (floatp-safe (cl-const-expr-val a)) > ;; ... > > floatp-safe is a function in package cl, and the compiled code will call > it at runtime. > Am I missing something? > > On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > >> > Agree about cl- being better than ecl- . >> > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two >> calls >> > indistinguishable to the byte compiler? >> >> The name is different, so the compiler can definitely tell the difference. >> >> > If they are, and calling cl-remove wouldn't trigger a warning, >> > wouldn't remove-if calls also become warning-less? >> >> Not necessarily, no. >> >> >> Stefan >> > > [-- Attachment #2: Type: text/html, Size: 1834 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-04 13:06 ` Stefan Monnier 2012-04-09 1:39 ` Ilya Shlyakhter @ 2012-04-09 4:54 ` Ilya Shlyakhter 2012-04-09 13:28 ` Stefan Monnier 1 sibling, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-09 4:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1181 bytes --] So, about the cl package: If remove-if is renamed cl-remove-if and then 'remove-if defaliased to 'cl-remove-if, is it now ok to (require 'cl) at runtime? Won't the alias now conflict with whatever definition of remove-if the user had? And if you don't (require 'cl) at runtime, then you can't call cl-remove-if at runtime, since it might not be available. One could move cl-remove-if etc into a separate module called cl-funcs, so if you want to call cl-remove-if at runtime you (require 'cl-funcs). This would somewhat break up the logical structure of the cl package, since things will get grouped by whether they're functions or macros rather than by topic. Suggestions? On Wed, Apr 4, 2012 at 9:06 AM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > > Agree about cl- being better than ecl- . > > Btw, if remove-if becomes defalias'ed to cl-remove-if, aren't the two > calls > > indistinguishable to the byte compiler? > > The name is different, so the compiler can definitely tell the difference. > > > If they are, and calling cl-remove wouldn't trigger a warning, > > wouldn't remove-if calls also become warning-less? > > Not necessarily, no. > > > Stefan > [-- Attachment #2: Type: text/html, Size: 1786 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 4:54 ` Ilya Shlyakhter @ 2012-04-09 13:28 ` Stefan Monnier 2012-04-09 14:38 ` Ilya Shlyakhter 2012-04-11 4:18 ` Richard Stallman 0 siblings, 2 replies; 19+ messages in thread From: Stefan Monnier @ 2012-04-09 13:28 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel > If remove-if is renamed cl-remove-if and then 'remove-if defaliased to > 'cl-remove-if, is it now ok to (require 'cl) at runtime? Won't the > alias now conflict with whatever definition of remove-if the user had? > And if you don't (require 'cl) at runtime, then you can't call > cl-remove-if at runtime, since it might not be available. We need a (require 'cl-<something>) which brings up CL but only within the "cl-" namespace. I don't have a good idea for naming. `cl-defs' might be OK, but I'm open to other suggestions. Maybe `cl-layer', or `cl-emu', or `cl-compat'? > One could move cl-remove-if etc into a separate module called cl-funcs, > so if you want to call cl-remove-if at runtime you (require 'cl-funcs). `cl-funs' is another option, indeed. > This would somewhat break up the logical structure of the cl package, > since things will get grouped by whether they're functions or macros > rather than by topic. No: The way to do it is to rename cl.el to cl-<something>.el, change all its definitions to use the "cl-" prefix and then create a new cl.el which only contains defaliases. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 13:28 ` Stefan Monnier @ 2012-04-09 14:38 ` Ilya Shlyakhter 2012-04-09 16:24 ` Stefan Monnier 2012-04-11 4:18 ` Richard Stallman 1 sibling, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-09 14:38 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 313 bytes --] Maybe cl-runtime, or cl-rt? We need a (require 'cl-<something>) which brings up CL but only within > the "cl-" namespace. I don't have a good idea for naming. `cl-defs' > might be OK, but I'm open to other suggestions. Maybe `cl-layer', or > `cl-emu', or `cl-compat'? > `cl-funs' is another option, indeed. > [-- Attachment #2: Type: text/html, Size: 555 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 14:38 ` Ilya Shlyakhter @ 2012-04-09 16:24 ` Stefan Monnier 2012-04-09 16:45 ` Ilya Shlyakhter 0 siblings, 1 reply; 19+ messages in thread From: Stefan Monnier @ 2012-04-09 16:24 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel > Maybe cl-runtime, or cl-rt? I'd rather not insist on the "runtime" side. It will just be the new canonical name of "cl". We can't use "cl" because too many package presume an implementation of "cl" which is not namespace clean, whereas the new "cl" will be namespace-clean. Maybe 'cl-clean' ? Stefan > We need a (require 'cl-<something>) which brings up CL but only within >> the "cl-" namespace. I don't have a good idea for naming. `cl-defs' >> might be OK, but I'm open to other suggestions. Maybe `cl-layer', or >> `cl-emu', or `cl-compat'? >> `cl-funs' is another option, indeed. >> ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 16:24 ` Stefan Monnier @ 2012-04-09 16:45 ` Ilya Shlyakhter 2012-04-09 16:54 ` Ilya Shlyakhter 2012-04-10 12:51 ` Stefan Monnier 0 siblings, 2 replies; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-09 16:45 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1457 bytes --] cl-clean sounds a bit like a development stage in a project (alpha, beta, clean...) -- might be confusing as a permanent package name? other than that, sounds good. other possibilities: cl2 cl-new cl-compat cl-ext cl-exts cl-extensions btw, the name prefix will stay as cl- , as in cl-remove-if, whatever the 'require symbol, correct? also, should the names be changed everywhere in the CL package manual, or just add a separate section saying that the following names should really be prefixed? also: should i also add cl- aliases for macro names in CL, for uniformity? eg proclaim is a function while declaim is a macro, but should the user have to keep that in mind or just use cl-proclaim and cl-declaim and have it work? On Mon, Apr 9, 2012 at 12:24 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > > Maybe cl-runtime, or cl-rt? > > I'd rather not insist on the "runtime" side. It will just be the new > canonical name of "cl". We can't use "cl" because too many package > presume an implementation of "cl" which is not namespace clean, whereas > the new "cl" will be namespace-clean. > > Maybe 'cl-clean' ? > > > Stefan > > > > We need a (require 'cl-<something>) which brings up CL but only within > >> the "cl-" namespace. I don't have a good idea for naming. `cl-defs' > >> might be OK, but I'm open to other suggestions. Maybe `cl-layer', or > >> `cl-emu', or `cl-compat'? > >> `cl-funs' is another option, indeed. > >> > [-- Attachment #2: Type: text/html, Size: 2215 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 16:45 ` Ilya Shlyakhter @ 2012-04-09 16:54 ` Ilya Shlyakhter 2012-04-10 12:51 ` Stefan Monnier 1 sibling, 0 replies; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-09 16:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- Attachment #1: Type: text/plain, Size: 1676 bytes --] p.s. cl-compat is taken (though obsolete), so that's not an option. On Mon, Apr 9, 2012 at 12:45 PM, Ilya Shlyakhter <ilya_shl@alum.mit.edu>wrote: > cl-clean sounds a bit like a development stage in a project (alpha, beta, > clean...) -- might be confusing as a permanent > package name? other than that, sounds good. > > other possibilities: > cl2 > cl-new > cl-compat > cl-ext > cl-exts > cl-extensions > > btw, the name prefix will stay as cl- , as in cl-remove-if, whatever the > 'require symbol, correct? > > also, should the names be changed everywhere in the CL package manual, or > just add a separate section > saying that the following names should really be prefixed? > > also: should i also add cl- aliases for macro names in CL, for uniformity? > eg proclaim is a function while declaim > is a macro, but should the user have to keep that in mind or just use > cl-proclaim and cl-declaim and have it work? > > On Mon, Apr 9, 2012 at 12:24 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote: > >> > Maybe cl-runtime, or cl-rt? >> >> I'd rather not insist on the "runtime" side. It will just be the new >> canonical name of "cl". We can't use "cl" because too many package >> presume an implementation of "cl" which is not namespace clean, whereas >> the new "cl" will be namespace-clean. >> >> Maybe 'cl-clean' ? >> >> >> Stefan >> >> >> > We need a (require 'cl-<something>) which brings up CL but only within >> >> the "cl-" namespace. I don't have a good idea for naming. `cl-defs' >> >> might be OK, but I'm open to other suggestions. Maybe `cl-layer', or >> >> `cl-emu', or `cl-compat'? >> >> `cl-funs' is another option, indeed. >> >> >> > > [-- Attachment #2: Type: text/html, Size: 2634 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 16:45 ` Ilya Shlyakhter 2012-04-09 16:54 ` Ilya Shlyakhter @ 2012-04-10 12:51 ` Stefan Monnier 1 sibling, 0 replies; 19+ messages in thread From: Stefan Monnier @ 2012-04-10 12:51 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: emacs-devel > cl-clean sounds a bit like a development stage in a project (alpha, > beta, clean...) -- might be confusing as a permanent package name? > other than that, sounds good. Not sure how much of a problem that is, but if people don't like it, we can surely find something else: `cl-all', `cl-prefix'? > other possibilities: > cl2 > cl-new > cl-compat > cl-ext > cl-exts > cl-extensions I don't like the "2" and "new" concepts here, since it's not a reimplementation/redesign. I didn't like "cl-ext" at first, but maybe there's some sense to it. How 'bout "cl-lib" instead? > btw, the name prefix will stay as cl- , as in cl-remove-if, whatever the > 'require symbol, correct? Yes. > also, should the names be changed everywhere in the CL package manual, > or just add a separate section saying that the following names should > really be prefixed? We want to discourage the use of plain (require 'cl), so the manual should reflect that and document the prefixed names. > also: should i also add cl- aliases for macro names in CL, for uniformity? That's a good question and I haven't thought much about it. I'm leaning towards the "yes" (e.g. I don't like the current dolist/dotimes situation where those macros are defined in two different ways depending on whether `cl' is loaded or not). Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-09 13:28 ` Stefan Monnier 2012-04-09 14:38 ` Ilya Shlyakhter @ 2012-04-11 4:18 ` Richard Stallman 2012-04-11 14:12 ` Ilya Shlyakhter 1 sibling, 1 reply; 19+ messages in thread From: Richard Stallman @ 2012-04-11 4:18 UTC (permalink / raw) To: Stefan Monnier; +Cc: ilya_shl, emacs-devel No: The way to do it is to rename cl.el to cl-<something>.el, change all its definitions to use the "cl-" prefix and then create a new cl.el which only contains defaliases. Yes, that would be the right way. My suggestions for names for the new package are cl-safe, cl-imp (for implementation), or cl-nice (because it is nice to the namespace). > also: should i also add cl- aliases for macro names in CL, for uniformity? That's a good question and I haven't thought much about it. I'm leaning towards the "yes" (e.g. I don't like the current dolist/dotimes situation where those macros are defined in two different ways depending on whether `cl' is loaded or not). I agree. -- Dr Richard Stallman President, Free Software Foundation 51 Franklin St Boston MA 02110 USA www.fsf.org www.gnu.org Skype: No way! That's nonfree (freedom-denying) software. Use free telephony http://directory.fsf.org/category/tel/ ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-11 4:18 ` Richard Stallman @ 2012-04-11 14:12 ` Ilya Shlyakhter 2012-04-11 14:32 ` Stefan Monnier 0 siblings, 1 reply; 19+ messages in thread From: Ilya Shlyakhter @ 2012-04-11 14:12 UTC (permalink / raw) To: rms; +Cc: Stefan Monnier, emacs-devel [-- Attachment #1: Type: text/plain, Size: 1683 bytes --] Of the names mentioned so far, cl-lib seems best to me: what distinguishes cl from most other packages is that it's a library of callable code rather than an implementation of some user-facing functionality. cl-ext would also work for the same reason. If the intention is to eventually obsolete and forget about the non-safe, non-clean and non-nice version of cl, then cl-safe/cl-clean/cl-nice might look strange in future code (suggesting that there's a non-safe/non-clean/non-nice version somewhere & the user is choosing the safe/clean/nice version for their particular program). Cf. car-safe, floatp-safe etc. On Wed, Apr 11, 2012 at 12:18 AM, Richard Stallman <rms@gnu.org> wrote: > No: The way to do it is to rename cl.el to cl-<something>.el, change all > its definitions to use the "cl-" prefix and then create a new cl.el > which only contains defaliases. > > Yes, that would be the right way. > > My suggestions for names for the new package are cl-safe, cl-imp (for > implementation), or cl-nice (because it is nice to the namespace). > > > also: should i also add cl- aliases for macro names in CL, for > uniformity? > > That's a good question and I haven't thought much about it. I'm leaning > towards the "yes" (e.g. I don't like the current dolist/dotimes > situation where those macros are defined in two different ways > depending on whether `cl' is loaded or not). > > I agree. > > -- > Dr Richard Stallman > President, Free Software Foundation > 51 Franklin St > Boston MA 02110 > USA > www.fsf.org www.gnu.org > Skype: No way! That's nonfree (freedom-denying) software. > Use free telephony http://directory.fsf.org/category/tel/ > [-- Attachment #2: Type: text/html, Size: 2382 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: CL package suggestion 2012-04-11 14:12 ` Ilya Shlyakhter @ 2012-04-11 14:32 ` Stefan Monnier 0 siblings, 0 replies; 19+ messages in thread From: Stefan Monnier @ 2012-04-11 14:32 UTC (permalink / raw) To: Ilya Shlyakhter; +Cc: rms, emacs-devel > Of the names mentioned so far, cl-lib seems best to me: what distinguishes OK, let's go with `cl-lib'. Stefan ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2012-04-11 14:32 UTC | newest] Thread overview: 19+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-04-03 16:52 CL package suggestion Ilya Shlyakhter 2012-04-03 16:58 ` Glenn Morris 2012-04-03 17:00 ` Glenn Morris 2012-04-03 17:09 ` Ilya Shlyakhter 2012-04-03 18:58 ` Stefan Monnier 2012-04-04 1:56 ` Ilya Shlyakhter 2012-04-04 13:06 ` Stefan Monnier 2012-04-09 1:39 ` Ilya Shlyakhter 2012-04-09 1:41 ` Ilya Shlyakhter 2012-04-09 4:54 ` Ilya Shlyakhter 2012-04-09 13:28 ` Stefan Monnier 2012-04-09 14:38 ` Ilya Shlyakhter 2012-04-09 16:24 ` Stefan Monnier 2012-04-09 16:45 ` Ilya Shlyakhter 2012-04-09 16:54 ` Ilya Shlyakhter 2012-04-10 12:51 ` Stefan Monnier 2012-04-11 4:18 ` Richard Stallman 2012-04-11 14:12 ` Ilya Shlyakhter 2012-04-11 14:32 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).