RE: changing function signatures and no library version # => must use too-general test

[Drew Adams]

    > Yes, I agree with everything you said. It doesn't change the general
    > problem, however. Rather than users needing to define their
    own function
    > that does what you wrote above (if case they want to do that
    in multiple
    > places, for instance), Emacs developers should just define a
    new, different
    > function themselves (not pour new wine into old bottles).

    I don't know specifically what happened with
    help-insert-xref-button, but
    it's prety common to change a function's list of arguments without
    subsantially changing its body and/or its conceptual meaning,
    in which case
    it will usually makes more sense to keep the same name.

Too bad for Emacs users. No, I don't see how that usually makes more sense,
whether it is common or not. Especially in the case of a non-interactive
function that has not particularly been advertised (e.g. in the Emacs-Lisp
manual), to me it makes more sense to change the function name when the
signature changes that much. (Simply adding parameters is of course not a
problem, if &optional or &rest is used to maintain backward compatibility.)

    Some functions are known to be "exported"

I don't know what you mean here. Do you mean documented in the manual?

    in which case we have to be
    careful, which is already a pain in the _|_ at times, but if we start to
    have to be careful like that with each and every function, it's
    going to be *really* annoying.

Annoyance to developers is important, but it is not as important as clean
software and clear software maintenance. Some developers have always felt
that the effort required to be user-friendly was simply a pain in the _|_
and a waste of their time and creativity. Most, fortunately, out-grow that,
or they learn better from being also users or maintainers of code written by
others.

Take me back a few decades, when writing clear code and commenting it was
considered, well wimpy. I knew a Lisp programmer who never, ever used any
whitespace that was not syntactically significant - tons of code in one long
line (no exaggeration). His personal shortcuts weren't limited to saving
whitespace (which could have been gotten around by pretty-printing). He was
brilliant and Lisp was about his only mode of thought, but his code was
considered strictly personal - no one wanted to try to modify, reuse, or
understand it.

To him it was "pretty common" to save time and space in his own way and it
would have been "*really* annoying" to write code that something other than
a Lisp machine or byte-compiler could read. He was, yes, very fast and very
good. He and his code just didn't play well with others.

    Next time around you'll come and complain that Emacs-22.1
    defined foo-titi
    and when its interface was changed in Emacs-22.4 the name was changed to
    foo-toto, and when the interface was changed yet again in
    Emacs-23.1 the name
    was changed to foo-titi ('cause the coder didn't know that name
    had already
    been in use a few years back), so now you again have no way to
    tell whether
    foo-titi uses the Emacs-22.1 or the Emacs-23.1 convention.

That would still be one problem less. That is, the same problem might
conceivably resurface, as you point out, but only in a much more limited and
less likely situation.

As far as I can see, you've simply pointed out an additional (unlikely)
problem to be tackled, not an argument for the status quo.

My general point is that Emacs users, more than users of other applications
(non-free and perhaps even other free applications), also read and reuse
Emacs source code. Keeping an eye out for how users might be affected by
source-code changes would be a *good thing*. I know the stock answer is that
Emacs developers don't care about backward compatibility, but some Emacs
users do: users who develop external libraries.

Do those users matter to Emacs development? Should you care about them? Put
it another way: How many useful Emacs features were imported from code
written originally by users as external libraries?