From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Matt Kramer Newsgroups: gmane.emacs.bugs Subject: bug#39564: Date: Sun, 1 Mar 2020 23:20:23 -0800 Message-ID: References: <20200211144941.godmcifegapmqg6i@Ergus> <83pndxerkg.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="27770"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 39564@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 02 08:21:22 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j8fOE-0006yJ-3S for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Mar 2020 08:21:22 +0100 Original-Received: from localhost ([::1]:55780 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j8fO2-0007vk-Sz for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 02 Mar 2020 02:21:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57608) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j8fNv-0007ve-6M for bug-gnu-emacs@gnu.org; Mon, 02 Mar 2020 02:21:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j8fNt-00059z-Ve for bug-gnu-emacs@gnu.org; Mon, 02 Mar 2020 02:21:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59477) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j8fNt-00059u-Rx for bug-gnu-emacs@gnu.org; Mon, 02 Mar 2020 02:21:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j8fNt-0002vF-Nr for bug-gnu-emacs@gnu.org; Mon, 02 Mar 2020 02:21:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Matt Kramer Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 02 Mar 2020 07:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39564 X-GNU-PR-Package: emacs Original-Received: via spool by 39564-submit@debbugs.gnu.org id=B39564.158313364311191 (code B ref 39564); Mon, 02 Mar 2020 07:21:01 +0000 Original-Received: (at 39564) by debbugs.gnu.org; 2 Mar 2020 07:20:43 +0000 Original-Received: from localhost ([127.0.0.1]:37217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j8fNb-0002uR-I5 for submit@debbugs.gnu.org; Mon, 02 Mar 2020 02:20:43 -0500 Original-Received: from mail-lf1-f50.google.com ([209.85.167.50]:44888) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j8fNY-0002u5-Lk for 39564@debbugs.gnu.org; Mon, 02 Mar 2020 02:20:42 -0500 Original-Received: by mail-lf1-f50.google.com with SMTP id 7so7080754lfz.11 for <39564@debbugs.gnu.org>; Sun, 01 Mar 2020 23:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x42uOZMUoEupsQuQUm4s2AF2k7K4DyKgXKIpJGtbhQo=; b=gIMwZGRJE7glURx9HuS1xdv49DzfIS8POtn+kHtRx/PWhBeEDusqV5y2f8bDNpSW24 fGWr4T34UPv5Y63jobOJ7qGybgv+d4qsBU4uAk+bSHX+AQ/Tb8nzWNT68cBZsV9NGo1c xY8/kbUQQsiXSwt+Yjsd0z+ImsbRoKYoLC1HbNyTrkWOYwIEyO/ia6koSohQYy/uhLuV fFypRL4vp0GE9cBT/G2oyhQ+8KOlH+4nAHsPhXRvzAJQGwcuvo6kDEkq6MgkETk5kS+l u/HrcFKCd/1d9lFVh5UX3dYdA7rKgjDJJJds43jjqTipyWeIAPzqpJF5KcTTrMmEhi9n rrSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x42uOZMUoEupsQuQUm4s2AF2k7K4DyKgXKIpJGtbhQo=; b=gxOywvkjOZeSW8Sa//4iVwhfo1Iji0evJ2vw2SwZQoJLXPuCpur7dp/VGmn730HSIM uV3GyBamsuooQZ8imZEEVMCM0xeRggWUPuZMy+ZH9yt8Z/a7eI0U0i9NLrtqW/wp3Yt5 5w2R+LZzQmqK6wl9nbjWYAK/4JikNXll7vIAJNHmK09LuRhLKPHlYB/jTIROogQtox11 34bDjaq8qAdXnySTQFGKYoQEJCnJj297KEUNjoDneusEb3CZeB2mHbiFYHn+1R6/4l4K zm9Dhw/fCjZMwljr8qL7UbUJZOLGJA3EX5pmsBn0cFjKqtM+RHQwjmWM19fsrLktqGoz UVbA== X-Gm-Message-State: ANhLgQ3Ve3p5a3TpXVwpEb+Z9L7vd8ZPmSiEFgJ0fwY7l1SN0S1/M5rm tbOwxME+D3227fSmM/gquz7+15YhhlMvpVU/eZ0= X-Google-Smtp-Source: ADFU+vuBiNzPVpeqEvt5G38jz11aS+Av+XtIoYhMElJgkEyZ5qaEBaOLPH50xrri2z3Z6/P0EdHflQirQtZwp232OQE= X-Received: by 2002:a19:2396:: with SMTP id j144mr9632376lfj.113.1583133634536; Sun, 01 Mar 2020 23:20:34 -0800 (PST) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.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-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176751 Archived-At: Followup: The regression in Ivy appears to be fixed when set-message-function is bound to nil at the top of the misbehaving function. In general, it seems like, given the new defaults defined in http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=485b423e8f0df2711a850be7f254665f64ab0bdb, it will be necessary to make a similar change to any existing function that, say, calls read-key under the assumption that the prompt will take over the mini-window. (At least when the prompt contains multiple lines). I guess that's the fundamental issue here. The new behavior may be a nice improvement, but it's unclear how much code there is out there that relies on the old behavior. (For the record, it looks like the Ivy discussion has moved to https://github.com/abo-abo/swiper/issues/2397) On Sun, Mar 1, 2020 at 2:26 PM Matt Kramer wrote: > > Thanks Eli for the explanation. Sorry for the trouble. It looks like > Ivy (at least, in ivy-dispatching-done) assumes the old behavior, to > wit, that echo-area messages will overwrite the minibuffer prompt, > leading to the regression discussed in > https://github.com/abo-abo/swiper/issues/2444. The conversation will > continue over there, I guess. > > On Sat, Feb 29, 2020 at 12:17 AM Eli Zaretskii wrote: > > > > > From: Matt Kramer > > > Date: Fri, 28 Feb 2020 09:33:57 -0800 > > > > > > Code I used: > > > > > > (defun make-lines (n) > > > (mapconcat #'number-to-string > > > (number-sequence 0 n) "\n")) > > > > > > (let ((map (make-sparse-keymap))) > > > (define-key map (kbd "C-f") (lambda () > > > (interactive) > > > (let ((inhibit-field-text-motion t)) > > > (goto-char (point-min))) > > > (message "%S" > > > (read-key > > > (concat > > > (make-lines 10) > > > "\nTest2"))) > > > (abort-recursive-edit))) > > > (read-from-minibuffer (concat (make-lines 10) "\nTest1: ") nil map)) > > > > > > With this code in the clipboard, I start emacs -Q (again, 27.0.60 > > > commit 75a9eee8b), and immediately hit the following sequence of keys: > > > > > > C-y > > > M-x eval-buffer RET > > > C-f > > > > > > The eval-buffer results are initially as expected. However, after > > > hitting C-f, the minibuffer then becomes: > > > > > > 0 > > > 1 > > > 2 > > > 3 > > > 4 > > > 5 > > > 6 > > > 7 > > > 8 > > > 9 > > > 10 > > > Test1: [0 > > > 1 > > > 2 > > > 3 > > > 4 > > > > > > with point at the very beginning of the minibuffer (first 0). > > > > Looks like the intended behavior for this code: the "[0 ..." part is > > the text of the message displayed by the command bound to C-f; it is > > enclosed in brackets to indicate that it is a message text separate > > from the rest of the prompt. This display of echo-area messages that > > attempts not to overwrite the minibuffer prompt in an active > > minibuffer is a new feature of Emacs 27. By default, Emacs will not > > let the mini-window grow enough to show the entire combined text of > > the prompt and the message, but if you set max-mini-window-height to a > > value 22 or greater, you will see this: > > > > 0 > > 1 > > 2 > > 3 > > 4 > > 5 > > 6 > > 7 > > 8 > > 9 > > 10 > > Test1: [0 > > 1 > > 2 > > 3 > > 4 > > 5 > > 6 > > 7 > > 8 > > 9 > > 10 > > Test2] > > > > which is what I would expect, given the code you presented. > > > > Going back to the original report, what is the bug here? > > > > Thanks.