bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

[Drew Adams]

> > > 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.
> 
> I read the mailing list, so I'm perfectly aware of that bug and the
> related discussions.  Please don't hijack this bug to hold it hostage
> to that one.  This bug is about a related issue, but one thing it is
> _not_ about is reverting the change in question.  So talking here
> instead of on #17109 is not useful.

It is now two months later, the 24.4 pretest is out, and there still
has been no follow-up for this "related-issue" bug - or for #17109,
for that matter.  I was hoping to get some guidance from the fix for
#17146, at least.

I am still left wondering (a) whether there is an intention
to fix what has been broken for Emacs 24.4, and (b) if not, how
I will need to go about fixing the damage myself locally.

See also bug #17397, which I filed recently.  Help commands
(seemingly because they now use only `with-help-window') no longer
invoke `temp-buffer-show-hook', and this breaks quite a bit for me
(whether I use one of my own help commands or a vanilla one).

The Lisp manual has still not been updated to reflect all of the
changes, AFAICT.  It still says clearly, for instance, that
`with-output-to-temp-buffer' switches to Help mode, which it
does *not* (bug #17109):

  "Unlike `with-output-to-temp-buffer', however, it
   [`with-temp-buffer-window'] does not automatically switch
   that buffer to Help mode."

And this text was updated for release 24.4 to add the word
"automatically", so presumably someone also paid some attention
to its continued claim regarding `with-output-to-temp-buffer'.

So ... product bug or doc bug?  How to know?  AFAIK, there was
never any emacs-devel proposal discussed about changing the
behavior in this regard - so maybe a product bug.  But then again,
AFAIK none of the changed "related-issue" behaviors were proposed
and discussed either, and at least some of those changes have
since been defended as not-gonna-revert - so maybe a doc bug.

Although I still hope for a fix to bug #17109 that reverts the
changes to `with-output-to-temp-buffer' which effectively neuter
it, I have nevertheless changed my code (and it is quite a lot)
to use `with-help-window' instead of `with-output-to-temp-buffer'
- to try to adapt to the incompatible changes introduced.

(This is actually a bit of a mess because the code in question
needs to use one or the other of these macros, depending on the
Emacs version.  Both macros exist also for previous versions,
but with different behaviors, etc.  Pretty ugly.)

Should I also be adding explicit calls to run
`temp-buffer-show-hook' here and there, in help commands?
If so, what about the vanilla Emacs help commands?  Can't a
user expect her `temp-buffer-show-hook' functions to continue
to be invoked by help commands?

The doc string for `with-help-window' sends you off to the
one for `with-temp-buffer-window', and that doc says that it
runs `temp-buffer-window-show-hook' (not `temp-buffer-show-hook').
Should I be adding my function(s) to that `window' hook also?
(But only for the latest release and future, presumably.)

The Elisp manual for `with-help-window' says that it "evaluates
BODY like `with-output-to-temp-buffer'."  Does that imply that
it runs `temp-buffer-show-hook'?  Not clear - "evaluates like"
is pretty vague.  Vague is probably OK if the behavior is really
the same, but if there are differences then it is not sufficient.
Not running the hook would be a difference worth mentioning, IMO.

(The changing and growing plethora of similar-sounding macros
and hooks is all a bit mind-boggling...)

What is the suggested way, or a suggested way, to deal with this
incompatible change (or these incompatible changes, depending on
how you want to look at it)?  I really would like to know.

It is not clear to me what the policy is now, or even whether
Nathan's bug #17146 and related bugs will be closed as "notabug"
or will eventually be fixed.  So far, they are still open, but
there are plenty of bugs that have languished for years, so
that alone doesn't inspire much hope.

Hoping for some guidance, information.

bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

[Eli Zaretskii]

> Date: Sun, 4 May 2014 19:01:34 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: nbtrap@nbtrap.com, 17146@debbugs.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.
> > 
> > I read the mailing list, so I'm perfectly aware of that bug and the
> > related discussions.  Please don't hijack this bug to hold it hostage
> > to that one.  This bug is about a related issue, but one thing it is
> > _not_ about is reverting the change in question.  So talking here
> > instead of on #17109 is not useful.
> 
> It is now two months later, the 24.4 pretest is out, and there still
> has been no follow-up for this "related-issue" bug - or for #17109,
> for that matter.  I was hoping to get some guidance from the fix for
> #17146, at least.

#17146 (this bug) is no longer present in the current pretest.  So I'm
going to mark this bug "done".

> I am still left wondering (a) whether there is an intention
> to fix what has been broken for Emacs 24.4, and (b) if not, how
> I will need to go about fixing the damage myself locally.
> 
> See also bug #17397, which I filed recently.  Help commands
> (seemingly because they now use only `with-help-window') no longer
> invoke `temp-buffer-show-hook', and this breaks quite a bit for me
> (whether I use one of my own help commands or a vanilla one).
> 
> The Lisp manual has still not been updated to reflect all of the
> changes, AFAICT.  It still says clearly, for instance, that
> `with-output-to-temp-buffer' switches to Help mode, which it
> does *not* (bug #17109):
> 
>   "Unlike `with-output-to-temp-buffer', however, it
>    [`with-temp-buffer-window'] does not automatically switch
>    that buffer to Help mode."
> 
> And this text was updated for release 24.4 to add the word
> "automatically", so presumably someone also paid some attention
> to its continued claim regarding `with-output-to-temp-buffer'.

This part of the discussion should probably be elsewhere, maybe in
#17109, maybe in a separate bug report (with new details about the
signs of damage you see in your code).

bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

[Nathan Trapuzzano]

On trunk:

emacs -nw -q file.txt
M-: (insert "μ\xc1")
C-x C-s

This throws a "make-text-button" error "Unknown button type
`help-xref'".  And it doesn't save.  I believe it should ask which
coding system I want to use to write to disk.

bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

[Eli Zaretskii]

> From: Nathan Trapuzzano <nbtrap@nbtrap.com>
> Date: Sun, 30 Mar 2014 21:52:13 -0400
> 
> On trunk:
> 
> emacs -nw -q file.txt
> M-: (insert "μ\xc1")
> C-x C-s
> 
> This throws a "make-text-button" error "Unknown button type
> `help-xref'".  And it doesn't save.  I believe it should ask which
> coding system I want to use to write to disk.

(The -nw part is not needed to reproduce the problem.)

This is because of this commit:

  ------------------------------------------------------------
  revno: 116839
  fixes bug: http://debbugs.gnu.org/16038
  committer: Leo Liu <sdl.web@gmail.com>
  branch nick: trunk
  timestamp: Sat 2014-03-22 08:13:46 +0000
  message:
    * help.el (temp-buffer-setup-hook): Remove help-mode-setup.
    (temp-buffer-show-hook): Remove help-mode-finish.

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.

--- lisp/international/mule-cmds.el~	2014-01-01 10:46:07 +0200
+++ lisp/international/mule-cmds.el	2014-03-31 08:53:35 +0300
@@ -703,6 +703,8 @@
 
   (let ((window-configuration (current-window-configuration))
 	(bufname (buffer-name))
+	(temp-buffer-setup-hook 'help-mode-setup)
+	(temp-buffer-show-hook 'help-mode-finish)
 	coding-system)
     (save-excursion
       ;; If some defaults are unsafe, make sure the offending

bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

[Drew Adams]

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

bug#17146: 24.4.50; File save with incapable coding system precluded by strange error message

[Eli Zaretskii]

> Date: Mon, 31 Mar 2014 08:30:53 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 17146@debbugs.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.

I read the mailing list, so I'm perfectly aware of that bug and the
related discussions.  Please don't hijack this bug to hold it hostage
to that one.  This bug is about a related issue, but one thing it is
_not_ about is reverting the change in question.  So talking here
instead of on #17109 is not useful.