unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Michael Heerdegen <michael_heerdegen@web.de>
Cc: "Gerd Möllmann" <gerd.moellmann@gmail.com>,
	"brandon.irizarry@gmail.com" <brandon.irizarry@gmail.com>,
	"Eli Zaretskii" <eliz@gnu.org>,
	"65344@debbugs.gnu.org" <65344@debbugs.gnu.org>
Subject: bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring
Date: Sat, 26 Aug 2023 02:02:02 +0000	[thread overview]
Message-ID: <SJ0PR10MB548848C02C22A5E2BD72EE50F3E2A@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87sf868xq5.fsf@web.de>

> > OK, so you don't see a problem.  Do you see
> > a reason why we would add some `cl-foobar' to
> > `cl-lib.el', if it's a function that has no
> > relation to Common Lisp?  Does it make any
> > sense to you that someone might expect it to
> > be housed elsewhere, with a different prefix
> > (or with no prefix)?
> >
> > That's all I'm trying to say here.  Let's avoid
> > stuffing non-CL stuff in `cl*.el' files.  Is it
> > necessary to clean house wholesale, moving and
> > renaming things to fix this mixup?  No.  I'm
> > not proposing disruption or extra work - just a
> > recognition of a will to avoid adding not CL
> > stuff to `cl*.el' files and giving it prefix
> > `cl-'.  Nothing revolutionary or heavy-handed
> > intended.
> 
> Sorry about mentioning flet again, but it's a good example to discuss.
> Would you want that we have cl-flet, which is an restricted version
> of the current implementation, and cl-flet*, which is like the current
> cl-flet?  Or two constructs with non-overlapping semantics?  Or was
> extending cl-flet as had been done ok for you?

I have nothing to say about `flet', `cl-flet', or `cl-flet*'.  I'm pretty ignorant of all that.

> Your suggestion sounds logical and objective, but what has "a relation to
> CL" or is "not CL" is a bit subjective, it is an individual decision
> where to draw the line.  I mean, anyone could agree with your claim but
> some may still come to other decision than you would expect.

Judgment calls, yes.  Especially if trying not
to be black-&-white, given where things are at
(not starting from scratch).  A judgment call,
but it need not be only up to an individual.
No different from having and following other
conventions, we have - e.g., wrt coding style.

Wrt any concrete change, there would presumably
be some discussion, with those closer to things
likely weighing in with more authority.

I'm only saying that AFAIK there hasn't been any
such attempt to avoid putting extraneous stuff
in `cl*.el'.  I've brought up the question in
the past wrt specific things (don't recall what),
but it wasn't thought to be important to keep
`cl-' for CL.  That approach/attitude tends to
lead to more such mix-up, not less.

It's not about perfection.  It's about having a
will/goal not to add unrelated stuff to `cl*.el'.

Not such a big deal or so hard to grasp, I think.
And doesn't require everyone to agree about each
detail.  It's about a general wish/commitment to
aim to have `cl*.el' for CL stuff.





  reply	other threads:[~2023-08-26  2:02 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-16 18:21 bug#65344: 28.2; Unable to Edebug cl-flet form which uses argument destructuring Brandon Irizarry
2023-08-17  0:55 ` Michael Heerdegen
2023-08-17  5:29 ` Gerd Möllmann
2023-08-17 15:42   ` Brandon Irizarry
2023-08-17 15:56     ` Eli Zaretskii
2023-08-17 18:23     ` Gerd Möllmann
2023-08-17 23:07       ` Michael Heerdegen
2023-08-18  5:19         ` Gerd Möllmann
2023-08-18  5:58           ` Michael Heerdegen
2023-08-18  6:43             ` Gerd Möllmann
2023-08-19  8:08               ` Gerd Möllmann
2023-08-20  3:57                 ` Michael Heerdegen
2023-08-20  5:32                   ` Gerd Möllmann
2023-08-20  6:08                     ` Michael Heerdegen
2023-08-20  6:48                       ` Gerd Möllmann
2023-08-21  1:19                         ` Michael Heerdegen
2023-08-21  7:01                           ` Gerd Möllmann
2023-08-21  7:10                             ` Gerd Möllmann
2023-08-21  7:30                               ` Gerd Möllmann
2023-08-22  0:54                                 ` Michael Heerdegen
2023-08-22  5:48                                   ` Gerd Möllmann
2023-08-22  6:10                                     ` Michael Heerdegen
2023-08-22  8:05                                       ` Gerd Möllmann
2023-08-22 21:06                                         ` Brandon Irizarry
2023-08-23  0:35                                           ` Michael Heerdegen
2023-08-23  0:32                                         ` Michael Heerdegen
2023-08-23  1:25                                           ` Drew Adams
2023-08-23  6:06                                             ` Gerd Möllmann
2023-08-23 14:23                                               ` Drew Adams
2023-08-24  3:16                                                 ` Michael Heerdegen
2023-08-24  9:10                                                 ` Gerd Möllmann
2023-08-24 23:04                                                   ` Michael Heerdegen
2023-08-25  1:53                                                     ` Drew Adams
2023-08-25  4:07                                                       ` Michael Heerdegen
2023-08-25 14:50                                                         ` Drew Adams
2023-08-26  0:16                                                           ` Michael Heerdegen
2023-08-26  2:02                                                             ` Drew Adams [this message]
2023-08-20  4:39                 ` Michael Heerdegen
2023-08-20  5:15                   ` Gerd Möllmann
2023-08-23  9:25 ` Mattias Engdegård
2023-08-23  9:31   ` Mattias Engdegård
2023-08-23 11:10     ` Gerd Möllmann
2023-08-23 14:08       ` Gerd Möllmann
2023-08-24  1:14         ` Michael Heerdegen
2023-08-24  6:17           ` Gerd Möllmann
2023-08-25  4:10             ` Michael Heerdegen
2023-08-25  6:19               ` Gerd Möllmann
2023-08-25  4:22             ` Michael Heerdegen
2023-08-25  6:33               ` Gerd Möllmann
2023-08-25 17:53                 ` Michael Heerdegen
2023-08-26  5:39                   ` Gerd Möllmann
2023-08-27  4:02                     ` Michael Heerdegen
2023-08-27  6:34                       ` Gerd Möllmann
2023-09-01 23:24         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-02  5:10           ` Gerd Möllmann
2023-09-02 17:04             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-02 19:27               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-03  5:51                 ` Gerd Möllmann
2023-09-03 16:09                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-03 16:47                     ` Gerd Möllmann
2023-09-04 21:14                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-23  9:33   ` Gerd Möllmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB548848C02C22A5E2BD72EE50F3E2A@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=65344@debbugs.gnu.org \
    --cc=brandon.irizarry@gmail.com \
    --cc=eliz@gnu.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=michael_heerdegen@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).