bug#35508: 27.0.50; Fine-ordering of functions on hooks

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> 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?

The patch includes the post-self-insert-hook example, I already mentioned
the after-change-functions example (where cc-mode wants his hook to
come before font-lock's), and I could add the case of
syntax-propertize's before-change-functions which needs to "come last".

> I agree that it's usually a bad idea, so maybe we should resist the
> temptation.

So far people haven't resisted the temptation, but have instead worked
around the lack of direct support for it, either by ad-hoc ways to
detect mis-ordering and re-set the ordering accordingly, or by hoping
for the best.

> If the worse comes to worst, a Lisp program could concoct
> the entire hook list in any order it sees fit, right?

I don't understand what you mean here.

>> +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?

Indeed.  Same for `t` not always going to the very end.

> That's backward-incompatible, no?

Sure.

> In any case, this default is insufficiently tested by the tests
> you propose.

What other tests do you suggest?

> So using 100 more than once makes the last one "win"?

Yes.  This is so that when using `t` more than once, the last one wins,
just as it used to.

>> +For backward compatibility reasons, a symbol other than nil is
>> +interpreted as a DEPTH of 90.
> This is not explicitly tested by the test.

I can a test to try and check that `90` corresponds to `t`, if you want,
although this property is trivially verified by looking at the code.
[ I tend to prefer tests that try and catch tricky interactions rather
  than straightforward bases cases.  E.g. the tests I included are the
  ones that failed during development ;-)  ]


        Stefan