Re: 23.0.60; M-x compile gives args out of range 0, 0

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

>> I disagree.  A major mode should basically *never* change globally
>> a defvar, except maybe for its own vars (plus a few exceptions, of
>> course).

> Well, that's a bit philosophical.  In practice, major mode maintainers
> _will_ be setting such variables without explicitly localising them,
> causing just that little bit extra in debugging, stress, curse words,
> and so on.

It's not philosophical.  It's simply needed so as to avoid undesired
interference between unrelated buffers.  I know it's a common bug.

> There's a category of variables which are _essentially_ buffer local, and
> nobody ever explicitly localises them first - things like major-mode,
> mark-ring, foo-minor-mode, buffer-undo-list, .....

It's hard to clearly define which ones are "essentially" buffer local
and which ones aren't.

> fl-e-ac-rf is in this category.

In my mind, it's definitely not in the same category as `major-mode' or
`buffer-undo-list'.  But it doesn't matter anyway.

> There are several other variables in font-lock.el which are explicity
> buffer-localised, amongst them the similar variable
> font-lock-extend-region-functions.  So it would promote consistency if we
> did the same with fl-extend-ac-region-function.

As I said:

>> I'm not opposed to make-variable-buffer-local,

So feel free to apply your patch (except for the part that changes the
docstring, since C-h v will take care of warning the user that the
variable is automatically made buffer-local).

>> but the bug was clearly in CC-mode, because a major mode should by
>> default use (set (make-local-variable ...) ...) rather than setq.

> I don't think it's clear at all.  The same "bug", if such it be, exists
> in font-lock.el itself, L1452:

>         (setq font-lock-syntactically-fontified end))

As I said "If you happen to know that the variable is "automatically
buffer-local", it's OK to use `setq'".

>> BTW, why doesn't CC-mode set those vars via font-lock-defaults, as the
>> author of font-lock intended?

> For portability's sake.  font-lock-defaults in XEmacs has a different
> format.  In particular, it lacks the "other-vars" bit at the end.  It's
> less hassle just not to use it.

Duh!


        Stefan