all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Eli Zaretskii <eliz@gnu.org>, Nathan Trapuzzano <nbtrap@nbtrap.com>
Cc: 17146@debbugs.gnu.org
Subject: bug#17146: 24.4.50; File save with incapable coding system precluded by strange error	message
Date: Mon, 31 Mar 2014 08:30:53 -0700 (PDT)	[thread overview]
Message-ID: <aa071e4a-793d-4035-9d7e-04c07955b130@default> (raw)
In-Reply-To: <83lhvqcsb3.fsf@gnu.org>

> 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
> NEWS.

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
vs users/lusers.

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.





  reply	other threads:[~2014-03-31 15:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-31  1:52 bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message Nathan Trapuzzano
2014-03-31 15:16 ` Eli Zaretskii
2014-03-31 15:30   ` Drew Adams [this message]
2014-03-31 15:54     ` Eli Zaretskii
     [not found] <<87ha6fyw1e.fsf@nbtrap.com>
     [not found] ` <<83lhvqcsb3.fsf@gnu.org>
     [not found]   ` <<aa071e4a-793d-4035-9d7e-04c07955b130@default>
     [not found]     ` <<83ha6ecqj3.fsf@gnu.org>
2014-05-05  2:01       ` Drew Adams
2014-05-05  6:20         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aa071e4a-793d-4035-9d7e-04c07955b130@default \
    --to=drew.adams@oracle.com \
    --cc=17146@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=nbtrap@nbtrap.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.