unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>,
	Michael Heerdegen <michael_heerdegen@web.de>
Cc: Daniel Mendler <mail@daniel-mendler.de>,
	"47992@debbugs.gnu.org" <47992@debbugs.gnu.org>,
	"monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>,
	"jakanakaevangeli@chiru.no" <jakanakaevangeli@chiru.no>
Subject: bug#47992: [External] : bug#47992: 27; 28; Phase out use of `equal` in `add-hook`, `remove-hook`
Date: Sun, 4 Jul 2021 17:08:00 +0000	[thread overview]
Message-ID: <SA2PR10MB4474644DFC651647CCCA1D92F31D9@SA2PR10MB4474.namprd10.prod.outlook.com> (raw)
In-Reply-To: <87r1ge42wk.fsf@gnus.org>

> > But what advantage would these offer,
> > compared to standard naming?
> 
> By "standard naming" you mean "define a function,
> and then use it in `add-hook'?"  Experience shows
> that people avoid doing so (for various reason),
> so creating a new form to cater to this use case
> makes sense.

FWIW, I disagree.  There's no real need for such
a "new form".

I think the use case you've imagined for it is a
s t r e t c h .  Users will just as likely avoid
making any of your new forms as they avoid named
functions now.

The "various reasons" amount to laziness (which
is often the right approach), and that will be
the same reason for not naming lambdas in the
new way you envision.  There's a reason lambdas
are anonymous functions.

Here's maybe another hint that it isn't needed:
Has anyone ever requested such a feature?

And if there really were such a need, you could
just check for non-nil `eq'uality of a lambda's
doc string, instead of adding yet another "new
form" that will likely ~never be used.

And even that feature - using a doc string with
a lambda - is rarely used.  As the doc string
of `lambda' itself says:

   But documentation strings are usually not
   useful in nameless functions.

Let's not add another ~useless "new form" for
lambdas.  They already have a doc string, which
I'm guessing is as much a name as what you have
in mind.

If you really want to test with `eq', just use
`eq' together with function `documentation'.

That'll save you implementing the same kind of
thing for yet another "name".  Same test: (1)
are both "names" present (non-nil), and (2) if
if so, are they `eq'?

And the same problem will persist: few will
ever bother to provide such a "name", even if
it might help them with `add|remove-hook'.

You have a solution in search of a problem, I
think.  Users just learn the hard way (but the
doc of `add|remove-hook' could be improved to
help them learn) that they don't want to use
lambdas as hook functions.





  reply	other threads:[~2021-07-04 17:08 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-24 12:11 bug#47992: 27; 28; Phase out use of `equal` in `add-hook`, `remove-hook` Daniel Mendler
2021-04-24 20:12 ` bug#47992: [External] : " Drew Adams
2021-04-24 20:23   ` Daniel Mendler
2021-04-24 21:20     ` Drew Adams
2021-04-24 21:34       ` Daniel Mendler
2021-04-24 22:30   ` Stefan Monnier
2021-04-24 22:38     ` Daniel Mendler
2021-04-24 23:04       ` Stefan Monnier
2021-04-24 23:38         ` Daniel Mendler
2021-04-25  1:16         ` Drew Adams
2021-04-25  3:08           ` Stefan Monnier
2021-04-25  4:57             ` Drew Adams
2021-04-25 13:52               ` Stefan Monnier
2021-04-25  1:16       ` Drew Adams
2021-04-25  1:23     ` Drew Adams
2021-04-25  3:10       ` Stefan Monnier
2021-04-25  4:57         ` Drew Adams
2021-04-25 10:33           ` Daniel Mendler
2021-04-25 13:56           ` Stefan Monnier
2021-05-02  9:09 ` Lars Ingebrigtsen
2021-05-02 10:37   ` Daniel Mendler
2021-05-03  8:50     ` Lars Ingebrigtsen
2021-07-06 14:44     ` Olivier Certner
     [not found]   ` <877di6udfy.fsf@web.de>
2021-07-04  1:09     ` Lars Ingebrigtsen
2021-07-04  2:35       ` Michael Heerdegen
2021-07-04  2:56         ` Lars Ingebrigtsen
2021-07-04  4:28           ` Michael Heerdegen
2021-07-04 13:36             ` Lars Ingebrigtsen
2021-07-04 17:08               ` Drew Adams [this message]
2021-07-04 22:45                 ` bug#47992: [External] : " Michael Heerdegen
2021-07-05 12:39                 ` Lars Ingebrigtsen
2021-07-06  1:48             ` Richard Stallman
2021-07-06  2:37               ` bug#47992: [External] : " Drew Adams
2021-07-06  3:21                 ` Michael Heerdegen
2021-07-07 23:57                 ` Richard Stallman
2021-07-06  9:46               ` Arthur Miller
2021-07-07 23:57                 ` Richard Stallman
2021-07-08  2:11                   ` Arthur Miller
2021-07-04 23:15       ` Michael Heerdegen

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=SA2PR10MB4474644DFC651647CCCA1D92F31D9@SA2PR10MB4474.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=47992@debbugs.gnu.org \
    --cc=jakanakaevangeli@chiru.no \
    --cc=larsi@gnus.org \
    --cc=mail@daniel-mendler.de \
    --cc=michael_heerdegen@web.de \
    --cc=monnier@iro.umontreal.ca \
    /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).