From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.bugs Subject: bug#21396: 25.0.50; read-key's prompt is not visible Date: Fri, 04 Sep 2015 11:27:30 +0200 Message-ID: <87vbbq356l.fsf@gnu.org> References: <87wpw91h2k.fsf@gnu.org> <87egifgzog.fsf@gnu.org> <83d1xz9xjz.fsf@gnu.org> <87zj13fipu.fsf@gnu.org> <834mjaaduo.fsf@gnu.org> <874mja4nm0.fsf@gnu.org> <831teea8ah.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441358903 12898 80.91.229.3 (4 Sep 2015 09:28:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 4 Sep 2015 09:28:23 +0000 (UTC) Cc: 21396@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 04 11:28:11 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZXnI2-0000Y8-He for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Sep 2015 11:28:10 +0200 Original-Received: from localhost ([::1]:57365 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXnI1-0001tq-Qu for geb-bug-gnu-emacs@m.gmane.org; Fri, 04 Sep 2015 05:28:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57132) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXnHy-0001tU-5R for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 05:28:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXnHu-0003AY-VH for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 05:28:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXnHu-0003AU-Rl for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 05:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZXnHu-0006p2-Iv for bug-gnu-emacs@gnu.org; Fri, 04 Sep 2015 05:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Tassilo Horn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Sep 2015 09:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 21396 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 21396-submit@debbugs.gnu.org id=B21396.144135885726189 (code B ref 21396); Fri, 04 Sep 2015 09:28:02 +0000 Original-Received: (at 21396) by debbugs.gnu.org; 4 Sep 2015 09:27:37 +0000 Original-Received: from localhost ([127.0.0.1]:48499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXnHV-0006oL-2L for submit@debbugs.gnu.org; Fri, 04 Sep 2015 05:27:37 -0400 Original-Received: from out2-smtp.messagingengine.com ([66.111.4.26]:46092) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZXnHS-0006oC-6v for 21396@debbugs.gnu.org; Fri, 04 Sep 2015 05:27:35 -0400 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id C7FA120755 for <21396@debbugs.gnu.org>; Fri, 4 Sep 2015 05:27:33 -0400 (EDT) Original-Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Fri, 04 Sep 2015 05:27:33 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=TmKVFWSFt37nmkwYuw0+/3WfXZE=; b=P5Kj6 +G1V+DuCrfZH3+NdjFS1QpFDbHF5U768KYlSHnHcy6JxY7LcgRm5j50cILDHBuyL bk0OuKFy36hxMT1yZ/U8MoZapHu1t/JUzTyXeM5J64ME5uoUg7nXiIkI0RktIuHC 8vJTYdQo1oSMlsz7qt3CdLuwHunNn29K4Kn/CA= X-Sasl-enc: HYbpXewt9OL0UwZki9CgwOj8Qx4joqPXnGGqrPtbH1nR 1441358853 Original-Received: from thinkpad-t440p (unknown [2.163.8.69]) by mail.messagingengine.com (Postfix) with ESMTPA id B81BAC0028D; Fri, 4 Sep 2015 05:27:32 -0400 (EDT) In-Reply-To: <831teea8ah.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 04 Sep 2015 11:38:30 +0300") User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/25.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106146 Archived-At: Eli Zaretskii writes: >> Redefining functions is the worst of all customization possibilities, >> of course, but what is the reason that the above cannot be expected >> to continue working? > > Supporting this is maintenance burden that we shouldn't be expected to > sustain. When I'm working on extending a function, how am I supposed > to know that it's defaliased by someone? If I need to extend the > function to make it incompatible with these tricks, it's a legitimate > development that shouldn't be avoided for fear of breaking someone's > fset. You cannot and should not! I am fully aware that I won't benefit from your extensions to `yes-or-no-p' when I do the above fset. But for a function with no side-effects and such a sharp contract as "ask the user for confirmation and return non-nil if she's fine", I don't see a practical problem anyway. Again, the current issue was that `read-key' (and therefore `y-or-n-p') didn't show its prompt anymore. That was a real regression, not a change which had the side-effect of breaking the fset "trick." Stefan fixed it not in order to restore compatibility with tricks but because `read-key' didn't satisfy the contract of its docstring anymore. > If people keep using such "customizations", it's a clear sign that > some defcustom or another similar facility is missing, or that the > original code needs improvement. So when such situations happen, > let's report them to the bug tracker, and let's handle them as we > usually do. I'm all in favour of having a `user-confirmation-function', and/or a more sensible use of `yes-or-no-p'/`y-or-n-p' inside emacs (use the former only when the consequences of a wrong answer are really severe), or something else. The problem is that it'll take long until all emacs packages follow suit, and frequently having to type 2 or 3 chars + RET instead of just one is something which is cumbersome enough to me and many others as it seems. Bye, Tassilo