Question about font-lock-compile-keywords

Question about font-lock-compile-keywords

[Drew Adams]

font-lock-compile-keywords added an optional arg for Emacs 22. It looks,
from a quick glance, as if a non-nil value for that arg gives behavior
similar to what the function did in Emacs 21 and 20.

Wouldn't it be better for the optional arg to be complemented, so that a
value of nil gave (more or less) the pre-22 behavior? Wouldn't that make
things easier for third-party libraries that call font-lock-compile-keywords
(with no second arg)?

Just a question. And again, I took only a quick look at the code, so perhaps
I'm mistaken about the behavior.

Re: Question about font-lock-compile-keywords

[Richard Stallman]

    font-lock-compile-keywords added an optional arg for Emacs 22. It looks,
    from a quick glance, as if a non-nil value for that arg gives behavior
    similar to what the function did in Emacs 21 and 20.

    Wouldn't it be better for the optional arg to be complemented, so that a
    value of nil gave (more or less) the pre-22 behavior? Wouldn't that make
    things easier for third-party libraries that call font-lock-compile-keywords
    (with no second arg)?

That seems like a good idea in principle, but which behavior do real
third-party libraries which use font-lock-compile-keywords actually
want?  (Are there really any?)

RE: Question about font-lock-compile-keywords

[Drew Adams]

        font-lock-compile-keywords added an optional arg for Emacs
        22. It looks, from a quick glance, as if a non-nil value
        for that arg gives behavior similar to what the function
        did in Emacs 21 and 20.

        Wouldn't it be better for the optional arg to be
        complemented, so that a value of nil gave (more or less)
        the pre-22 behavior? Wouldn't that make things easier for
        third-party libraries that call font-lock-compile-keywords
        (with no second arg)?

    That seems like a good idea in principle, but which behavior do real
    third-party libraries which use font-lock-compile-keywords actually
    want?  (Are there really any?)

I don't have any concrete info to help, here. I just thought it seemed a bit
backwards. More typically, optional args are added in such a way that the
nil value is more or less compatible with the previous version, without the
new arg (when feasible).

FWIW, this came up as I was trying to use, in Emacs 20, some Emacs 22 code
that called font-lock-remove-keywords. I first tried simply adding a
definition of that function, but things soon got more complex. It was in
exploring this that I discovered the new, backward-seeming arg to
font-lock-compile-keywords.

Re: Question about font-lock-compile-keywords

[Richard Stallman]

    I don't have any concrete info to help, here. I just thought it seemed a bit
    backwards. More typically, optional args are added in such a way that the
    nil value is more or less compatible with the previous version, without the
    new arg (when feasible).

The change is to handle two cases differently, which previously were
handled the same.  Either way, the new version will be compatible with
the previous version in one case, and incompatible in the other case.

RE: Question about font-lock-compile-keywords

[Drew Adams]

        I don't have any concrete info to help, here. I just
        thought it seemed a bit backwards. More typically, optional
        args are added in such a way that the nil value is more or
        less compatible with the previous version, without the
        new arg (when feasible).

    The change is to handle two cases differently, which previously were
    handled the same.  Either way, the new version will be compatible with
    the previous version in one case, and incompatible in the other case.

OK, thanks. As I said, I took only a quick look at the code, and was not
sure about the behavior.