From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 35508@debbugs.gnu.org
Subject: bug#35508: 27.0.50; Fine-ordering of functions on hooks
Date: Wed, 01 May 2019 21:00:21 +0300 [thread overview]
Message-ID: <831s1iqclm.fsf@gnu.org> (raw)
In-Reply-To: <jwvwojbkz63.fsf@iro.umontreal.ca> (message from Stefan Monnier on Tue, 30 Apr 2019 16:37:08 -0400)
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 30 Apr 2019 16:37:08 -0400
>
> Occasionally it's important to control the relative ordering of
> functions on hooks. It's usually a bad idea, but sometimes alternatives
> are worse.
Could you please give a couple of examples? I agree that it's usually
a bad idea, so maybe we should resist the temptation. If the worse
comes to worst, a Lisp program could concoct the entire hook list in
any order it sees fit, right?
> +The place where the function is added depends on the DEPTH
> +parameter. DEPTH defaults to 0.
So from now on, omitting DEPTH will not necessarily put the function
at the beginning of the hook list? That's backward-incompatible, no?
In any case, this default is insufficiently tested by the tests you
propose.
> By convention, should be
> +a number between -100 and 100 where 100 means that the function
> +should be at the very end of the list, whereas -100 means that
> +the function should always come first. When two functions have
> +the same depth, the new one gets added after the old one if
> +depth is strictly positive and before otherwise.
So using 100 more than once makes the last one "win"?
> +For backward compatibility reasons, a symbol other than nil is
> +interpreted as a DEPTH of 90.
This is not explicitly tested by the test.
Thanks.
next prev parent reply other threads:[~2019-05-01 18:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-30 20:37 bug#35508: 27.0.50; Fine-ordering of functions on hooks Stefan Monnier
2019-04-30 21:37 ` Drew Adams
2019-04-30 22:31 ` Stefan Monnier
2019-05-01 18:00 ` Eli Zaretskii [this message]
2019-05-01 20:29 ` Stefan Monnier
2019-05-08 18:32 ` Stefan Monnier
2019-05-11 12:05 ` Eli Zaretskii
2019-05-11 13:26 ` Stefan Monnier
2019-05-11 13:54 ` Eli Zaretskii
2019-05-13 13:29 ` Stefan Monnier
2019-05-29 19:56 ` Stefan Monnier
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=831s1iqclm.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=35508@debbugs.gnu.org \
--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 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.