[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#17146: 24.4.50; File save with incapable coding system precluded by
bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message
Mon, 31 Mar 2014 08:30:53 -0700 (PDT)
> This change is backward-incompatible, but is not in NEWS for some
> reason. Needless to say, the canonical way of fixing the fallout is
> not described in NEWS. Are functions that need Help mode supposed to
> let-bind these hooks? If so, the patch below should fix the problem.
> In any case, please document the change and the way to adapt to it in
Please see bug #17109. FWIW, this regression really bothers me.
This is not the way to make changes. It is fine to introduce and
use new macros. And it is fine to deprecate old macros in favor
of new macros or functions (which has not even been done here, AFAIK).
What is not kosher is to change the behavior of an existing macro,
so that it breaks code that uses that macro.
This comes, perhaps, from thinking that the distributed Emacs code
is the only Emacs-Lisp code, or is the only code that matters. And
that comes, perhaps, from an overemphasis on self: core developer
Such a way of thinking is completely counter to the spirit of Emacs.
The core Emacs code that Emacs Dev distributes is only that: a core.
The larger Emacs community (*users*) is not only explicity invited
and encouraged to extend such code - that is practically the core
principle of Emacs itself: user modification.
Personally, I have lots of code, in different libraries, that uses
`with-output-to-temp-buffer', and that needs to work across
multiple Emacs versions. This incompatible change would
considerably complicate such code - for no good reason. Even if
I am the only one to use this macro (which I doubt), this is not a
reasonable change, IMO.
I really hope that someone DTRT here.