Re: [PATCH 0/7] Cleanups and tests for DEFVAR_PER_BUFFER variables

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

>> BTW, we may also want to try and increase the proportion of those vars
>> which don't have a global default (i.e. look at which variables fall
>> into this camp and that can be changed without too much trouble).
> I would have investigated this,

I think we'd want to do things one step at a time, tho, so better
concentrate on what you have now.

> but I don't know to what extent we try to provide
> backwards-compatibility for this kind of thing.

We very much want to preserve backwards-compatibility.

> If it doesn't break any of the tests, is it probably fine?

No, that's definitely not sufficient.

> Or if we're concerned about breaking third-party packages, how can one
> judge the risk of that?

Searching through uses of the variable in the packages we can find (GNU
ELPA and MELPA are good starting points).  It's hard work and often
results in concluding that it's too risky.  Tho often those problems can
be seen much earlier, luckily.

Better is to find some way to make the change gradually or to first
install changes that detect when the code exploits the "to be old"
behavior and emit messages warning about such a use.

It's can be a long process.

> If we could get rid of defaults from most of the variables, we could
> just convert the rest into regular buffer-local variables and then
> remove support for defaults in DEFVAR_PER_BUFFER entirely, which would
> be a big simplification (and performance improvement).  But of course
> this depends on how many variables can have their defaults removed -
> since converting a variable into a regular buffer-local variable will
> make its performance worse for sure.

Indeed, that's also my hope.  I don't know how realistic it is, OTOH.


        Stefan