* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries @ 2015-03-08 18:02 Drew Adams 2015-03-08 18:12 ` Eli Zaretskii 2015-03-08 18:21 ` Daniel Colascione 0 siblings, 2 replies; 20+ messages in thread From: Drew Adams @ 2015-03-08 18:02 UTC (permalink / raw) To: 20056 In our `cl*.el' libraries we have some user-facing `cl-*' macros etc. that do not correspond to anything in Common Lisp. This seems misguided. We see this in node (cl) `Modify Macros', for example: "The following macros were invented for this package; they have no analogues in Common Lisp." Why add them to a package that is for Common Lisp functionality (it is "The GNU Emacs Common Lisp emulation package") if they are not part of Common Lisp? This is quite misleading, and it has led some people to think that `letf' etc. are in fact part of Common Lisp. Please consider renaming these without the `cl-' prefix and moving them to a different library, whose name does not start with `cl'. In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2015-02-27 on LEG570 Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs' ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 18:02 bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries Drew Adams @ 2015-03-08 18:12 ` Eli Zaretskii 2015-03-08 19:06 ` Dani Moncayo 2015-03-08 18:21 ` Daniel Colascione 1 sibling, 1 reply; 20+ messages in thread From: Eli Zaretskii @ 2015-03-08 18:12 UTC (permalink / raw) To: Drew Adams, dmoncayo; +Cc: 20056 > Date: Sun, 8 Mar 2015 11:02:33 -0700 (PDT) > From: Drew Adams <drew.adams@oracle.com> > > In GNU Emacs 25.0.50.1 (i686-pc-mingw32) > of 2015-02-27 on LEG570 > Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 ^^^^^^^^^^^^^ Dani, what's this "bzr revision" thing about? Do you see that on your machine as well? ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 18:12 ` Eli Zaretskii @ 2015-03-08 19:06 ` Dani Moncayo 2015-03-08 20:10 ` Eli Zaretskii 2016-02-29 20:08 ` Glenn Morris 0 siblings, 2 replies; 20+ messages in thread From: Dani Moncayo @ 2015-03-08 19:06 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 20056 >> In GNU Emacs 25.0.50.1 (i686-pc-mingw32) >> of 2015-02-27 on LEG570 >> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 > ^^^^^^^^^^^^^ > > Dani, what's this "bzr revision" thing about? I don't know. > Do you see that on your > machine as well? No, I see this: In GNU Emacs 25.0.50.1 (i686-pc-mingw32) of 2015-02-27 on LEG570 Repository revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 Windowing system distributor `Microsoft Corp.', version 6.3.9600 Configured using: `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs' -- Dani Moncayo ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 19:06 ` Dani Moncayo @ 2015-03-08 20:10 ` Eli Zaretskii 2016-02-29 20:08 ` Glenn Morris 1 sibling, 0 replies; 20+ messages in thread From: Eli Zaretskii @ 2015-03-08 20:10 UTC (permalink / raw) To: Dani Moncayo; +Cc: 20056 > Date: Sun, 8 Mar 2015 20:06:44 +0100 > From: Dani Moncayo <dmoncayo@gmail.com> > Cc: Drew Adams <drew.adams@oracle.com>, 20056@debbugs.gnu.org > > >> In GNU Emacs 25.0.50.1 (i686-pc-mingw32) > >> of 2015-02-27 on LEG570 > >> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 > > ^^^^^^^^^^^^^ > > > > Dani, what's this "bzr revision" thing about? > > I don't know. > > > Do you see that on your > > machine as well? > > No, I see this: > > In GNU Emacs 25.0.50.1 (i686-pc-mingw32) > of 2015-02-27 on LEG570 > Repository revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 > Windowing system distributor `Microsoft Corp.', version 6.3.9600 > Configured using: > `configure --host=i686-pc-mingw32 --enable-checking=yes,glyphs' Thanks, I guess there's some subtle bug that only rears its head when git the executable is not around. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 19:06 ` Dani Moncayo 2015-03-08 20:10 ` Eli Zaretskii @ 2016-02-29 20:08 ` Glenn Morris 2016-02-29 20:57 ` Drew Adams 1 sibling, 1 reply; 20+ messages in thread From: Glenn Morris @ 2016-02-29 20:08 UTC (permalink / raw) To: 20056 Dani Moncayo wrote: >>> In GNU Emacs 25.0.50.1 (i686-pc-mingw32) >>> of 2015-02-27 on LEG570 >>> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 >> ^^^^^^^^^^^^^ >> >> Dani, what's this "bzr revision" thing about? > > I don't know. For the record, it's a bug in Someone's custom Emacs bug reporting package. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2016-02-29 20:08 ` Glenn Morris @ 2016-02-29 20:57 ` Drew Adams 0 siblings, 0 replies; 20+ messages in thread From: Drew Adams @ 2016-02-29 20:57 UTC (permalink / raw) To: Glenn Morris, 20056 > >>> In GNU Emacs 25.0.50.1 (i686-pc-mingw32) > >>> of 2015-02-27 on LEG570 > >>> Bzr revision: b2a590d4e3dc692a97c1b53e015b945d84b4b4c7 > >> ^^^^^^^^^^^^^ > >> > >> Dani, what's this "bzr revision" thing about? > > > > I don't know. > > For the record, it's a bug in Someone's custom Emacs bug reporting > package. Yes, it came fom my library `emacsbug+.el'. http://www.emacswiki.org/emacs/download/emacsbug%2b.el It does this: (insert "\n\nIn " (emacs-version) "\n") (when (and (boundp 'emacs-bzr-version) (stringp emacs-bzr-version)) (insert "Bzr revision: " emacs-bzr-version "\n")) Which is exactly what vanilla Emacs did too, a couple of years ago. I just had not updated my library to use the renamed label, `Repository version:'. I've done that now, so this scandalous problem should no longer plague you. In any case, my code does not define or set `emacs-bzr-version'. ,---- | emacs-bzr-version is a variable defined in `emacsbug+.el'. | Its value is nil | | This variable is an alias for `emacs-repository-version'. | This variable is obsolete since 24.4; | use `emacs-repository-version' instead. | | Documentation: | String giving the repository revision from which this Emacs was built. | Value is nil if Emacs was not built from a repository checkout, | or if we could not determine the revision. `---- My code uses the old name of this variable because it works, including across multiple Emacs versions. Naturally, I proposed the little that `emacsbugs+.el' does to Emacs Dev for `emacsbug.el'. Naturally, there was no interest. What does it do? It just lets users choose which fields to include by default in a bug report. What Emacs does with a monolithic `report-emacs-bug', this library does with a modular `report-emacs-bug'. That's all. Not a biggee. User option `ebp-report-emacs-bug-included-fields': (defcustom ebp-report-emacs-bug-included-fields '(version settings major-mode minor-modes recent-input recent-messages load-shadows features) "Fields to include by default for command `report-emacs-bug'. The fields are included automatically in the buffer where you edit your bug report." :type '(set (const :tag "Emacs version info" version) (const :tag "Important settings" settings) (const :tag "Major mode" major-mode) (const :tag "Minor modes" minor-modes) (const :tag "Recent input" recent-input) (const :tag "Recent messages" recent-messages) (const :tag "Load-path shadows" load-shadows) (const :tag "Features" features)) :group 'emacsbug-plus :group 'convenience) For my own purposes, I use the value `(version)': report just the version info, by default. There are also commands to insert all or any of the fields. To insert recent input, for example, you can use command `edp-insert-recent-input'. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 18:02 bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries Drew Adams 2015-03-08 18:12 ` Eli Zaretskii @ 2015-03-08 18:21 ` Daniel Colascione 2015-03-08 18:46 ` Drew Adams 1 sibling, 1 reply; 20+ messages in thread From: Daniel Colascione @ 2015-03-08 18:21 UTC (permalink / raw) To: Drew Adams, 20056 [-- Attachment #1: Type: text/plain, Size: 997 bytes --] On 03/08/2015 11:02 AM, Drew Adams wrote: > In our `cl*.el' libraries we have some user-facing `cl-*' macros etc. > that do not correspond to anything in Common Lisp. This seems > misguided. > > We see this in node (cl) `Modify Macros', for example: > > "The following macros were invented for this package; they have no > analogues in Common Lisp." > > Why add them to a package that is for Common Lisp functionality (it is > "The GNU Emacs Common Lisp emulation package") if they are not part of > Common Lisp? > > This is quite misleading, and it has led some people to think that > `letf' etc. are in fact part of Common Lisp. Please consider renaming > these without the `cl-' prefix and moving them to a different library, > whose name does not start with `cl'. Even cl functions that have the same names as functions in Common Lisp don't always have the same features or semantics. I don't think it's very important that the cl package mirror Common Lisp. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 18:21 ` Daniel Colascione @ 2015-03-08 18:46 ` Drew Adams 2015-03-08 19:11 ` Daniel Colascione 0 siblings, 1 reply; 20+ messages in thread From: Drew Adams @ 2015-03-08 18:46 UTC (permalink / raw) To: Daniel Colascione, 20056 > Even cl functions that have the same names as functions in Common Lisp > don't always have the same features or semantics. I don't think it's > very important that the cl package mirror Common Lisp. That is something quite different. Those differences are pointed out, and the aim is to emulate Common Lisp, however imperfectly we might be able to (or might want to) do so at any given time. There is no reason to misleadingly add stuff to our emulation library that has no counterpart is Common Lisp - is not emulating anything there. It is even worse to use names that make it look as if these do correspond to Common Lisp things. It is perfectly fine for Emacs to add things that Common Lisp does not have/do. But it should add them elsewhere from the `cl*.el' files, and document them elsewhere than in manual CL. These are *Emacs* things that have nothing to do with Common Lisp. If you start adding non Common-Lisp stuff to `cl*.el', then where will you stop? What will be your criteria for adding them to `cl*.el'? If they do not emulate something in Common Lisp then they belong elsewhere from `cl*.el' (this should be obvious, I think). We are not redesigning Common Lisp or pretending to do so. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 18:46 ` Drew Adams @ 2015-03-08 19:11 ` Daniel Colascione 2015-03-08 21:12 ` Drew Adams 0 siblings, 1 reply; 20+ messages in thread From: Daniel Colascione @ 2015-03-08 19:11 UTC (permalink / raw) To: Drew Adams, 20056 [-- Attachment #1: Type: text/plain, Size: 1340 bytes --] On 03/08/2015 11:46 AM, Drew Adams wrote: >> Even cl functions that have the same names as functions in Common Lisp >> don't always have the same features or semantics. I don't think it's >> very important that the cl package mirror Common Lisp. > > That is something quite different. Those differences are pointed > out, and the aim is to emulate Common Lisp, however imperfectly > we might be able to (or might want to) do so at any given time. > > There is no reason to misleadingly add stuff to our emulation > library that has no counterpart is Common Lisp - is not > emulating anything there. It is even worse to use names that > make it look as if these do correspond to Common Lisp things. > > It is perfectly fine for Emacs to add things that Common Lisp > does not have/do. But it should add them elsewhere from the > `cl*.el' files, and document them elsewhere than in manual CL. Why? Some things (like letf) are just natural extensions of facilities we got from Common Lisp. Keep in mind that they didn't start out under the cl namespace either. They were just there along with everything else when we created cl-lib. I don't think you've explained the downside of extending CL in the cl- namespace. You've articulated an aesthetic point, but I don't see any negative technical consequences. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 19:11 ` Daniel Colascione @ 2015-03-08 21:12 ` Drew Adams 2015-03-08 21:19 ` Daniel Colascione 0 siblings, 1 reply; 20+ messages in thread From: Drew Adams @ 2015-03-08 21:12 UTC (permalink / raw) To: Daniel Colascione, 20056 > > There is no reason to misleadingly add stuff to our emulation > > library that has no counterpart is Common Lisp - is not > > emulating anything there. It is even worse to use names that > > make it look as if these do correspond to Common Lisp things. > > > > It is perfectly fine for Emacs to add things that Common Lisp > > does not have/do. But it should add them elsewhere from the > > `cl*.el' files, and document them elsewhere than in manual CL. > > Why? Some things (like letf) are just natural extensions of > facilities we got from Common Lisp. They may be natural extensions of Common Lisp for you, but that does not make them Common Lisp, and it does not make them natural extensions of Common Lisp for Common Lisp's designers. We are not designing or extending Common Lisp. That would be pretentious. We are designing Emacs Lisp. It is perfectly fine to extend or redesign Emacs Lisp any way we like. And we can take whatever we want from Common Lisp and do whatever we want with it. We need not try to emulate any given Common-Lisp function or macro. But the things we put in the Common-Lisp emulation package should be emulations of Common Lisp things, IMO - things designed by the Common-Lisp designers for Common Lisp. It is not appropriate to add non Common-Lisp things to our emulation of Common Lisp. That's all. > Keep in mind that they didn't start out under the cl namespace > either. They were just there along with everything else > when we created cl-lib. Yes, they should have been moved out of `cl*.el' before the creation of `cl-lib.el'. It's not too late to clean things up now and put them in non-`cl*.el' files where they belong (and of course remove the `cl-' prefix). They do not represent Common Lisp features in any way. So call it `letf', not `cl-letf', and move it out of `cl*.el'. Similarly for anything else that is unrelated to Common Lisp. > I don't think you've explained the downside of extending CL > in the cl-namespace. It's not about "extending CL in the cl-namespace". It's about a misguided, if indirect, attempt to extend Common Lisp, and giving the mistaken impression that these things are part of Common Lisp. It's not about the namespace. The same bug report applies to the old `letf' etc. in the old `cl-macs.el' (now called `cl--letf' in the new `cl-macs.el'). The name `letf' was fine for Emacs. And it still is. It just does not belong in `cl*.el'. > You've articulated an aesthetic point, but I don't see any > negative technical consequences. Technical consequences? It's about how this misleads users - user consequences. You've not articulated any criteria for adding a function or macro to `cl*.el'. Why not move `while' there as `cl-while'? Any number of Emacs functions and macros, could be argued to be "natural extensions of facilities we got from Common Lisp." That's too vague to mean anything helpful. Just because we got `let', `let*', and `setf' from Common Lisp, that's no reason that we should add `letf' or `cl-letf' - which have no counterpart in Common Lisp - to `cl*.el'. That's what this bug report is about: Just what should be part of our Common-Lisp emulation package. The criterion I would use is this: The only things that belong there are things that emulate things in Common Lisp. If Common Lisp has a function or macro `foo' then we can consider emulating it (under whatever name) and adding it to the `cl*.el' files. If not, it belongs elsewhere in Emacs. What, specifically, are your criteria for inclusion in `cl*.el'? I was quite specific about mine. How about you? ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 21:12 ` Drew Adams @ 2015-03-08 21:19 ` Daniel Colascione 2015-03-08 21:31 ` Drew Adams 2015-03-09 4:52 ` Stefan Monnier 0 siblings, 2 replies; 20+ messages in thread From: Daniel Colascione @ 2015-03-08 21:19 UTC (permalink / raw) To: Drew Adams, 20056 [-- Attachment #1: Type: text/plain, Size: 788 bytes --] On 03/08/2015 02:12 PM, Drew Adams wrote: > It is perfectly fine to extend or redesign Emacs Lisp any way we > like. And we can take whatever we want from Common Lisp and do > whatever we want with it. We need not try to emulate any given > Common-Lisp function or macro. But the things we put in the > Common-Lisp emulation package should be emulations of Common Lisp > things, IMO - things designed by the Common-Lisp designers for > Common Lisp. > > It is not appropriate to add non Common-Lisp things to our > emulation of Common Lisp. That's all. I think cl-lib has long ago stopped being an emulation of common lisp. Now, it's a CL-*inspired* utility library. I doubt that there's a risk of real harmful confusion between this library and actual Common Lisp. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 21:19 ` Daniel Colascione @ 2015-03-08 21:31 ` Drew Adams 2015-03-09 4:52 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: Drew Adams @ 2015-03-08 21:31 UTC (permalink / raw) To: Daniel Colascione, 20056 > > It is perfectly fine to extend or redesign Emacs Lisp any way we > > like. And we can take whatever we want from Common Lisp and do > > whatever we want with it. We need not try to emulate any given > > Common-Lisp function or macro. But the things we put in the > > Common-Lisp emulation package should be emulations of Common Lisp > > things, IMO - things designed by the Common-Lisp designers for > > Common Lisp. > > > > It is not appropriate to add non Common-Lisp things to our > > emulation of Common Lisp. That's all. > > I think cl-lib has long ago stopped being an emulation of common lisp. What makes you think so? Even if that were true, it's not a reason not to clean it up now. And if it is not to be cleaned up, what criteria (3rd time asking) do you apply to decide what goes into it and what does not? > Now, it's a CL-*inspired* utility library. What does that even mean? Inspired how? What criteria define what is or is not a "CL-*inspired* utility"? If ever there was a huge language that touches nearly everything and nearly every software engineering construct/approach, it's Common Lisp. What is not a "CL-*inspired* utility"? > I doubt that there's a risk of real harmful confusion between > this library and actual Common Lisp. Google for `letf' and you will find that just such confusion has occurred. And there is no reason for it. That's the point - it doesn't have to be this way. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-08 21:19 ` Daniel Colascione 2015-03-08 21:31 ` Drew Adams @ 2015-03-09 4:52 ` Stefan Monnier 2019-08-02 12:50 ` Lars Ingebrigtsen 1 sibling, 1 reply; 20+ messages in thread From: Stefan Monnier @ 2015-03-09 4:52 UTC (permalink / raw) To: Daniel Colascione; +Cc: 20056 FWIW, I'll just mention that I agree with Daniel's assessment. Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2015-03-09 4:52 ` Stefan Monnier @ 2019-08-02 12:50 ` Lars Ingebrigtsen 2019-08-03 2:49 ` Noam Postavsky 0 siblings, 1 reply; 20+ messages in thread From: Lars Ingebrigtsen @ 2019-08-02 12:50 UTC (permalink / raw) To: Stefan Monnier; +Cc: 20056 Stefan Monnier <monnier@iro.umontreal.ca> writes: > FWIW, I'll just mention that I agree with Daniel's assessment. Seems like most agree that this isn't something to be fixed, and I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2019-08-02 12:50 ` Lars Ingebrigtsen @ 2019-08-03 2:49 ` Noam Postavsky 2019-08-03 7:49 ` Štěpán Němec 2019-08-03 21:10 ` Stefan Monnier 0 siblings, 2 replies; 20+ messages in thread From: Noam Postavsky @ 2019-08-03 2:49 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 20056, Stefan Monnier Lars Ingebrigtsen <larsi@gnus.org> writes: > Stefan Monnier <monnier@iro.umontreal.ca> writes: > >> FWIW, I'll just mention that I agree with Daniel's assessment. > > Seems like most agree that this isn't something to be fixed, and I'm > closing this bug report. Things have changed since the original discussion though: now that setf has been moved out of cl-lib, I think cl-letf and cl-callf should go with it. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2019-08-03 2:49 ` Noam Postavsky @ 2019-08-03 7:49 ` Štěpán Němec 2019-08-03 10:30 ` Lars Ingebrigtsen 2019-08-03 21:10 ` Stefan Monnier 1 sibling, 1 reply; 20+ messages in thread From: Štěpán Němec @ 2019-08-03 7:49 UTC (permalink / raw) To: Noam Postavsky; +Cc: 20056, Lars Ingebrigtsen, Stefan Monnier On Fri, 02 Aug 2019 22:49:19 -0400 Noam Postavsky wrote: > Things have changed since the original discussion though: now that setf > has been moved out of cl-lib, I think cl-letf and cl-callf should go > with it. As much as I would personally like to get rid of the prefixes, it seems to me that unless you move _most_ of cl-, you'll only increase the confusion. Now it's just setf, that's easy to remember, but with more exceptions one would have to check if a particular form is or isn't supposed to be used with the prefix all the time (albeit with the help of the byte compiler). Considering your proposal in particular, what about shiftf, rotatef? What makes them different? -- Štěpán ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2019-08-03 7:49 ` Štěpán Němec @ 2019-08-03 10:30 ` Lars Ingebrigtsen 2019-08-03 12:58 ` Noam Postavsky 0 siblings, 1 reply; 20+ messages in thread From: Lars Ingebrigtsen @ 2019-08-03 10:30 UTC (permalink / raw) To: Štěpán Němec; +Cc: 20056, Noam Postavsky, Stefan Monnier Štěpán Němec <stepnem@gmail.com> writes: > Considering your proposal in particular, what about shiftf, rotatef? > What makes them different? And incf/decf. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2019-08-03 10:30 ` Lars Ingebrigtsen @ 2019-08-03 12:58 ` Noam Postavsky 2019-08-03 13:16 ` Štěpán Němec 0 siblings, 1 reply; 20+ messages in thread From: Noam Postavsky @ 2019-08-03 12:58 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 20056, Štěpán Němec, Stefan Monnier Lars Ingebrigtsen <larsi@gnus.org> writes: > Štěpán Němec <stepnem@gmail.com> writes: > >> Considering your proposal in particular, what about shiftf, rotatef? >> What makes them different? > > And incf/decf. That letf and callf are not defined by Common Lisp. ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2019-08-03 12:58 ` Noam Postavsky @ 2019-08-03 13:16 ` Štěpán Němec 0 siblings, 0 replies; 20+ messages in thread From: Štěpán Němec @ 2019-08-03 13:16 UTC (permalink / raw) To: Noam Postavsky; +Cc: 20056, Lars Ingebrigtsen, Stefan Monnier On Sat, 03 Aug 2019 08:58:45 -0400 Noam Postavsky wrote: > Lars Ingebrigtsen <larsi@gnus.org> writes: > >> Štěpán Němec <stepnem@gmail.com> writes: >> >>> Considering your proposal in particular, what about shiftf, rotatef? >>> What makes them different? >> >> And incf/decf. > > That letf and callf are not defined by Common Lisp. Yeah, but setf is... (and as pointed out elsewhere in the thread, letf and callf really belong naturally with the others). Anyway, I see that your proposal _is_ in fact limited to these and the more general cl- problem is beyond this particular bug report, sorry for the noise. -- Štěpán ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries 2019-08-03 2:49 ` Noam Postavsky 2019-08-03 7:49 ` Štěpán Němec @ 2019-08-03 21:10 ` Stefan Monnier 1 sibling, 0 replies; 20+ messages in thread From: Stefan Monnier @ 2019-08-03 21:10 UTC (permalink / raw) To: Noam Postavsky; +Cc: 20056, Lars Ingebrigtsen > Things have changed since the original discussion though: now that setf > has been moved out of cl-lib, I think cl-letf and cl-callf should go > with it. I'm OK with moving them out of CL, but they should go to gv.el (i.e. with a `gv-` prefix). And w.r.t cl-callf, I'd rather replace it is something slightly different (like the `gv-modify` discussed recently-ish). Stefan ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-08-03 21:10 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-03-08 18:02 bug#20056: 25.0.50; Remove non Common Lisp stuff from cl*.el libraries Drew Adams 2015-03-08 18:12 ` Eli Zaretskii 2015-03-08 19:06 ` Dani Moncayo 2015-03-08 20:10 ` Eli Zaretskii 2016-02-29 20:08 ` Glenn Morris 2016-02-29 20:57 ` Drew Adams 2015-03-08 18:21 ` Daniel Colascione 2015-03-08 18:46 ` Drew Adams 2015-03-08 19:11 ` Daniel Colascione 2015-03-08 21:12 ` Drew Adams 2015-03-08 21:19 ` Daniel Colascione 2015-03-08 21:31 ` Drew Adams 2015-03-09 4:52 ` Stefan Monnier 2019-08-02 12:50 ` Lars Ingebrigtsen 2019-08-03 2:49 ` Noam Postavsky 2019-08-03 7:49 ` Štěpán Němec 2019-08-03 10:30 ` Lars Ingebrigtsen 2019-08-03 12:58 ` Noam Postavsky 2019-08-03 13:16 ` Štěpán Němec 2019-08-03 21:10 ` 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).