GNU bug report logs - #35508
27.0.50; Fine-ordering of functions on hooks

Previous Next

Full log

Message #23 received at 35508 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 35508 <at> debbugs.gnu.org
Subject: Re: bug#35508: 27.0.50; Fine-ordering of functions on hooks
Date: Sat, 11 May 2019 15:05:03 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: 35508 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.