[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35508: 27.0.50; Fine-ordering of functions on hooks
From: |
Eli Zaretskii |
Subject: |
bug#35508: 27.0.50; Fine-ordering of functions on hooks |
Date: |
Sat, 11 May 2019 15:05:03 +0300 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 35508@debbugs.gnu.org
> Date: Wed, 08 May 2019 14:32:43 -0400
>
> I updated the patch so we use it for syntax-propertize's
> before-change-functions as well as a comment showing where we'd use it
> in cc-mode (using it in CC-mode would take more work in order to make
> sure it doesn't break on older Emacsen).
>
> >> 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.
>
> [ Still don't understand. ]
>
> >> That's backward-incompatible, no?
> > Sure.
>
> I added a note in the "incompatible changes" section of NEWS.
>
> >> In any case, this default is insufficiently tested by the tests
> >> you propose.
> > What other tests do you suggest?
>
> I added a test to make sure nil is treated like 0.
>
> >> 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 added a test to make sure t is treated like 90.
>
> Other objections?
Thanks. Should we perhaps change 100 to 110 and 90 to 100? And
perhaps not document the 110 value? Just a thought.
No other objections.