From debbugs-submit-bounces@debbugs.gnu.org Thu Mar 21 15:19:36 2019 Received: (at submit) by debbugs.gnu.org; 21 Mar 2019 19:19:36 +0000 Received: from localhost ([127.0.0.1]:53601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h73Dz-0006ql-7Q for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:19:36 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40496) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h738D-0006gs-76 for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:13:38 -0400 Received: from lists.gnu.org ([209.51.188.17]:55338) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h7387-00027E-VV for submit@debbugs.gnu.org; Thu, 21 Mar 2019 15:13:32 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54865) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7386-0007n1-81 for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 15:13:31 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h7384-00024L-RG for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 15:13:30 -0400 Received: from forward400p.mail.yandex.net ([2a02:6b8:0:1472:2741:0:8b7:105]:34637) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h7384-00020p-0U for bug-gnu-emacs@gnu.org; Thu, 21 Mar 2019 15:13:28 -0400 Received: from mxback1g.mail.yandex.net (mxback1g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:162]) by forward400p.mail.yandex.net (Yandex) with ESMTP id C2E0E1BC154B for ; Thu, 21 Mar 2019 22:13:22 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback1g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id d1daoU1yHv-DL4e8jo1; Thu, 21 Mar 2019 22:13:22 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1553195602; bh=3IhdfI8Vd3kCrCDMFltlnhwZWx8Gb26KvwjC4rVbwFA=; h=Message-Id:Date:Subject:To:From; b=K4SY2Jg6dr1md0ZFPrIRWiD7U+qbdiTA5nKNAcEI5tOfDCoPnxL56hk8RNmhyonfz LrqidoQSZ+yiUFy0dgU88j151tlHEUDN/xX2cznVo4NpCQmTW/+nXIvFNt9oGzScd4 ZMhco7z5POFYw7RRC/ZQOVJOy5Yeft8qbGvS1jKM= Authentication-Results: mxback1g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt3-2475c4d2af83.qloud-c.yandex.net with HTTP; Thu, 21 Mar 2019 22:13:21 +0300 From: pinkanon pinkanon Envelope-From: pinkanon-pinkanon@yandex.ru To: bug-gnu-emacs@gnu.org Subject: Some minibuffer behaviour is annoying MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 21 Mar 2019 21:13:21 +0200 Message-Id: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a02:6b8:0:1472:2741:0:8b7:105 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 21 Mar 2019 15:19:34 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Hi! I have two issues regarding minibuffer usage: (1) when I press backspace and the prompt is empty, minibuffer tells me "Text is read-only". You. Don't. Say. Proposed solution: while it can be argued that this is an OK default, it would be great to have an option to show nothing instead. (2) When I try to quit and some buffer is unchanged, I get the usual deal asking me what I want. The problem I have here [in addition to the problem discussed in (1), adapted to this case: "Type C-h for help."] is that I must use C-g, but not good old escape. Proposed solution: make [an option to be able to] ESC any minibuffer prompt. In this particular case, maybe ESC could be added to one of the possible response options, but that's an implementation detail as far as I am concerned, a regular user. Here are some other people trying to solve this problem with no luck. https://superuser.com/questions/795763/how-to-make-emacs-quit-the-minibuffer-with-one-press-of-esc I come from Vim background and these problems make Emacs look sluggish to me. I really hope for a solution. Thank you. Best, Pink Anon. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 22 12:57:23 2019 Received: (at 34939) by debbugs.gnu.org; 22 Mar 2019 16:57:23 +0000 Received: from localhost ([127.0.0.1]:54625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7NTv-0000oL-4m for submit@debbugs.gnu.org; Fri, 22 Mar 2019 12:57:23 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:37462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7NTt-0000o4-0W for 34939@debbugs.gnu.org; Fri, 22 Mar 2019 12:57:21 -0400 Received: by mail-wr1-f48.google.com with SMTP id w10so3138938wrm.4 for <34939@debbugs.gnu.org>; Fri, 22 Mar 2019 09:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=evIUbRT+ZwGUooKIjBvtcsASwxtvjzK2ckeKsjm5OKI=; b=fZDqfJuUZ8wko+bnN8WMFJ+JQBLdEr6fTBv5lvh9GN2Fp7qLM1htgopaMH3EJIfHkY 75ehUiGSluPcod5i1vbaFAN9cHCihv5apzVf2kpxpsogGvsF/PXrYZDGYRRAT+LQ96FW PE49F/oJMAenAjsO57OGwKCb7Gigb/DYof0mCA5aY3iNqAsx86VuWgCAPzXFxZnDwQas Ujv0/2QVwKGLcRXww7Zy/C/rM3YdDw3hl2l3s+pzTZpw5K653fA5A8g6T/4afx9RGSEC +DVs5qQOGvJigcXtRw8iCgWuLQDPujrrhmKLIpOFTiaxPtwi5H2h+/wfHWkohG+OnvMe bd0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=evIUbRT+ZwGUooKIjBvtcsASwxtvjzK2ckeKsjm5OKI=; b=k36l/agBPkIiyjeIiVNtxVTxAxBTtW7ENHN/xfbEQHSebnZsAbOb1WwDowV7TfMxA0 2o6N0iCPh/E9rVIq2cEJEES9UWSeHoz7Qvi4z6A9JMT/X2nEbajof2Nmqk+q6I9kFQbc GVkt0ydcFTxJ2abzF2Kfl78eotVRP6mcbfx3UxwCe27NYZKw1C/cEYbYXdJZJFew1hG7 pK8BrH2q5w0cndoK3wydm4SSDt8jxmCGhvv5QnMUAEISJknVwJccw9PCts7/PcHdDIFY pHyN/SAs7bn1QJ00UjOTP3pLH9aCo87P+L7rflC48jxR2eLefpCJV/ag0+UQXV1Z44qB V41A== X-Gm-Message-State: APjAAAU7L3NFGqqSlDKZOxpkuaBAOqb9vyEYTR2ZNNdpn5G/tgkfyudY vAL2WxccIyhA/JhRlbxbshacaIQe X-Google-Smtp-Source: APXvYqzbgP5kXVjmJBsTZht0LNyoD7PyKfmyWo4YkH501bYgxCcESJm+Taf8sBjyqk5RIAA6z45+Dw== X-Received: by 2002:a5d:6b05:: with SMTP id v5mr1296355wrw.314.1553273834866; Fri, 22 Mar 2019 09:57:14 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id b3sm10411040wmj.15.2019.03.22.09.57.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Mar 2019 09:57:14 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: pinkanon pinkanon , 34939@debbugs.gnu.org References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> From: Dmitry Gutov Message-ID: <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> Date: Fri, 22 Mar 2019 18:57:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 34939 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 21.03.2019 21:13, pinkanon pinkanon wrote: > Hi! I have two issues regarding minibuffer usage: > > (1) when I press backspace and the prompt is empty, minibuffer tells me > "Text is read-only". You. Don't. Say. Agreed. > Proposed solution: while it can be argued that this is an OK default, > it would be great to have an option to show nothing instead. As a "solution", patch would be better. Off the top of my head, I don't see a simple fix while the prompt is still implemented using the read-only text property. > (2) When I try to quit and some buffer is unchanged, I get the usual > deal asking me what I want. The problem I have here [in addition to > the problem discussed in (1), adapted to this case: "Type C-h for > help."] is that I must use C-g, but not good old escape. > > Proposed solution: make [an option to be able to] ESC any minibuffer > prompt. In this particular case, maybe ESC could be added to one of > the possible response options, but that's an implementation detail as > far as I am concerned, a regular user. > > Here are some other people trying to solve this problem with no luck. > https://superuser.com/questions/795763/how-to-make-emacs-quit-the-minibuffer-with-one-press-of-esc Probably no simple way to make ESC work that way. The answer gives a hint why. But you could go the ergoemacs way, I guess. From debbugs-submit-bounces@debbugs.gnu.org Fri Mar 22 22:32:18 2019 Received: (at 34939) by debbugs.gnu.org; 23 Mar 2019 02:32:18 +0000 Received: from localhost ([127.0.0.1]:54865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7WSI-0000HF-B1 for submit@debbugs.gnu.org; Fri, 22 Mar 2019 22:32:18 -0400 Received: from eggs.gnu.org ([209.51.188.92]:49898) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7WSG-0000Gz-EX for 34939@debbugs.gnu.org; Fri, 22 Mar 2019 22:32:16 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:55996) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7WS9-000369-P1; Fri, 22 Mar 2019 22:32:10 -0400 Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1h7WS7-0005Cr-9k; Fri, 22 Mar 2019 22:32:07 -0400 Content-Type: text/plain; charset=Utf-8 From: Richard Stallman To: Dmitry Gutov In-Reply-To: <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> (message from Dmitry Gutov on Fri, 22 Mar 2019 18:57:12 +0200) Subject: Re: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> Message-Id: Date: Fri, 22 Mar 2019 22:32:07 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: rms@gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > > (1) when I press backspace and the prompt is empty, minibuffer tells me > > "Text is read-only". You. Don't. Say. > Agreed. This error message may be surprising, but it is not actually wrong. The minibuffer prompt is text in the minibiffer. You can move point through it. Kill commands will not delete it, but they will put it in the kill ring. We could add special-case code to handle that specific case differently, perhaps with a different error message that won't seem strange. -- Dr Richard Stallman President, Free Software Foundation (https://gnu.org, https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 23 05:46:52 2019 Received: (at 34939) by debbugs.gnu.org; 23 Mar 2019 09:46:52 +0000 Received: from localhost ([127.0.0.1]:55017 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7dEp-0004Sd-RQ for submit@debbugs.gnu.org; Sat, 23 Mar 2019 05:46:52 -0400 Received: from mail-lj1-f169.google.com ([209.85.208.169]:32842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7dEm-0004SP-Ne for 34939@debbugs.gnu.org; Sat, 23 Mar 2019 05:46:49 -0400 Received: by mail-lj1-f169.google.com with SMTP id f23so4001079ljc.0 for <34939@debbugs.gnu.org>; Sat, 23 Mar 2019 02:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=d79VEoMDU1hpcS6tO75bcM08Sd61iQmHTZ+9OKmfflY=; b=MS4wuk2yTN2jWhWboTV5cbAsez82o2IGKOMc5SCy0+m5uzaz9/bYstvgDM6ZTZsdN8 rzBTih+OUNuTsxy7+lwTTIxeBSf9ra7XBr00MQjFIw3OnUp9/tSqSUhYl7uD+mLOFlyr 11CtmvcndtNwcWIoeTCpj8xDaF8cpd5fH0McBK1+Hft1i2EBjx0ZHY70tYYMeQUZGewk o6ujJFnvIt+/JNHJH7VrLKAoKv4fWZ58Y9Sn7Hqdx1g8b7hKn3TMULg0YwSA886bcsPf cyBl/xxszzY4dl3z4qPtBeQTTM1wZCuPBaCXfB7tK9MnNXgA0/r7dJCZVJo+bVXS7HGx fBeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=d79VEoMDU1hpcS6tO75bcM08Sd61iQmHTZ+9OKmfflY=; b=NniZfso8AeQPM7CNSKSEmbjGIV6Pgz+ibd4Na0uyHsr0DYH+J6QZMVvZVr1wtuX118 gD+NzXeZwLJBmHHKlEuUfgicaF0ZRPPvJdbp/EcXb2wvwFKb5chXsEUtEfqkRg15KZpB 21x8L3E933dKrQmGBfYOTfv2TaQ48aZuBNNXCREAq5geMndxMxs3/AO+gd2D6u6f8u3T dk1KCBX217QiTvgAMV1FY5bVU4s7aBZKnIJPEzwbr3wndq1zjbRcHSZ+/4rT6Z/Mp+lH wi6PR+Cx2W039mv2ELE3eVy2FD8bk+CIUXUrAUL+AyYe6UpyXKA7yGln+NZ3uejgk4dk Qq+g== X-Gm-Message-State: APjAAAX5x0v9IqHPSKpDixV6Lqw3Ki8Ds4PuA2bikqX0u5EeaHIgF9d8 bTMQPsh/5MX+bw/T0f7biY/qagmJ X-Google-Smtp-Source: APXvYqwoVhsLvmDhe8j8b60K8vWzTW1KAlQRlC/kPZ0IZJAE8M4ElTpn5Atc8EYBr9qx0n3r4Sxm7A== X-Received: by 2002:a2e:7215:: with SMTP id n21mr8231682ljc.105.1553334402472; Sat, 23 Mar 2019 02:46:42 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id q26sm2505444lfd.27.2019.03.23.02.46.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 02:46:41 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: rms@gnu.org References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> From: Dmitry Gutov Message-ID: <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru> Date: Sat, 23 Mar 2019 11:46:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 23.03.2019 4:32, Richard Stallman wrote: > This error message may be surprising, but it is not actually wrong. This is true, but... > We could add special-case code to handle that specific case differently, > perhaps with a different error message that won't seem strange. The error message is annoying because I only ever try to delete the prompt by mistake. And when it's shows, I simply have to wait the second or so for it to go away and to see the minibuffer again (patiently staying away from C-g). So I'd rather there was no error message. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 23 05:50:22 2019 Received: (at 34939) by debbugs.gnu.org; 23 Mar 2019 09:50:22 +0000 Received: from localhost ([127.0.0.1]:55021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7dIE-0004Xu-DX for submit@debbugs.gnu.org; Sat, 23 Mar 2019 05:50:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:37394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7dIB-0004Xf-KM for 34939@debbugs.gnu.org; Sat, 23 Mar 2019 05:50:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:60810) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h7dI5-0000KV-T5; Sat, 23 Mar 2019 05:50:13 -0400 Received: from [176.228.60.248] (port=2616 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1h7dHu-0003Cu-5n; Sat, 23 Mar 2019 05:50:02 -0400 Date: Sat, 23 Mar 2019 11:50:00 +0200 Message-Id: <83o961q5rr.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-reply-to: <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru> (message from Dmitry Gutov on Sat, 23 Mar 2019 11:46:38 +0200) Subject: Re: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org, rms@gnu.org, pinkanon.pinkanon@yandex.ru X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > From: Dmitry Gutov > Date: Sat, 23 Mar 2019 11:46:38 +0200 > Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org > > And when it's shows, I simply have to wait the second or so for it to go > away and to see the minibuffer again (patiently staying away from C-g). Doesn't some innocent key, like the right arrow, end the wait immediately? From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 23 07:24:20 2019 Received: (at 34939) by debbugs.gnu.org; 23 Mar 2019 11:24:20 +0000 Received: from localhost ([127.0.0.1]:55032 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7elA-0006ra-IC for submit@debbugs.gnu.org; Sat, 23 Mar 2019 07:24:20 -0400 Received: from mail-lj1-f173.google.com ([209.85.208.173]:38256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7el8-0006rM-7F for 34939@debbugs.gnu.org; Sat, 23 Mar 2019 07:24:18 -0400 Received: by mail-lj1-f173.google.com with SMTP id p14so3116087ljg.5 for <34939@debbugs.gnu.org>; Sat, 23 Mar 2019 04:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=b0qONf8LPzQ1u7kqVMCuHT22EsOrPjG0MqLcGOcr2IE=; b=cVGqZO27vWENsmq/Fsc09J+xzEreHjTIU28hhEcBJws7SRkpm3VKkfyAkGR+BANN0k bkIjkqsh7KFatzBEN+L0IUNPsLDIq3wLTRkc/deWEWcFnKB+Rr8bDhsZf3rlYp7Yw4YT ive/MB5uttJBChOW45YsoIo+ZP+nRKCQsIZJzvGOMxDEivPM8FkSyoquIqhhaDYoMFkP CAOE28baT7CaCY4i7GxnT2G9kw8EYXqFp4VJnmG9CzpufxFAYsGqK5v3F6WskglVoU4M BiuBmTDpPIqkT+UEXOA+Xy7MVSKp1vVy6rKwcrT/zFLPrg0zyGWhK19wE/W5SilBD0d2 Qvug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=b0qONf8LPzQ1u7kqVMCuHT22EsOrPjG0MqLcGOcr2IE=; b=ZG2vg7B5mdDf2u0YFrXQINKjINnsiTnfjFlvx45rHkojwC6riyySvfGfmZgT0cq/yD O4MZftnoB12iDFoe/2rHyIXS+vmJgoCMccm+pcTkgh0LlJCAmq5sC4IbQCsoHh+Lut18 VuNI6fyu6gWnVzY6RSb9jcvrRkjVv63SjZnxJAXprPQVJivX1OIGztMpiS+RwuTQk1m0 4e6u9MdvyeWsPSOBZDA2cOQC/fJJrUKJk/xmqmUxvZgXsHcR40Idc3Bjp3PLXumU6lSU k5KsTx4WGGgg9vBGt+XRbBUM9NMCI/z6USWNhPYaodf8pPXnw9qCH46+cindoLU0hYs7 aP0A== X-Gm-Message-State: APjAAAV36FMIkSAdRugzqBROKtqLHM0sfMrVCtOHz+/b1CUl6nulWiI3 dNAJcEN79FBsoPMyWtogCVA= X-Google-Smtp-Source: APXvYqyNhrNBCAZN6XV6DNxsaITL227fETNf0higf3urDSLA6J6NfwTDjqXZsp52t95ceSuwTkPQyQ== X-Received: by 2002:a2e:895a:: with SMTP id b26mr7595940ljk.89.1553340252020; Sat, 23 Mar 2019 04:24:12 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id z15sm376103ljz.55.2019.03.23.04.24.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 04:24:10 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Eli Zaretskii References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru> <83o961q5rr.fsf@gnu.org> From: Dmitry Gutov Message-ID: <27dac6a0-03d1-1e5c-4f98-65388464b344@yandex.ru> Date: Sat, 23 Mar 2019 13:24:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <83o961q5rr.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On 23.03.2019 11:50, Eli Zaretskii wrote: >> From: Dmitry Gutov >> Date: Sat, 23 Mar 2019 11:46:38 +0200 >> Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org >> >> And when it's shows, I simply [...] Content analysis details: (1.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: yandex.ru] 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.208.173 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (dgutov[at]yandex.ru) 0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom freemail headers are different 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: 34939 Cc: pinkanon.pinkanon@yandex.ru, rms@gnu.org, 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 23.03.2019 11:50, Eli Zaretskii wrote: >> From: Dmitry Gutov >> Date: Sat, 23 Mar 2019 11:46:38 +0200 >> Cc: pinkanon.pinkanon@yandex.ru, 34939@debbugs.gnu.org >> >> And when it's shows, I simply have to wait the second or so for it to go >> away and to see the minibuffer again (patiently staying away from C-g). > > Doesn't some innocent key, like the right arrow, end the wait > immediately? First, even if it worked, it would be a workaround. New users hitting the "is read-only" problem would continue to do so. Second, is just a likely to hit me with the "End of buffer" error message instead. Also useless, by the way. I'd rather the minibuffer didn't show either error, especially because it gets concealed by the echo area. From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 23 11:52:14 2019 Received: (at 34939) by debbugs.gnu.org; 23 Mar 2019 15:52:14 +0000 Received: from localhost ([127.0.0.1]:55696 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7iwP-00073p-U4 for submit@debbugs.gnu.org; Sat, 23 Mar 2019 11:52:14 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:55686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7iwO-00073c-8n for 34939@debbugs.gnu.org; Sat, 23 Mar 2019 11:52:12 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2NFmup2139771; Sat, 23 Mar 2019 15:52:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Udg+ufRk0cqZduxCGrAHUKuyRTxtfGJi2ccVxJfqIo8=; b=KSjse9MmSLrIIsRBAlrPNV4rgWo1oVbFlWfIRIZZNzPns8o7fhwNgFIMXr+mgYJz2CDu SOkMLsExI/bedr/fWIyoL17M8TIx9hoDj9qG6OExDpcjVF0YlRWDdQESfgtbSNnP+UCw /ELkG68QoBlxTlnn0WvKkIRd6Ck+0gwbn/0aftri6Mk8AtMRFmB3/RzV4FFaWgn1enOz Dj0CliA3wa+xpiOr8St9ksYyZu7nIgWyrLIFjHZqIeheI5PLE6aRTm7UMReb20hL2FFB XMs7AtLTgvMoIOuDoNE9KZlrtzNM+qwd2oI5RUZUxBsXmtN3YX5229aGcnMBquwwxX8f zQ== Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp2130.oracle.com with ESMTP id 2rdnky05ta-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 23 Mar 2019 15:52:05 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id x2NFq064010797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 23 Mar 2019 15:52:00 GMT Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x2NFpxLI027900; Sat, 23 Mar 2019 15:51:59 GMT MIME-Version: 1.0 Message-ID: Date: Sat, 23 Mar 2019 08:51:58 -0700 (PDT) From: Drew Adams To: Eli Zaretskii , Dmitry Gutov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <<1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru>> <<83o961q5rr.fsf@gnu.org>> In-Reply-To: <<83o961q5rr.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4822.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9204 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=926 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903230121 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: pinkanon.pinkanon@yandex.ru, rms@gnu.org, 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > And when it's shows, I simply have to wait the second or so for it to g= o > > away and to see the minibuffer again (patiently staying away from C-g). >=20 > Doesn't some innocent key, like the right arrow, end the wait > immediately? I've wondered from time to time how we might unobtrusively let more users know whenever a message to the echo area would be removed upon a user action. E.g., `sit-for' behavior (not `sleep-for') is invisible and unknown to many users. That's generally as it should be (unobtrusive), but I've still wondered if there isn't some subtle way to indicate to observant users that Emacs is waiting only passively, i.e., in an easily interruptible way. A tiny indication in the mode line or the echo area perhaps? Something (e.g. one char) that at least some users might notice, wonder about, and investigate to find out that what it indicates. Kind of like the mode-line indications of current status (CS:CH:FR) that many users learn about (but perhaps many users never bother to find out about). Probably the echo area would be the right place for this, perhaps as a prefix? Maybe one or two chars such as "| ". (Or perhaps there's an emoticon char that signifies something relevant?) From debbugs-submit-bounces@debbugs.gnu.org Sat Mar 23 11:53:35 2019 Received: (at 34939) by debbugs.gnu.org; 23 Mar 2019 15:53:36 +0000 Received: from localhost ([127.0.0.1]:55699 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7ixi-00075m-Ce for submit@debbugs.gnu.org; Sat, 23 Mar 2019 11:53:35 -0400 Received: from forward100o.mail.yandex.net ([37.140.190.180]:54721) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h7fc8-0001kP-Qf for 34939@debbugs.gnu.org; Sat, 23 Mar 2019 08:19:06 -0400 Received: from mxback7g.mail.yandex.net (mxback7g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:168]) by forward100o.mail.yandex.net (Yandex) with ESMTP id B1C994AC1722; Sat, 23 Mar 2019 15:18:58 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback7g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id cTtDcMtqBQ-IvXGqGpa; Sat, 23 Mar 2019 15:18:57 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1553343537; bh=8zAlTFukPfcnuTOLVgqOGPIerfV/DREHW3+030ULDlI=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=LbrhxXrSMK1oEQNh0x8OOnsFkLGhclRYc2sMwHSEJUeaxcyTw3abFWn2FdwBGQEi8 CHg6q70e5gx8ZRedtoRUCREUNA/BsLrriJSjGn6Tk2tGNnFpz42cvisWaCT1YOE8Vt pAhvL/lSWVzXqv8pPWMRc/TqMEdEgO1Sl+Q2lIcs= Authentication-Results: mxback7g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas2-985f744271ca.qloud-c.yandex.net with HTTP; Sat, 23 Mar 2019 15:18:57 +0300 From: pinkanon pinkanon Envelope-From: pinkanon-pinkanon@yandex.ru To: Dmitry Gutov , Eli Zaretskii In-Reply-To: <27dac6a0-03d1-1e5c-4f98-65388464b344@yandex.ru> References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru> <83o961q5rr.fsf@gnu.org> <27dac6a0-03d1-1e5c-4f98-65388464b344@yandex.ru> Subject: Re: bug#34939: Some minibuffer behaviour is annoying MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sat, 23 Mar 2019 14:18:57 +0200 Message-Id: <1190951553343537@sas2-985f744271ca.qloud-c.yandex.net> Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34939 X-Mailman-Approved-At: Sat, 23 Mar 2019 11:53:32 -0400 Cc: "34939@debbugs.gnu.org" <34939@debbugs.gnu.org>, "rms@gnu.org" X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > We could add special-case code to handle that specific case differently, perhaps with a different error message that won't seem strange. Just to clarify myself. I didn't mean that the error message was strange. The fact that the message pops up at all is my concern. It's maybe is OK for newcomers, but an option to not show - not to give any textual feedback - is what I had in mind. > > Here are some other people trying to solve this problem with no luck. > > https://superuser.com/questions/795763/how-to-make-emacs-quit-the-minibuffer-with-one-press-of-esc > Probably no simple way to make ESC work that way. The answer gives a > hint why. But you could go the ergoemacs way, I guess. Hmmm, no easy way to replace C-g... could it be made possible to let the user slip in a custom key+function pair into the response option stack "(y, n, !, ., q, C-r, d or C-h)"? From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 31 16:16:03 2019 Received: (at 34939) by debbugs.gnu.org; 31 Mar 2019 20:16:03 +0000 Received: from localhost ([127.0.0.1]:38501 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAgs6-0003N5-MT for submit@debbugs.gnu.org; Sun, 31 Mar 2019 16:16:02 -0400 Received: from insect.birch.relay.mailchannels.net ([23.83.209.93]:46018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAgs4-0003MT-9l for 34939@debbugs.gnu.org; Sun, 31 Mar 2019 16:16:01 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 963405C4B96; Sun, 31 Mar 2019 20:15:58 +0000 (UTC) Received: from pdx1-sub0-mail-a74.g.dreamhost.com (unknown [100.96.20.50]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 4E7CD5C4B30; Sun, 31 Mar 2019 20:15:58 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a74.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 31 Mar 2019 20:15:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Average-Desert: 58d1cff4233a1b61_1554063358444_3092895436 X-MC-Loop-Signature: 1554063358444:4156647308 X-MC-Ingress-Time: 1554063358444 Received: from pdx1-sub0-mail-a74.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTP id ED4CD82D1A; Sun, 31 Mar 2019 13:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=3FbfayEX34dPzCyae0MiWLBlH9M=; b= D4+4TQxGL+3huX1H7y11IuuPneYnI/0GXEz9BiZ91SVCwhyoIQERhOUEYp9bH8Aw Ep6tAJB6EQXhYFicLpsrcPlR4QOxKx3sLNDecJdPnpOjlQO0odry4w0WkS/MPcE+ 8+mN4Tl4pvAp8OjVrN+aF2dA769T0sL0jQZsB3pT3E8= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 407F982D2A; Sun, 31 Mar 2019 13:15:55 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a74 From: Juri Linkov To: pinkanon pinkanon Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> Date: Sun, 31 Mar 2019 22:49:51 +0300 In-Reply-To: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> (pinkanon pinkanon's message of "Thu, 21 Mar 2019 21:13:21 +0200") Message-ID: <87a7hasuz4.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrledvgddugeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdelledrvddtvdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdelledrvddtvddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehpihhnkhgrnhhonhdrphhinhhkrghnohhnseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > (1) when I press backspace and the prompt is empty, minibuffer tells me > "Text is read-only". You. Don't. Say. Messages in the echo area should not conceal the minibuffer. Period. There is a special function minibuffer-message for this purpose: (add-hook 'minibuffer-setup-hook (lambda () (setq-local command-error-function (lambda (error context _command) (minibuffer-message (concat context (get (car error) 'error-message))))))) > (2) When I try to quit and some buffer is unchanged, I get the usual > deal asking me what I want. The problem I have here [in addition to > the problem discussed in (1), adapted to this case: "Type C-h for > help."] is that I must use C-g, but not good old escape. To avoid all such problems, just bind keyboard-escape-quit globally when not on a tty where an ESC prefix still might be needed: (when window-system (define-key global-map [escape] 'keyboard-escape-quit)) From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 31 16:16:11 2019 Received: (at 34939) by debbugs.gnu.org; 31 Mar 2019 20:16:11 +0000 Received: from localhost ([127.0.0.1]:38504 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAgsF-0003NX-0O for submit@debbugs.gnu.org; Sun, 31 Mar 2019 16:16:11 -0400 Received: from bonobo.maple.relay.mailchannels.net ([23.83.214.22]:19942) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAgsC-0003NL-9r for 34939@debbugs.gnu.org; Sun, 31 Mar 2019 16:16:09 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3665C5C4B96; Sun, 31 Mar 2019 20:16:06 +0000 (UTC) Received: from pdx1-sub0-mail-a74.g.dreamhost.com (unknown [100.96.20.50]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5FDEF5C52AC; Sun, 31 Mar 2019 20:16:05 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a74.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 31 Mar 2019 20:16:06 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Chemical-Robust: 4d5e430d6a13b1a5_1554063366050_4166920341 X-MC-Loop-Signature: 1554063366050:3411597165 X-MC-Ingress-Time: 1554063366050 Received: from pdx1-sub0-mail-a74.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTP id 1DCDE82D2B; Sun, 31 Mar 2019 13:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=3rVBh1 dUJPt6RmoStSo5JBQiZ1U=; b=Ovq1I4CP6/ndp+DCFJsNzDWtQWmEpOb0fpPtDT gXjKvPXHJEI1LxFlIjgfBEduq/ME8iOOJpb4TRav9sJY8Mqkfypa9yk20qAFONie 5HNbLYtqZ8+BMpb7/+p8A1tbf3Ch7m8fGKphtKA1SqlV8lnfRWtCgVJPKAQnlm/9 GZzCY= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 7418E82D2A; Sun, 31 Mar 2019 13:16:02 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a74 From: Juri Linkov To: Drew Adams Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <0b53220d-e11f-f0a7-5ed0-33ebc0c251b6@yandex.ru> <3928775d-74bf-1d42-3a30-a8bfc6036dd5@yandex.ru>> <83o961q5rr.fsf@gnu.org>> Date: Sun, 31 Mar 2019 22:50:32 +0300 In-Reply-To: (Drew Adams's message of "Sat, 23 Mar 2019 08:51:58 -0700 (PDT)") Message-ID: <87zhpargdj.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrledvgddugeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughrvgifrdgruggrmhhssehorhgrtghlvgdrtghomhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > (Or perhaps there's an emoticon char that signifies something relevant?= ) =F0=9F=91=8D From debbugs-submit-bounces@debbugs.gnu.org Sun Mar 31 16:30:35 2019 Received: (at 34939) by debbugs.gnu.org; 31 Mar 2019 20:30:35 +0000 Received: from localhost ([127.0.0.1]:38517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAh6B-0003mK-3e for submit@debbugs.gnu.org; Sun, 31 Mar 2019 16:30:35 -0400 Received: from eastern.maple.relay.mailchannels.net ([23.83.214.55]:4556) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAh68-0003mB-Jx for 34939@debbugs.gnu.org; Sun, 31 Mar 2019 16:30:33 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 730C25E1B8E; Sun, 31 Mar 2019 20:30:30 +0000 (UTC) Received: from pdx1-sub0-mail-a74.g.dreamhost.com (100-96-6-76.trex.outbound.svc.cluster.local [100.96.6.76]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B69985E1B6F; Sun, 31 Mar 2019 20:30:29 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a74.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 31 Mar 2019 20:30:30 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Wide-Eyed-Fearful: 25de28ce6202afd9_1554064230134_1043169119 X-MC-Loop-Signature: 1554064230134:945011632 X-MC-Ingress-Time: 1554064230133 Received: from pdx1-sub0-mail-a74.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTP id 5062A82D2E; Sun, 31 Mar 2019 13:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=tf1tkH6XP1elMfqh/pxulpAHeb0=; b= yIa2Dkp8fKkbvhfh6w1LTkAE+gFu57XtMSd77z7SSAMW9uSIXieRBQA6bX78zLAv ZG7uFgeWuJXlbK7NNULdpxre2K3uKEXlXP9OS00tsZbR2rmDWhmD0A0UDrXRQVBy +1+n2n5iB2fkR+DSpjj/ktN+z74L/P4UpnaSVlSYItU= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 0446A82D22; Sun, 31 Mar 2019 13:30:21 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a74 From: Juri Linkov To: pinkanon pinkanon Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> Date: Sun, 31 Mar 2019 23:29:11 +0300 In-Reply-To: <87a7hasuz4.fsf@mail.linkov.net> (Juri Linkov's message of "Sun, 31 Mar 2019 22:49:51 +0300") Message-ID: <87sgv2pz3c.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrledvgdduheduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdelledrvddtvdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdelledrvddtvddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopehpihhnkhgrnhhonhdrphhinhhkrghnohhnseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> (1) when I press backspace and the prompt is empty, minibuffer tells me >> "Text is read-only". You. Don't. Say. > > Messages in the echo area should not conceal the minibuffer. Period. > > There is a special function minibuffer-message for this purpose: There is another place where messages conceal the minibuffer: running a version-control command that asks for a branch name and typing TAB for completion runs a command to fetch branch names. Its output conceals the minibuffer when vc-command-messages is non-nil. Here is a fix: diff --git a/lisp/vc/vc-dispatcher.el b/lisp/vc/vc-dispatcher.el index edbb83f3df..c4b327a3f0 100644 --- a/lisp/vc/vc-dispatcher.el +++ b/lisp/vc/vc-dispatcher.el @@ -324,7 +324,8 @@ vc-do-command (apply 'start-file-process command (current-buffer) command squeezed)))) (when vc-command-messages - (message "Running in background: %s" full-command)) + (let ((inhibit-message (eq (selected-window) (active-minibuffer-window)))) + (message "Running in background: %s" full-command))) ;; Get rid of the default message insertion, in case we don't ;; set a sentinel explicitly. (set-process-sentinel proc #'ignore) @@ -332,11 +333,13 @@ vc-do-command (setq status proc) (when vc-command-messages (vc-run-delayed - (let ((message-truncate-lines t)) + (let ((message-truncate-lines t) + (inhibit-message (eq (selected-window) (active-minibuffer-window)))) (message "Done in background: %s" full-command))))) ;; Run synchronously (when vc-command-messages - (message "Running in foreground: %s" full-command)) + (let ((inhibit-message (eq (selected-window) (active-minibuffer-window)))) + (message "Running in foreground: %s" full-command))) (let ((buffer-undo-list t)) (setq status (apply 'process-file command nil t nil squeezed))) (when (and (not (eq t okstatus)) @@ -350,7 +353,8 @@ vc-do-command (if (integerp status) (format "status %d" status) status) full-command)) (when vc-command-messages - (message "Done (status=%d): %s" status full-command)))) + (let ((inhibit-message (eq (selected-window) (active-minibuffer-window)))) + (message "Done (status=%d): %s" status full-command))))) (vc-run-delayed (run-hook-with-args 'vc-post-command-functions command file-or-list flags)) From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 06:11:01 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 10:11:01 +0000 Received: from localhost ([127.0.0.1]:38861 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAtu9-0000Lr-80 for submit@debbugs.gnu.org; Mon, 01 Apr 2019 06:11:01 -0400 Received: from forward501o.mail.yandex.net ([37.140.190.203]:56592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAtu6-0000Lb-LE for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 06:11:00 -0400 Received: from mxback8g.mail.yandex.net (mxback8g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:169]) by forward501o.mail.yandex.net (Yandex) with ESMTP id 794321E80191; Mon, 1 Apr 2019 13:10:51 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback8g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id m99B5E9gWR-AovGiRO6; Mon, 01 Apr 2019 13:10:50 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1554113450; bh=gdd1HoYUpKGQP+67hR4E+ryJjFiPO8yaRCcb6mD5zkc=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=CURpMSxHvwq4yyRHEwcHkRazq/pxDW/ozWNnOBCx8taddZyFsKL3HJQRqw2Bi0xlu 1v9QsO7DHCBoj/fIV1xSKjE4QVCI3PQTve21z5RH1mcATOrrBbA1JBcC7Q+umYTPzA jyturEJHqskZulI9AnZgEtcW4SDvp3ZtfGhe9pvs= Authentication-Results: mxback8g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by myt6-add70abb4f02.qloud-c.yandex.net with HTTP; Mon, 01 Apr 2019 13:10:50 +0300 From: pinkanon pinkanon Envelope-From: pinkanon-pinkanon@yandex.ru To: Juri Linkov In-Reply-To: <87a7hasuz4.fsf@mail.linkov.net> References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> Subject: Re: bug#34939: Some minibuffer behaviour is annoying MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Mon, 01 Apr 2019 13:10:50 +0300 Message-Id: <26451261554113450@myt6-add70abb4f02.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34939 Cc: "34939@debbugs.gnu.org" <34939@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) 31.03.2019, 23:16, "Juri Linkov" : > Messages in the echo area should not conceal the minibuffer. Period. > > There is a special function minibuffer-message for this purpose: > >   (add-hook 'minibuffer-setup-hook >             (lambda () >               (setq-local command-error-function >                           (lambda (error context _command) >                             (minibuffer-message >                              (concat context (get (car error) >                                                   'error-message))))))) > This does the job! Thank you, Juri. >>  (2) When I try to quit and some buffer is unchanged, I get the usual >>  deal asking me what I want. The problem I have here [in addition to >>  the problem discussed in (1), adapted to this case: "Type C-h for >>  help."] is that I must use C-g, but not good old escape. > > To avoid all such problems, just bind keyboard-escape-quit globally > when not on a tty where an ESC prefix still might be needed: > >   (when window-system >     (define-key global-map [escape] 'keyboard-escape-quit)) I have no luck w/ this one, though. Emacs 26.1 build 1, Arch Linux. steps: emacs -Q somefile -> Eval the code -> type something -> C-x C-c -> "Save file...? ..." -> Escape -> "Type C-h for help" From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 09:03:56 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 13:03:56 +0000 Received: from localhost ([127.0.0.1]:38922 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAwbT-0006rH-Re for submit@debbugs.gnu.org; Mon, 01 Apr 2019 09:03:56 -0400 Received: from mail-lf1-f43.google.com ([209.85.167.43]:39231) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAwbR-0006r3-Ao for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 09:03:54 -0400 Received: by mail-lf1-f43.google.com with SMTP id m13so6224853lfb.6 for <34939@debbugs.gnu.org>; Mon, 01 Apr 2019 06:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=N1vj076y+iCpMByUZ/Q69+yh3AxmjRPage3d/WI0A3w=; b=hc3a77dV9Y4HdeX2N7wywUvBHlYSoguIHnbyDz2mZ/g7t326TCDEpHfSh3PfQfbpqq YlnTeUZTKOaZMlNnshfZ2Hl1ArltrOUyK4dB0Xab7k79hCpFkJnluZYYyeG9S749RbL9 Y3DkY5pdPFCn8/g4P4S1ZcyJ8CJmLwVsFOjxC7TzQq7kpxwKUOYO79Xfs6Ig9/Kq9EPe ekooScO6wxIEpxZawKCBv+AFXxH5bcETmJOEMlhLchw7KN95iYWMiLbpmMia4tZJwPSR 5qhig1n16QdXQl2km2pxrboBU1zASpGhch31b/je++W6mkp1Ph65hCe28C4bfishtqXO S8vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=N1vj076y+iCpMByUZ/Q69+yh3AxmjRPage3d/WI0A3w=; b=eyZpbiKg/bRX5D6QrJMCKcy/RZy5gzxYjKUdApkgRBMFZ0xj8Zc+rhW97Rj/aZ9B/W R2VpNvdcLazrRUqTK+v2nueAXHeXStOFG+RtrV0dOQlMgNAVpuNqnJAOvn4JqpvFBCLQ rtYeRT6WOVAHnZbMrUeYmJrllCWvxAFDntssFUr6AoLA+NKixn1234xSRNz9C+FFruTG zX1keLsErMP3iBoNxOc5PyfPgrBrGErZpUMM2czY4KCabGP1+3JvbHRgV+D678Sba8r0 ym950mVcqT6GtTRm//MUHA/HWKcpEZnUvqN4AsLWu+FCEKUYE0ekH12jP67rzFYjLfkD AANA== X-Gm-Message-State: APjAAAUKBdZ6SS9UqQ6Q8WwliLYTwkmoudNkMBetpQbHOLXv9nyddNQ1 vS3fasm/ATgXZrroFD9rJ3Caq4/K X-Google-Smtp-Source: APXvYqzOG2wPqb2UM2LoRSEaCHvrlc7zg8dRVJDgf0HDHmpxQPiWpOBegawUzSyzFDccgQYn30PGZA== X-Received: by 2002:a19:ae11:: with SMTP id f17mr34074047lfc.12.1554123826938; Mon, 01 Apr 2019 06:03:46 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id l15sm2102203ljh.62.2019.04.01.06.03.44 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 06:03:45 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov , pinkanon pinkanon References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Mon, 1 Apr 2019 16:03:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Thunderbird/66.0 MIME-Version: 1.0 In-Reply-To: <87a7hasuz4.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 31.03.2019 22:49, Juri Linkov wrote: > Messages in the echo area should not conceal the minibuffer. Period. > > There is a special function minibuffer-message for this purpose: Shouldn't we make this behavior the default, then? From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 09:08:51 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 13:08:51 +0000 Received: from localhost ([127.0.0.1]:38926 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAwgF-0006yM-Gi for submit@debbugs.gnu.org; Mon, 01 Apr 2019 09:08:51 -0400 Received: from mail-lf1-f54.google.com ([209.85.167.54]:39782) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hAwgD-0006y5-Ux for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 09:08:50 -0400 Received: by mail-lf1-f54.google.com with SMTP id m13so6238032lfb.6 for <34939@debbugs.gnu.org>; Mon, 01 Apr 2019 06:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jjEY2X1jxUumc1U1a7zkHFAIgkkW0hD0gfjDlnse8B4=; b=MNwPMq6/yc9jh8y//6FO9tu73zjbHOeP/XIVj8ZoXnBpOM6lqSBHK0oIr2NPAcFzQL fPMAE1XCSjC+Gnj5PW0fL1B1ssrcZxUoWiQKeQTnbduvSW7A1lZQJiviMTKN3mAC+5NI DLpcjW6iPNiABDIt0uDrnQlPXOOq8guDPeYoxMIthiZuB+mxK///+HuRnGldJyVWL3CG zv3piCvSeeDGt5qJACIEucN/+8Nx0nqCOx2CTaKpEjuRwBdaaqHc4pCojqnn9cOzLuhk XeueaFu1HYi1Z0Qt8hQoN3PceP2hO6Ty+5YvMsDiaotb+eiVszRE38knFF5/R9UIlq6I Ullw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jjEY2X1jxUumc1U1a7zkHFAIgkkW0hD0gfjDlnse8B4=; b=Iypi7tdi//+NqonoW+Sc97IoUoyo5ErV7u+UajqbTOyGr6Bk0wk5TtRrAYMLj54Mn3 wP07wshaU3ST6nqcH3OTZJsSIgdq2sgzhmSNLS8wBAGOjPeiGwKMCspN9mRLbnRPs5An RPDk8OINdoQ3t3A0O3Dh0yx5pXjGk5VFpUqWutPXXcvaQoGRbu3JYQIH5qB88fyRX169 +93fupjbrgzde9U9v1BAKvd6ZBwr5nlxyKtTYPCAzjXkCRI3uKRSfMiYnFB9eIzSaBXU c6xIx9K4KcvrWBMmKyNu49KkFREH2yp8StfUvm98SJ8IV0aYEeftnrV+DpX07uxqPvbU n82Q== X-Gm-Message-State: APjAAAXlxxflVrrAfqG07qeW5H+Le+Pl+aKBJ3ZzpIUEt6xkgBvvF8cY GltjvdrM0tl0V/XZdSsR6a39rTxW X-Google-Smtp-Source: APXvYqwV4tI0Cn9YGf/WGLN+Ngb6ahrQHmZ9bKBJxMebATGy5cL2g1s09EKJVj7vuZhdZkBqfTLTig== X-Received: by 2002:a19:5201:: with SMTP id m1mr11635912lfb.68.1554124123630; Mon, 01 Apr 2019 06:08:43 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id x6sm1863127lfe.67.2019.04.01.06.08.41 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 06:08:42 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov , pinkanon pinkanon References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87sgv2pz3c.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Mon, 1 Apr 2019 16:08:40 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Thunderbird/66.0 MIME-Version: 1.0 In-Reply-To: <87sgv2pz3c.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 31.03.2019 23:29, Juri Linkov wrote: > There is another place where messages conceal the minibuffer: > running a version-control command that asks for a branch name > and typing TAB for completion runs a command to fetch branch names. > Its output conceals the minibuffer when vc-command-messages is non-nil. > Here is a fix: The patch is okay, but wouldn't it be better if 'message', when called from the minibuffer, went through command-error-function, or something like that? So we could have a unified interface through which to change the behavior. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 16:46:17 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 20:46:17 +0000 Received: from localhost ([127.0.0.1]:39953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB3ov-0003Xb-1G for submit@debbugs.gnu.org; Mon, 01 Apr 2019 16:46:17 -0400 Received: from bonobo.maple.relay.mailchannels.net ([23.83.214.22]:11114) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB3ot-0003XL-5h for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 16:46:15 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E63CE5C5DF2; Mon, 1 Apr 2019 20:46:13 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 7C0AE5C5C94; Mon, 1 Apr 2019 20:46:13 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a35.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 01 Apr 2019 20:46:13 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Unite-Blushing: 686b2ecb221e2c97_1554151573706_1350158999 X-MC-Loop-Signature: 1554151573705:748539313 X-MC-Ingress-Time: 1554151573704 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 1222E7F601; Mon, 1 Apr 2019 13:46:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=ov+9tX LXaIqpU3YPATU+Awq/wGM=; b=HHBHXnnB+rww10M7WROPC1vMLR1OcvzxFMxYQd n32jqgwggi32qDTokotMq6dVXS/hKOaUHbujP3Hk5RX+jfncon54Q7z4HXpDvWWz IMKVrZE+a1MKNvohVLwCv25x9+eKOB59FCiVqtVIdAbVqujsUZ41hJ7CJpVfeV4m aZf3Y= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 68A7F7F0DB; Mon, 1 Apr 2019 13:46:10 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a35 From: Juri Linkov To: pinkanon pinkanon Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <26451261554113450@myt6-add70abb4f02.qloud-c.yandex.net> Date: Mon, 01 Apr 2019 23:25:08 +0300 In-Reply-To: <26451261554113450@myt6-add70abb4f02.qloud-c.yandex.net> (pinkanon pinkanon's message of "Mon, 01 Apr 2019 13:10:50 +0300") Message-ID: <87r2alcyuj.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrleeggdduhedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtredunecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepphhinhhkrghnohhnrdhpihhnkhgrnhhonheshigrnhguvgigrdhruhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: "34939@debbugs.gnu.org" <34939@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> =A0(2) When I try to quit and some buffer is unchanged, I get the usu= al >>> =A0deal asking me what I want. The problem I have here [in addition t= o >>> =A0the problem discussed in (1), adapted to this case: "Type C-h for >>> =A0help."] is that I must use C-g, but not good old escape. >> >> To avoid all such problems, just bind keyboard-escape-quit globally >> when not on a tty where an ESC prefix still might be needed: >> >> =A0=A0(when window-system >> =A0=A0=A0=A0(define-key global-map [escape] 'keyboard-escape-quit)) > > I have no luck w/ this one, though. Emacs 26.1 build 1, Arch Linux. > steps: emacs -Q somefile -> Eval the code -> type something -> > C-x C-c -> "Save file...? ..." -> Escape -> "Type C-h for help" Thanks for detailed test case, I misunderstood your original description, but now it's clear. `C-x C-c' (save-buffers-kill-terminal) is a special case that requires a special customization: (define-key query-replace-map [escape] 'quit) From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 16:46:28 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 20:46:28 +0000 Received: from localhost ([127.0.0.1]:39956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB3p5-0003Xy-GD for submit@debbugs.gnu.org; Mon, 01 Apr 2019 16:46:28 -0400 Received: from quail.birch.relay.mailchannels.net ([23.83.209.151]:62113) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB3p2-0003Xn-8H for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 16:46:25 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 8CF4912594A; Mon, 1 Apr 2019 20:46:19 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 1BBC9125382; Mon, 1 Apr 2019 20:46:19 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a35.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 01 Apr 2019 20:46:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Spill-Left: 100e56c2478aa588_1554151579244_370851241 X-MC-Loop-Signature: 1554151579243:945017536 X-MC-Ingress-Time: 1554151579243 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id B419F7F0DC; Mon, 1 Apr 2019 13:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=nkAXtT YwPgj15RHo3hE7Mj4Vc7U=; b=iRU2Q3Wd/ThMSVgIntud9XnOxuBI5qXlxuNVQa SfoZOVhikpt1/fbJvOQ0w4qxBRMXQJtdCTyJ/Pv7aH20hZdpw5oYhZcMXtN7jxUi kUkz2oNilQfVV+lhpuMhNHHFnpfZPun6jEKEw20bl4/2e9guHpxSTnflJeFn2g2+ rhCxg= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 9713E7F0DB; Mon, 1 Apr 2019 13:46:16 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a35 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> Date: Mon, 01 Apr 2019 23:29:16 +0300 In-Reply-To: (Dmitry Gutov's message of "Mon, 1 Apr 2019 16:03:41 +0300") Message-ID: <87lg0tbjmj.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrleeggdduhedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> Messages in the echo area should never conceal the minibuffer. Period= . >> >> There is a special function minibuffer-message for this purpose: > > Shouldn't we make this behavior the default, then? I agree it should be the default. But unfortunately I have no idea how to do this. Both ways to catch error signals in the minibuffer: 1. Overriding the default error function with command-error-function; 2. Using condition-case like (condition-case lossage ... minibuffer reading ... (text-read-only (minibuffer-message (get (car lossage) 'error-message))))) Both they override the default error handling called by =E2=80=98error-message-string=E2=80=99 in the function =E2=80=98print_err= or_message=E2=80=99 that performs many useful things that include logging of error messages in the *Messages* buffer. Overriding the default error function will exclude this useful default behavior. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 16:46:30 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 20:46:30 +0000 Received: from localhost ([127.0.0.1]:39959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB3p8-0003YE-98 for submit@debbugs.gnu.org; Mon, 01 Apr 2019 16:46:30 -0400 Received: from catfish.maple.relay.mailchannels.net ([23.83.214.32]:56994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB3p5-0003Xx-TK for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 16:46:28 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7CF481252A8; Mon, 1 Apr 2019 20:46:26 +0000 (UTC) Received: from pdx1-sub0-mail-a35.g.dreamhost.com (unknown [100.96.11.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0B7B312594A; Mon, 1 Apr 2019 20:46:25 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a35.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 01 Apr 2019 20:46:26 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Whistle-Reaction: 6bba47a053e251cc_1554151586253_243086876 X-MC-Loop-Signature: 1554151586253:2836330476 X-MC-Ingress-Time: 1554151586253 Received: from pdx1-sub0-mail-a35.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTP id 8B8CF7F601; Mon, 1 Apr 2019 13:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=bW3Tox VkcW5dtShYFcXnHBHGZ5k=; b=gDtJcHr4YLg0RxeReaQYWWZHhK0pu6CennPmXd gCXIJTwAt/qiVZNu5z9g7MjZz7rTsYCf19ZtmO/YYf5jfkjW/fujQKkMiSzplxHD UzUUQEJjZgplcdaOnaWAeD8prSuIQUa9/HQiAaiNBYYrFiJXJO3Kp+u7bSXuO9QJ 92dPc= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 6272A7F0DC; Mon, 1 Apr 2019 13:46:22 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a35 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87sgv2pz3c.fsf@mail.linkov.net> Date: Mon, 01 Apr 2019 23:31:27 +0300 In-Reply-To: (Dmitry Gutov's message of "Mon, 1 Apr 2019 16:08:40 +0300") Message-ID: <877ecdbj29.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedutddrleeggdduhedtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> There is another place where messages conceal the minibuffer: >> running a version-control command that asks for a branch name >> and typing TAB for completion runs a command to fetch branch names. >> Its output conceals the minibuffer when vc-command-messages is non-nil= . >> Here is a fix: > > The patch is okay, but wouldn't it be better if 'message', when called = from > the minibuffer, went through command-error-function, or something > like that? It's impossible to override =E2=80=98message=E2=80=99 with something like (advice-add 'message :around (lambda (orig-fun &rest args) (if (eq (selected-window) (active-minibuffer-window)) (apply 'minibuffer-message args) (apply orig-fun args))) '((name . message-minibuffer))) because =E2=80=98minibuffer-message=E2=80=99 has =E2=80=98message=E2=80=99= calls and this goes into infinite recursion. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 01 17:54:13 2019 Received: (at 34939) by debbugs.gnu.org; 1 Apr 2019 21:54:13 +0000 Received: from localhost ([127.0.0.1]:40010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB4se-0005FW-TV for submit@debbugs.gnu.org; Mon, 01 Apr 2019 17:54:13 -0400 Received: from mail-lj1-f170.google.com ([209.85.208.170]:33600) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hB4sb-0005FE-Rf for 34939@debbugs.gnu.org; Mon, 01 Apr 2019 17:54:11 -0400 Received: by mail-lj1-f170.google.com with SMTP id f23so9658353ljc.0 for <34939@debbugs.gnu.org>; Mon, 01 Apr 2019 14:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zFxBvSIE6+/3wj4aTQKfJT2SzUa5Coen+IUNvmqy1Bg=; b=LUgJlCwcQL4ZiQ0x93h3w5rBk8RdWOy9yPTs5DBgUejPT80uD7AuxY7HlyYY/XFVTV zldI7dMPkMblqT9X5/TVRRphEuK1GbYF15vLpzEJy9xnDm/y4SiRm1Moz1BjZvc4AQ9N WGB7HpuoTjJ0z4+zPy+Cs2Ye4yM0QOm0lWMNJNLuxs6Vkmx5vqpxSp537SFPmDvGEZ1q PyZT3n1xayTRjX3ds2w6ke/m8nVhp9u3S8/SfruegW7vCvQIG2in9lp2kqik98hkGrug sp65HiZrRfbIm/j6uLuJTqZcXkO95fhRqbzpplV+cZSSJLek6xThwq8U1krltOiFwbkm D+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zFxBvSIE6+/3wj4aTQKfJT2SzUa5Coen+IUNvmqy1Bg=; b=nKpsI64pnvvN9cjlPmG5trFh+KcXBn7W2oxYFC7uQ7JIWq3N0/LszYd9m1rdWcuQBg 7WlYjXWc1iM1DzWdqPTk+mWdAm+g+UH2sMMjnJV+9h9LSAm4F0NFxDQuflG200hb10F4 XAoWy/6quMdZwlcF64dIJWBJn7AcfaJbYBKGE5RbhfgJnUpZGBpOcjeMtdaj+GHtvk82 q3RaPuJaZjkhd+aJX6ncuwHBLr2PZi4QaJrkeZ/joi3E9zNwL/5qkWIJg3p1TvnrrJnB iPeXpgc2IDgiv8zbU5C+Ji96XYFaKYmo5e3ZL5e8xBxq7eFE79QeakIDztLoAjrUMC6V b5sg== X-Gm-Message-State: APjAAAWVWugOrVGVjoC/Cjuw/9/1FTMMHq8+Imu/LcvE55SXYH0Ji9Bv kG1XcDGcf7bVUQrNThN3vVXs/y5i X-Google-Smtp-Source: APXvYqy9ThQg91NGkt5CW9Do6XzVWlEJh708ixPu8ghKzM02HECVwVIjM2hfed95d4KyW0hDOsdiig== X-Received: by 2002:a2e:7806:: with SMTP id t6mr15634224ljc.143.1554155643424; Mon, 01 Apr 2019 14:54:03 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id m18sm2384955ljb.35.2019.04.01.14.54.00 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 01 Apr 2019 14:54:02 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87sgv2pz3c.fsf@mail.linkov.net> <877ecdbj29.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Tue, 2 Apr 2019 00:53:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Thunderbird/66.0 MIME-Version: 1.0 In-Reply-To: <877ecdbj29.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 01.04.2019 23:31, Juri Linkov wrote: > It's impossible to override ‘message’ with something like > > ... > > because ‘minibuffer-message’ has ‘message’ calls > and this goes into infinite recursion. We could change minibuffer-message and introduce a new function that would do "raw" output, to be used in there. And in 'message' too. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 02 14:26:06 2019 Received: (at 34939) by debbugs.gnu.org; 2 Apr 2019 18:26:06 +0000 Received: from localhost ([127.0.0.1]:41694 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBO6m-0001ev-Fm for submit@debbugs.gnu.org; Tue, 02 Apr 2019 14:26:06 -0400 Received: from forward501j.mail.yandex.net ([5.45.198.251]:35326) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBO6j-0001eI-GN for 34939@debbugs.gnu.org; Tue, 02 Apr 2019 14:26:03 -0400 Received: from mxback21g.mail.yandex.net (mxback21g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:321]) by forward501j.mail.yandex.net (Yandex) with ESMTP id AEF0533800E8; Tue, 2 Apr 2019 21:25:54 +0300 (MSK) Received: from localhost (localhost [::1]) by mxback21g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id EaCrmerWfr-PrJakZ3X; Tue, 02 Apr 2019 21:25:54 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1554229554; bh=Uxa2ij95Bm3sxFTAOtJ0GPo7rHoew+VHVctHzdrwQzo=; h=Message-Id:Cc:Subject:In-Reply-To:Date:References:To:From; b=UR+1+ZkxSwovao2lEXjPoztqZlhpDGWXXZMYWoRrNx4SYlHXvV8so6cBrmH81gNDn TIM/pd4wdBsUjAil//DqhjAzBgcto5g4LxdV0RE0PO5uaM1Kts8YFwLCU2tk0FHPQz 7W+LbT9e3HE6pvUniZ0iSwolpv6o6H9RAetuLkEI= Authentication-Results: mxback21g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by sas1-640e2cc17194.qloud-c.yandex.net with HTTP; Tue, 02 Apr 2019 21:25:53 +0300 From: pinkanon pinkanon Envelope-From: pinkanon-pinkanon@yandex.ru To: Juri Linkov In-Reply-To: <87r2alcyuj.fsf@mail.linkov.net> References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <26451261554113450@myt6-add70abb4f02.qloud-c.yandex.net> <87r2alcyuj.fsf@mail.linkov.net> Subject: Re: bug#34939: Some minibuffer behaviour is annoying MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Tue, 02 Apr 2019 21:25:53 +0300 Message-Id: <577871554229553@sas1-640e2cc17194.qloud-c.yandex.net> Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 34939 Cc: "34939@debbugs.gnu.org" <34939@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > `C-x C-c' (save-buffers-kill-terminal) is a special case that > requires a special customization: > > (define-key query-replace-map [escape] 'quit) Great! Thanks, Juri! Thanks all! 01.04.2019, 23:46, "Juri Linkov" : >>>>   (2) When I try to quit and some buffer is unchanged, I get the usual >>>>   deal asking me what I want. The problem I have here [in addition to >>>>   the problem discussed in (1), adapted to this case: "Type C-h for >>>>   help."] is that I must use C-g, but not good old escape. >>> >>>  To avoid all such problems, just bind keyboard-escape-quit globally >>>  when not on a tty where an ESC prefix still might be needed: >>> >>>    (when window-system >>>      (define-key global-map [escape] 'keyboard-escape-quit)) >> >>   I have no luck w/ this one, though. Emacs 26.1 build 1, Arch Linux. >>   steps: emacs -Q somefile -> Eval the code -> type something -> >>   C-x C-c -> "Save file...? ..." -> Escape -> "Type C-h for help" > > Thanks for detailed test case, I misunderstood your original description, > but now it's clear. > > `C-x C-c' (save-buffers-kill-terminal) is a special case that > requires a special customization: > >   (define-key query-replace-map [escape] 'quit) From debbugs-submit-bounces@debbugs.gnu.org Wed Apr 03 17:09:46 2019 Received: (at 34939) by debbugs.gnu.org; 3 Apr 2019 21:09:46 +0000 Received: from localhost ([127.0.0.1]:43327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBn8j-0001QK-NM for submit@debbugs.gnu.org; Wed, 03 Apr 2019 17:09:46 -0400 Received: from cichlid.maple.relay.mailchannels.net ([23.83.214.36]:19303) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hBn8h-0001QB-Do for 34939@debbugs.gnu.org; Wed, 03 Apr 2019 17:09:44 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id E87F38C244D; Wed, 3 Apr 2019 21:09:40 +0000 (UTC) Received: from pdx1-sub0-mail-a11.g.dreamhost.com (100-96-4-94.trex.outbound.svc.cluster.local [100.96.4.94]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 13B548C2392; Wed, 3 Apr 2019 21:09:40 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a11.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 03 Apr 2019 21:09:40 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Grain-Cooperative: 5634da17400ee392_1554325780688_1396834437 X-MC-Loop-Signature: 1554325780688:2278906671 X-MC-Ingress-Time: 1554325780688 Received: from pdx1-sub0-mail-a11.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTP id EF9AC82D22; Wed, 3 Apr 2019 14:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=Qg399U ErC2pbcXdas2q8YrN68QU=; b=2j7M7zGI37I6EN5g2czpwP6BVXhDBUkkFLTa5n 22o++VHEsLwQOxiTucTQ7JHLH+uu4WJRXNJTV2xP3LvIFae/h3KHys5cAfiNQDmF JtRTCToKfCaJtIq1M7j6E3SweQvHisOhlpRsbFXbkTvbJkvUslsdzB/2Qdxx9UN1 VP2ek= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTPSA id 3718082D1E; Wed, 3 Apr 2019 14:09:24 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a11 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87sgv2pz3c.fsf@mail.linkov.net> <877ecdbj29.fsf@mail.linkov.net> Date: Wed, 03 Apr 2019 23:50:37 +0300 In-Reply-To: (Dmitry Gutov's message of "Tue, 2 Apr 2019 00:53:59 +0300") Message-ID: <87k1gavmn6.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrtdefgdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> It's impossible to override =E2=80=98message=E2=80=99 with something l= ike >> >> ... >> >> because =E2=80=98minibuffer-message=E2=80=99 has =E2=80=98message=E2=80= =99 calls >> and this goes into infinite recursion. > > We could change minibuffer-message and introduce a new function that wo= uld > do "raw" output, to be used in there. And in 'message' too. IOW, using the same design as discussed for i18n where gettext is called from a subfunction format-message, not from 'message'. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 16:56:12 2019 Received: (at 34939) by debbugs.gnu.org; 7 Apr 2019 20:56:12 +0000 Received: from localhost ([127.0.0.1]:48775 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDEpo-0007qu-86 for submit@debbugs.gnu.org; Sun, 07 Apr 2019 16:56:12 -0400 Received: from bisque.maple.relay.mailchannels.net ([23.83.214.18]:2459) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDEpm-0007qm-Ms for 34939@debbugs.gnu.org; Sun, 07 Apr 2019 16:56:11 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 146A95E1D30; Sun, 7 Apr 2019 20:56:07 +0000 (UTC) Received: from pdx1-sub0-mail-a60.g.dreamhost.com (100-96-6-122.trex.outbound.svc.cluster.local [100.96.6.122]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 956355E11B6; Sun, 7 Apr 2019 20:56:06 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a60.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 07 Apr 2019 20:56:07 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Invention-Exultant: 46afe1f50bfcabd3_1554670566919_3196417386 X-MC-Loop-Signature: 1554670566919:140665592 X-MC-Ingress-Time: 1554670566918 Received: from pdx1-sub0-mail-a60.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTP id 5B6EC80288; Sun, 7 Apr 2019 13:56:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=JTPM4j t7FdCf2DZS8R/Qg06bkTM=; b=CiNe9GizCz0HPK1sac4hz4Ka3X6AdQdI+UlR3G gNwJKLKKCCQGAiBn3dqEMQAOBlEOJtEy3Jk2mqcoaRjILWuruPXTXuPkyt7iKLme qbHwZmeJbLfTnXjLN9iFpSBF7jPSUYLMJopuCrEAw9DSgE7uYFZdQ/aEPmxi+vcq B8Doo= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTPSA id CFAA38027A; Sun, 7 Apr 2019 13:55:58 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a60 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> Date: Sun, 07 Apr 2019 23:43:01 +0300 In-Reply-To: <87lg0tbjmj.fsf@mail.linkov.net> (Juri Linkov's message of "Mon, 01 Apr 2019 23:29:16 +0300") Message-ID: <877ec5zgeq.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddugdduheegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleelrddvtddvnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleelrddvtddvpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>> Messages in the echo area should never conceal the minibuffer. Perio= d. >>> >>> There is a special function minibuffer-message for this purpose: >> >> Shouldn't we make this behavior the default, then? > > I agree it should be the default. But unfortunately I have no idea > how to do this. Both ways to catch error signals in the minibuffer: > > 1. Overriding the default error function with command-error-function; > > 2. Using condition-case like > > (condition-case lossage > ... minibuffer reading ... > (text-read-only > (minibuffer-message (get (car lossage) 'error-message))))) > > Both they override the default error handling called by > =E2=80=98error-message-string=E2=80=99 in the function =E2=80=98print_e= rror_message=E2=80=99 > that performs many useful things that include logging of error > messages in the *Messages* buffer. Overriding the default error > function will exclude this useful default behavior. Another variant is to extend 'echo_area_display' to use 'minibufer-message' in case of the active minibuffer. More radical approach is to disjoint the minibuffer from the echo area and display them separately one above another. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 19:09:20 2019 Received: (at 34939) by debbugs.gnu.org; 7 Apr 2019 23:09:20 +0000 Received: from localhost ([127.0.0.1]:48843 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDGue-0002dL-6P for submit@debbugs.gnu.org; Sun, 07 Apr 2019 19:09:20 -0400 Received: from mail-lj1-f171.google.com ([209.85.208.171]:39049) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDGuc-0002d5-92 for 34939@debbugs.gnu.org; Sun, 07 Apr 2019 19:09:18 -0400 Received: by mail-lj1-f171.google.com with SMTP id l7so9528871ljg.6 for <34939@debbugs.gnu.org>; Sun, 07 Apr 2019 16:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=71ksgYBJLlluWbatJ5xpG0Vxqs2c7Q313vqbqVsYpCU=; b=UVkab2ETHcAesy7U5RtGIS5bpMWW+EGp+/xIudop67N9Sxbw8rnMh6EzT1FI/L29MA l9rKerS3HPCbyvkkA8BaFUc41SxaqVAfKLkQZ4RbIox/ELNK0kkxU0012ZfVykU5i8ww ugFJuRKv7OYXQ+xTbgR8EfW0l58xPmSlREfLQW/iM6vZoKZV2QDeAK8D+kN2p1SO55Gh NE9equLzbsaCxW6r75Q0AeE/lFm6vQUUiHoGwk13NtoqvjY9ZbJIsPeGqiGJk8htjH4v h+/N++59cr2O4sHx0fTcjNsRhSSvIooHefbhCrCeqJtn1wn3VNT2YDemHsb84b8Mj/xA 1ApQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=71ksgYBJLlluWbatJ5xpG0Vxqs2c7Q313vqbqVsYpCU=; b=TPZyITi8ayWfEENgm0oTmAgdt90JAs4Ij23YIU0pWI3Vgi+sqoKy8qykd86XJBFTYe fjjgNSdodz97Zrk9cttRa3FiNuXMOyJaBo5H0Z2LufyBG3X9mUyAhumQ2fFR6tmzDH82 76B+O2KETbPMk/lpq+0ypMpkXsJhpVs3SS/My0KHmYoxi+PjdiBRSK09OvQqXho1XPqp jBaVICG2R/ZW1H0i4VMvTw5uB1FQMaaVp3EsFoiy92eT5Bg8dp/6mGTzxarMuH0Pt7ze RZP+r0ds8mxfDb8PvVgQj5ccD9HjCJgydHs1ZQDZQwPPLtfI2dDCu/Gzo4Z1wseMKOmd 9DMw== X-Gm-Message-State: APjAAAXi5/8Uw6XB3rp8FXH67myXqIl4YOR7lZxy7+67ksNgPlO7wshc U/hhAZmpQ/CoIjfbN0DZyjVtE4Nz X-Google-Smtp-Source: APXvYqweUKa40W22v305f7WK9i1l3J4uNGpMiels1Vyqy5XU6e2d4ky6iOwqr0BcjGJQoe4ZWgtA5Q== X-Received: by 2002:a2e:3010:: with SMTP id w16mr13954951ljw.62.1554678552166; Sun, 07 Apr 2019 16:09:12 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id k10sm6105964ljh.86.2019.04.07.16.09.10 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 07 Apr 2019 16:09:11 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> Date: Mon, 8 Apr 2019 02:09:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.0a1 MIME-Version: 1.0 In-Reply-To: <877ec5zgeq.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 07.04.2019 23:43, Juri Linkov wrote: > Another variant is to extend 'echo_area_display' to use > 'minibufer-message' in case of the active minibuffer. I think I'd like that. Guess the only downside is having to decide whatever's going to happen when the current minibuffer contents are too long for the area to accommodate both them and the message? From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 16:28:44 2019 Received: (at 34939) by debbugs.gnu.org; 8 Apr 2019 20:28:44 +0000 Received: from localhost ([127.0.0.1]:50210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDasl-00057U-UM for submit@debbugs.gnu.org; Mon, 08 Apr 2019 16:28:44 -0400 Received: from bird.maple.relay.mailchannels.net ([23.83.214.17]:63832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDasj-00057M-Uq for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 16:28:42 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 4F49F1250ED; Mon, 8 Apr 2019 20:28:40 +0000 (UTC) Received: from pdx1-sub0-mail-a91.g.dreamhost.com (unknown [100.96.28.55]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D827B12596F; Mon, 8 Apr 2019 20:28:39 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a91.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 08 Apr 2019 20:28:40 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Keen-Tasty: 12be32401912fcf8_1554755320035_2796964581 X-MC-Loop-Signature: 1554755320035:1006390217 X-MC-Ingress-Time: 1554755320034 Received: from pdx1-sub0-mail-a91.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a91.g.dreamhost.com (Postfix) with ESMTP id 4DF607FA63; Mon, 8 Apr 2019 13:28:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=bUSVHb6Z1X7lwTB+SfBpZgDwwtA=; b= IKA9XImmxVG0EdcTi0u8kklhnxbivhC+hqVQTadvgR0FovTAav5ZIqf0enzFFYe1 idg0mQ99oW0YAZDdmdxVD70DKPWt0G+ITC3VZ+TSEv2ne5aLqGTZKDLMQW6fvEHt miOs4YWu1vvCFJJmx6Ef4sYQ8DIXiyXPRKhtHOWoTeM= Received: from mail.jurta.org (m91-129-99-202.cust.tele2.ee [91.129.99.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a91.g.dreamhost.com (Postfix) with ESMTPSA id 1F39C7FA57; Mon, 8 Apr 2019 13:28:32 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a91 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> Date: Mon, 08 Apr 2019 22:47:35 +0300 In-Reply-To: <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> (Dmitry Gutov's message of "Mon, 8 Apr 2019 02:09:09 +0300") Message-ID: <877ec4wa7c.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrudefgdduhedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesthdtredttdertdenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdelledrvddtvdenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdelledrvddtvddprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegughhuthhovheshigrnhguvgigrdhruhenucevlhhushhtvghrufhiiigvpeef X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> Another variant is to extend 'echo_area_display' to use >> 'minibufer-message' in case of the active minibuffer. > > I think I'd like that. Guess the only downside is having to decide > whatever's going to happen when the current minibuffer contents are too > long for the area to accommodate both them and the message? I see no downsides - using minibuffer-message already does the right thing: it resizes the minibuffer area. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 18:01:15 2019 Received: (at 34939) by debbugs.gnu.org; 8 Apr 2019 22:01:15 +0000 Received: from localhost ([127.0.0.1]:50274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDcKI-0003Cn-Vt for submit@debbugs.gnu.org; Mon, 08 Apr 2019 18:01:15 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:58020) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDcKH-0003CZ-Am for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 18:01:13 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38LxPZ8112664; Mon, 8 Apr 2019 22:01:06 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=c+3nZiVCa2Axu8ds3Td6o0gTz5UzPGXhLCi6cMjzB1g=; b=jKC7GMUlrswkZCFbW3z2+2ZdxdEA2xpvf8T5641zux6EnICgRd6ufWh6y83EnDiIQ2+a 3QreNkxQv1/bPK60jXlS8bEH1wv2R7QrhN//oxLiVbAXIa6NW4ql/5Wzjzhf0PjiADLu 9u7Ohj4svubSh0nBmbD/7jyVZ5dXAkMpCNqgaiSGAwoUiA3PrV/lr5da3YTJDYc0n74n mr+QjXRfsrdknGAU9PWAqmmzMuJYbeUZ66zDLb2aJIp2yd3IeSvlruhMHGN0AgrTcwo8 V+xWGUxtucPgK4j3bz+HDE6FeeHJQ3wT3pOoP43O8lsebslMwco5DUiOFHxjMV7sEtMU Pg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 2rpkhssc9s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 22:01:05 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38LxVjd127262; Mon, 8 Apr 2019 22:01:04 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3030.oracle.com with ESMTP id 2rpj5a7hrh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 22:01:04 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x38M10UF031640; Mon, 8 Apr 2019 22:01:01 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 8 Apr 2019 15:00:59 -0700 (PDT) From: Drew Adams To: Juri Linkov , Dmitry Gutov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> In-Reply-To: <877ec4wa7c.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080160 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080160 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > >> Another variant is to extend 'echo_area_display' to use > >> 'minibufer-message' in case of the active minibuffer. > > > > I think I'd like that. Guess the only downside is having to decide > > whatever's going to happen when the current minibuffer contents are > > too long for the area to accommodate both them and the message? >=20 > I see no downsides - using minibuffer-message already does the right > thing: it resizes the minibuffer area. Apologies for not following this thread. My impression is that you might be trying to make messages, when the minibuffer is active, always use `minibuffer-message' and never `message'. If so, that would be a very bad thing. Not only simplistic but misguided. The two behaviors are quite different, and both can be useful during an interaction while the minibuffer is active. `message' replaces the content of the minibuffer momentarily. `minibuffer-message' does not replace the content but adds to it (mixes with it). I'm sure you're aware of this difference, so I'm confused why youwould think it might be a good idea to make Emacs always use `minibuffer-message'. I'm hoping I've simply misunderstood what you're up to. In a way those are two different levels/dimensions of minibuffer messaging - at least they can be used to that effect. Their difference is just what I stated. Their uses follow from their difference - use each behavior for its particular effect. It's silly to think that either of them is useless or inappropriate, in some blanket way. Each of them can be useless or inappropriate in a given context, and each can be useful and helpful in a given context. I have lots of code that interacts with the minibuffer, in all kinds of way, including dialogs that involve multiple buffers and multiple levels of minibuffers. There is not only _one_ kind of minibuffer-user interaction. It's a judgment call which function (`message' or `minibuffer-message') to use in a specific context. No simple rule can replace such design/judgment. User interactions can take all kinds of forms, with and without the minibuffer. Being able to get the `message' behavior when the minibuffer is active is essential - an important tool in our tool chest. Please do not try to remove that tool. `message' interrupts minibuffer use with echo-area messaging - it's good for that purpose. `minibuffer-message' does not interrupt temporally; it interrupts minibuffer content spatially. It's not about echo-area display inappropriately "concealing" the minibuffer. It's about that display appropriately interrupting it temporarily (controlled by application, not by some silly Emacs built-in lockdown restriction). If you're toying with the idea of replacing `message' behavior with `minibuffer-message' behavior when the minibuffer is active, please ask yourselves what the _real_ problem is that you're trying to solve. I'm sure that's not its solution. (FWIW, I don't see anything in the original problem description that would invite such a "solution".) That a programmer _can_ create a lousy dialog with users, "concealing" minibuffer input inappropriately, should not cause Emacs itself to try to second-guess programmers by preventing them from defining dialogs of all sorts. That's the opposite of Emacs. This, BTW, is completely wrong: > Messages in the echo area should never conceal the minibuffer. Period. > There is a special function minibuffer-message for this purpose Neither of those statements is correct. IMO, such a doctrinaire posture belies ignorance of the spectrum/space of possible minibuffer uses. Thx. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 19:06:56 2019 Received: (at 34939) by debbugs.gnu.org; 8 Apr 2019 23:06:56 +0000 Received: from localhost ([127.0.0.1]:50304 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDdLs-0006zZ-9B for submit@debbugs.gnu.org; Mon, 08 Apr 2019 19:06:56 -0400 Received: from mail-lf1-f42.google.com ([209.85.167.42]:38802) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDdLp-0006zK-UO for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 19:06:55 -0400 Received: by mail-lf1-f42.google.com with SMTP id u24so3865017lfg.5 for <34939@debbugs.gnu.org>; Mon, 08 Apr 2019 16:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4auM+HP5PKE+ctebCQ7Clm96sfkJ4FKRarALuHhy2hY=; b=g1pStgs38b71ordzI1nHvj47z6OoYZ3dUu+eJz5JdB0MJoCD07/VU053jDKUBcxtvP aL2QoMZFDFNp5OMPoTo+d09SfUj9Ad3WaKc4EBPxn6EDa9c31CJ7MDYesh0soxrQEiDr vQUGyF56VjFSe+u+nQGVnXVOvtkQnHlE/xlf/YQxQ27adrROS8KHSUMXd+rVGCsj4b5R mNII8u0qou8WMHscTt6feo6VXiclRG4MXn+6pfDV6uUra7wdiv9kD3B3U+GpH25WBlq2 bRJS8kwwg9VK0zgPHuHn7RENR6lg5JanY4CeDz8oPE4cKwxvU60O2NQSXDMAvhqNZql7 p8cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4auM+HP5PKE+ctebCQ7Clm96sfkJ4FKRarALuHhy2hY=; b=fN0fUS129jpt2vanNy+y4mgTy1VmWYMEgkZvFE/SHm25LEANhKziscfG6Nwd62Qvwy L6so26K/ivVkNlybgvyZIyI6lFuyCXzvyFxSsWUMagK42n3v/LNnv7ryxRUbjkCBp6vk agb+cjcceJvni8SSIQd2H2IxALwlU+NH4pQZAZ6/rpaT2XzHMmu9RRCPxlge+udmU+eF qUwh62I51zYElWwI64/bxuCtPkv99uOi3woJuWDo4otfKNBLXrQttQi/FH4CgnjXLv5V +8CcGbp/ovbFwIjnKgZo7NPUqd3wIQrQHAG18Q8yUC8hRFMGwrVBZm5kTWIVTqmFFwmH yr/w== X-Gm-Message-State: APjAAAUcJvHi3wh9my9J0URislvn2TNlH3qd2MAigLiL9oar3aick/QN 76d6jwA+U4XsMY2jvOVkq7zvXNMf X-Google-Smtp-Source: APXvYqyFqVa0zywzEMn1AwRMMBgRfRkKW+dNfWoaeQN1LdsDr8hifWGnDqGtaEhhVO6izDOtAMSZOA== X-Received: by 2002:ac2:5205:: with SMTP id a5mr2711797lfl.102.1554764806569; Mon, 08 Apr 2019 16:06:46 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id c5sm7225261ljd.18.2019.04.08.16.06.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 16:06:45 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Drew Adams , Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> Date: Tue, 9 Apr 2019 02:06:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 09.04.2019 1:00, Drew Adams wrote: > If you're toying with the idea of replacing > `message' behavior with `minibuffer-message' > behavior when the minibuffer is active, please ask > yourselves what the_real_ problem is that you're > trying to solve. Avoiding hiding the minibuffer contents while the user is interacting with them (e.g. basically anytime the minibuffer is active). From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 19:32:43 2019 Received: (at 34939) by debbugs.gnu.org; 8 Apr 2019 23:32:43 +0000 Received: from localhost ([127.0.0.1]:50325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDdkp-0007f2-9L for submit@debbugs.gnu.org; Mon, 08 Apr 2019 19:32:43 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:40288) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDdkm-0007en-Fx for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 19:32:41 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38NTTpw183781; Mon, 8 Apr 2019 23:32:34 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=cIhmbicm/h74QViv+3Gu8TpDqtZpyzRlpEJZwYrsnFo=; b=hzg3oFMdgE8reKzZBZaYvB5AQxtZ+OBpNqjkBX8JzNyO4QGOFlIEVpA/50x4guciykbD 9MOhxygSjrdpihlt+wPF9EcR1hLBmADFkB9q9HUskL11orepkWT8IKmEAKm1QwlDml/9 5e6wte3BdNbvW0dYZlWCdP5HIBHnYu7mAaoUzLxQvEU2PKSmleTlzIx/Dfc5SFgGHj2a yQaRddC837aEjRP4fW3T5Zixng7qDQPqCNjm1r47oZjahKmagFETFDEDccJ6M5UXWAF6 oq7BnvxsySz+7KaEJ3rCZnCv4XZzIj75tv3baAeeYjJBS1wy/n8ZQMv1gJQC8ZUlqtjw Lg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by aserp2130.oracle.com with ESMTP id 2rphme9tbv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 23:32:34 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38NWTi3136822; Mon, 8 Apr 2019 23:32:33 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2rpytba871-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 08 Apr 2019 23:32:33 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x38NWVSe013304; Mon, 8 Apr 2019 23:32:32 GMT MIME-Version: 1.0 Message-ID: <049df71d-dd1b-4683-9020-e71eb71c5dad@default> Date: Mon, 8 Apr 2019 16:32:31 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Juri Linkov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> In-Reply-To: <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=917 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080170 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=938 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080169 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > If you're toying with the idea of replacing > > `message' behavior with `minibuffer-message' > > behavior when the minibuffer is active, please ask > > yourselves what the_real_ problem is that you're > > trying to solve. >=20 > Avoiding hiding the minibuffer contents while the user is interacting > with them (e.g. basically anytime the minibuffer is active). Avoiding hiding ... is a "solution", not a problem. Well, if you systematically prevent that "hiding" then yes, you will have introduced a problem. Count me as one strongly objecting to such a plan. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 19:37:23 2019 Received: (at 34939) by debbugs.gnu.org; 8 Apr 2019 23:37:23 +0000 Received: from localhost ([127.0.0.1]:50333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDdpL-0007m1-89 for submit@debbugs.gnu.org; Mon, 08 Apr 2019 19:37:23 -0400 Received: from mail-lf1-f53.google.com ([209.85.167.53]:42255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDdpK-0007lo-1h for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 19:37:22 -0400 Received: by mail-lf1-f53.google.com with SMTP id v24so7808295lfe.9 for <34939@debbugs.gnu.org>; Mon, 08 Apr 2019 16:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EQCm1tJYKFRHkAlZrwxOmj4fp61HMxTR3HHlCk2WLG0=; b=rQFXce4l9RTKU0Q45+dpfmopVlIUoVuRx7/elZtK+degP9lRh9UXoYym3tlFvdP11W GLkq+BtpDEGizFz3GFCty6tFbZdULRxhfvGHs90p2N0KrVdEWKBrDLFvIISBT3gDsMvA vfDFUzSfcZCNUjnRD53dI+3Iw809idkdCixu2HfbfHfxFCG9Jo6veFAlBQO6l8R1lrar AE4FGIYogZzHuv5Osgxo7drdTsb1mu5lcxRgbHhgFzyCRZBcTNoAzEY39JxsbrXz9KLB xaRFMk3kjNXvCxbq9656JDXOx81OebwjlC/ELorsZhxBC0q/e4gfp79cWileafXLVDYS okUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EQCm1tJYKFRHkAlZrwxOmj4fp61HMxTR3HHlCk2WLG0=; b=CLXuZMKNx5JMdcveB1ymwLTyuUpSH3oOdX/XCScdcbTSxdZ8ZwZqsLoPm3BRb/50ar 9kfKGrvY8ENuBTdQBAS2/AdBtCMflMzf4Hsp6Fo9bg0kjZXoZceRlaS67HKkqof2Mfpr kIw9hMY0GgJhuibrOKUG4gmbgCBGBVyCjbJGDTgpmRmbdT9Yo50kBiXSkCgO7SPyhiLg RKFC+P/XY8BDJZwXfYHn4UHaCepJL8xR/gD4Nq/EJRH9mE4EBTcB/LQP03iTw7RIrxbd 5jXph3GhxICGt/zsDWB3XRbpPFR2vmjWSgX+IXOU0rgKDDCi2yMPKpWBfKNxc5VFusDk mH1g== X-Gm-Message-State: APjAAAUbIULm/DNYHaBSBBWpn9eth7UbXenXVPZH1QuoVboySkFVco/L 1Fc+JG4UcPA/dUwWAb3iKj6WOv3A X-Google-Smtp-Source: APXvYqxmRbTMg3cvNz3p8N+dXLuGeABmgal+eLo44yU4rWbgs4zRTn6WwJm4I80TqrYMmD6Xqice+w== X-Received: by 2002:ac2:5921:: with SMTP id v1mr17025419lfi.135.1554766635806; Mon, 08 Apr 2019 16:37:15 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id q5sm6225302lfm.16.2019.04.08.16.37.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 16:37:14 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Drew Adams , Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> <049df71d-dd1b-4683-9020-e71eb71c5dad@default> From: Dmitry Gutov Message-ID: <439cea61-fb63-8214-63ce-a053f0d45bed@yandex.ru> Date: Tue, 9 Apr 2019 02:37:11 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <049df71d-dd1b-4683-9020-e71eb71c5dad@default> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 09.04.2019 2:32, Drew Adams wrote: > Avoiding hiding ... is a "solution", not a problem. The problem is that it's hard to efficiently interact with something you cannot see. I'd think that much would be obvious. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 20:00:12 2019 Received: (at 34939) by debbugs.gnu.org; 9 Apr 2019 00:00:12 +0000 Received: from localhost ([127.0.0.1]:50341 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDeBQ-0008Jx-5g for submit@debbugs.gnu.org; Mon, 08 Apr 2019 20:00:12 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:44670) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDeBN-0008Im-Kl for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 20:00:10 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x390036H012807; Tue, 9 Apr 2019 00:00:03 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=tp8pjUoTTA5d7+SSBGIwWCv3w3SDVJtOZMaoA/zZtNk=; b=TuCyGih6FeSx2WoscbF+Bp3Eem+3AiooY4tys9M8m48q9xNHSNrnxgCMfUT85RZmxxmu M+lcojMjw7ip/kMmm/atmFk9EMC7Y+RuBxr2LsEDAnaQB+gKBSQyLMCvFEmxPOvthBgc ubv6VLKyo4gSoX7Nb/FQOEzh50aPVSz7FM1J5ZlsjQWWJKZvVSjGO036hYoRrKN8mJjw lps1on4/O7KrSk3OtCY8P92gp8yAhPVIg0P3YF+5RSmSqBjemZen36nGzb9VBW7B55td ufhuL4JSZJ2GM97D7giBDvH0nrsZ5zxitL2MYQ7F9SFY6ltC9JY9pHx4K/ExMLIbGRnh QA== Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by userp2120.oracle.com with ESMTP id 2rpmrq1m4w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 09 Apr 2019 00:00:03 +0000 Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x38Nxop8116409; Tue, 9 Apr 2019 00:00:03 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 2rpkehyst1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 09 Apr 2019 00:00:03 +0000 Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x390002s026976; Tue, 9 Apr 2019 00:00:01 GMT MIME-Version: 1.0 Message-ID: Date: Mon, 8 Apr 2019 16:59:59 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Juri Linkov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> <049df71d-dd1b-4683-9020-e71eb71c5dad@default> <439cea61-fb63-8214-63ce-a053f0d45bed@yandex.ru> In-Reply-To: <439cea61-fb63-8214-63ce-a053f0d45bed@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080172 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9221 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080172 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > The problem is that it's hard to efficiently interact > with something you cannot see. But you _can_ see it. Before and after the `message', which disappears as soon as you type your next input char or perform some other action. Seeing happens in time, over time. > I'd think that much would be obvious. It's too general and abstract. Too blanket, too black-&-white. Too simplistic, dogmatic. Sometimes in a dialog what's _wanted_ is to interrupt. And there are different ways of interrupting, each of which can be useful, helpful. Sometimes, while a user is inputting content in the minibuffer, she wants to interrupt her own inputting to do something else temporarily. Would you prevent her from doing that too? Sometimes something else going on wants to interrupt her inputting to remind/report/signal/... something. The point is that `message' interrupts temporally, and `minibuffer-message' interrupts spatially. They both interfere with what appears in that little dialog space (minibuffer/echo-area real estate), but they do so in different ways. Those different ways lend themselves to different uses/purposes. They can be put to good use together or separately. "I'd think that much would be obvious." It should be. You're trying to impede the use of an important dialog construct. To return to the OP problem statement - Minibuffer behavior can be annoying or helpful. Programmers have the means to do good or bad. Your removing one of their tools does not improve things - quite the contrary. It's not `message' + minibuffer that's bad. It's a programmer's misguided use of the combination that _can_ be bad. Please leave programming minibuffer interaction to programmers, instead of trying to dictate it from on high. Thx. From debbugs-submit-bounces@debbugs.gnu.org Mon Apr 08 20:11:50 2019 Received: (at 34939) by debbugs.gnu.org; 9 Apr 2019 00:11:51 +0000 Received: from localhost ([127.0.0.1]:50350 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDeMg-0000BT-N4 for submit@debbugs.gnu.org; Mon, 08 Apr 2019 20:11:50 -0400 Received: from mail-lf1-f48.google.com ([209.85.167.48]:36703) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDeMc-0000BD-Ek for 34939@debbugs.gnu.org; Mon, 08 Apr 2019 20:11:47 -0400 Received: by mail-lf1-f48.google.com with SMTP id u17so1563867lfi.3 for <34939@debbugs.gnu.org>; Mon, 08 Apr 2019 17:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HgRC0mU/hfS4guVzSayVaNqafFJTbe2m19CIDcZzGEs=; b=Rkh2dGM6KDdpH+IOk1XrlD7QQRAr7u1OVdebK2THbPeeuPGYJ6nluZGQ4DpqMVtGS5 CJ2IO/dyy+nNNbHSw9jJLV9fAhSSRcEQGqqvU5ErNMOl8ZaQSfB1PzmWlG47F6yysT9I w9/P/gJM9eysE2oAy/VEvPmfxyD+FROChPwKoSHWGiHSdkmTerEkK7NXMmTbzbxVtEHV 7/KkXixahw43fzA//N1h1qJBLsGf0Wx2DmiA+xkZeidrIFJFX0viLe7nYzG3kqMrW0x3 BrN6/A0IwHsdMvm4vQ4tVKtguKLyr/7hUUmOE6lCH1SW2WXRMnVdbQG8jBO3BnLl4Q1J 8a8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HgRC0mU/hfS4guVzSayVaNqafFJTbe2m19CIDcZzGEs=; b=n8SPzsPEAlZeEW1g0a0iysWxGIg/kams3+04Uw0QmP9fdTL2rMWDTie+arUcw1wrYA 1lsGDiy2wGOghCp7n+gcoU/Yll9aI+9f1lDNFFVB7qQOCyovNYyEV8Z8Ksb87Mma6Ih8 zHREBawRzzlJDM83JcDHCMQEX8iuudRy02G83VXG1CRV/f1Wy/+T7YW8hsS94MCrcBtY dwwyckETqhhGfdm9OkaiH1pRqICBkSU6in1oV46tgWazuvasxVuJfDVhuJze5ncTO7Kp Pfr3XSkYO3YyE345ICxD+ltEmf4bf3/lyplBuEJIIcmLV+XIuQz5gKKqyFE99jqDpKBT zz7g== X-Gm-Message-State: APjAAAXHYMkFGwD/nRYtpBHTPHdCt0mra0tfDy/iB3KAgj8bbBb683LS UzTvWmv8x/nHp7fE4R9Ozy7qzs4P X-Google-Smtp-Source: APXvYqzpxrc+JiEM9nHJSXWHuqqf+4P0wZWC4QpVySXIgKZ4yI+DwqtoXVIOogYVgrvq6updQdgTlA== X-Received: by 2002:ac2:4839:: with SMTP id 25mr8522960lft.85.1554768699430; Mon, 08 Apr 2019 17:11:39 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id m18sm6500580ljb.35.2019.04.08.17.11.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 17:11:38 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Drew Adams , Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> <049df71d-dd1b-4683-9020-e71eb71c5dad@default> <439cea61-fb63-8214-63ce-a053f0d45bed@yandex.ru> From: Dmitry Gutov Message-ID: <4eee2f08-5385-c845-07f6-355d242d3ae0@yandex.ru> Date: Tue, 9 Apr 2019 03:11:34 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 09.04.2019 2:59, Drew Adams wrote: > But you _can_ see it. Before and after the `message', > which disappears as soon as you type your next input > char or perform some other action. Seeing happens > in time, over time. Yeah, it's annoying and creates a bad image for the editor. Just see the original report. >> I'd think that much would be obvious. > > It's too general and abstract. Too blanket, too > black-&-white. Too simplistic, dogmatic. > > Sometimes in a dialog what's _wanted_ is to interrupt. > And there are different ways of interrupting, each of > which can be useful, helpful. If we do get around to having message always delegate to minibuffer-message, there will be another function for "interrupting" messages. It would require you to do some compatibility shimming in your code, though. From debbugs-submit-bounces@debbugs.gnu.org Tue Apr 09 14:26:44 2019 Received: (at 34939) by debbugs.gnu.org; 9 Apr 2019 18:26:44 +0000 Received: from localhost ([127.0.0.1]:51958 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDvSG-0000rp-FG for submit@debbugs.gnu.org; Tue, 09 Apr 2019 14:26:44 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:52994) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDvSE-0000rJ-GW for 34939@debbugs.gnu.org; Tue, 09 Apr 2019 14:26:43 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x39IKBBU139366; Tue, 9 Apr 2019 18:26:35 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=6OF2Kc78nx3jZ95BMbYqaleGItvbrNJ1vc/bvCdnA34=; b=uqMda3ZwT0wq3v7b66GbWNff1eeYwP+suDoUwlNUR+cwYLdXTOANLSxMd8J5UB/uOpGy BvsahZ2Kn2Wfhswwq2TWLr/NF85m1oixpPSHmmEdbDnPN60Bj5EORHoPxWmeAUq67teZ 6WBMnDAjbEELEkWXmPHOkobfsGT/K0xDVNLAGKpVgVhB4E+CPry8s5RGzApBWKyYUAV1 gaK6E+NOAGxRf+dXC/VTC/1yJtSTBJl1PxnuaGlJs4vEpLh3fsuLXR46yx15l+vIFZA9 JhTvWVFiQ7RMIDxUiKArxglorurzzUVWjz+gaBaWz5Edwh/GTCN0zh0q8miEh1nJHlCK iw== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2130.oracle.com with ESMTP id 2rpkhsxvdj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 09 Apr 2019 18:26:35 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x39IPc2b108659; Tue, 9 Apr 2019 18:26:34 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3020.oracle.com with ESMTP id 2rpytbs3bf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 09 Apr 2019 18:26:34 +0000 Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x39IQWFf028378; Tue, 9 Apr 2019 18:26:32 GMT MIME-Version: 1.0 Message-ID: <54041382-cfd6-4842-aea8-741213f917e9@default> Date: Tue, 9 Apr 2019 11:26:31 -0700 (PDT) From: Drew Adams To: Dmitry Gutov , Juri Linkov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87lg0tbjmj.fsf@mail.linkov.net> <877ec5zgeq.fsf@mail.linkov.net> <76a81f37-acf8-1eee-5e9d-0e44b945aaeb@yandex.ru> <877ec4wa7c.fsf@mail.linkov.net> <00a1524b-cce8-70ad-97a8-35e5ef342435@yandex.ru> <049df71d-dd1b-4683-9020-e71eb71c5dad@default> <439cea61-fb63-8214-63ce-a053f0d45bed@yandex.ru> <4eee2f08-5385-c845-07f6-355d242d3ae0@yandex.ru> In-Reply-To: <4eee2f08-5385-c845-07f6-355d242d3ae0@yandex.ru> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4834.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9222 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090115 X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9222 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904090115 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > But you _can_ see it. Before and after the `message', > > which disappears as soon as you type your next input > > char or perform some other action. Seeing happens > > in time, over time. >=20 > Yeah, it's annoying and creates a bad image for the > editor. Just see the original report. One user does not speak for all Emacs users. Bad image of the editor is in the eye of the beholder, and it should not be our primary concern. Usefulness for users (including Elisp programmers) should be our main concern. Different users make different uses of Emacs. One size - even the one size you think is great - does not fit all. > >> I'd think that much would be obvious. > > > > It's too general and abstract. Too blanket, too > > black-&-white. Too simplistic, dogmatic. > > > > Sometimes in a dialog what's _wanted_ is to interrupt. > > And there are different ways of interrupting, each of > > which can be useful, helpful. >=20 > If we do get around to having message always delegate to > minibuffer-message, there will be another function for "interrupting" > messages. It would require you to do some compatibility shimming in your > code, though. I made my points. I'm not going to argue with you. As you do, you will just do what you want anyway. I will say this though. 1. Whatever you do, please do it in Lisp, not C, so users can advise, redefine, remove, or improve on it according to their needs using Lisp. 2. Please make the behavior controllable by users and by code (Lisp). 3. Since 2009 I've used the following simple function in my code. It lets code and users control the behavior. It is in _addition_ to `minibuffer-message' and `message', as another alternative. IOW, sometimes I call `minibuffer-message', sometimes`message', and sometimes this function. An example of code controlling the behavior is binding `icicle-minibuffer-message-ok-p' to nil (conditionally) to avoid delays from using `minibuffer-message' or to inhibit possible message display. I have over a hundred calls to this function, so you can see that I am sensitive to the need to often use `minibuffer-message' when the minibuffer is active. What I disagree with is your black-&-white view of things, which leads you to want to always impose the single behavior of `minibuffer-message'. (defun icicle-msg-maybe-in-minibuffer (format-string &rest args) "Display FORMAT-STRING as a message. If called with the minibuffer inactive, use `message'. Otherwise: If `icicle-minibuffer-message-ok-p', then use `minibuffer-message'. Else do nothing (no message display)." (if (active-minibuffer-window) (when icicle-minibuffer-message-ok-p (save-selected-window (select-window (minibuffer-window)) (minibuffer-message (apply #'format (concat " [" format-string "]") args)))) (apply #'message format-string args))) From debbugs-submit-bounces@debbugs.gnu.org Sun May 19 16:16:55 2019 Received: (at 34939) by debbugs.gnu.org; 19 May 2019 20:16:55 +0000 Received: from localhost ([127.0.0.1]:35603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSSEo-0005cD-S1 for submit@debbugs.gnu.org; Sun, 19 May 2019 16:16:55 -0400 Received: from ostrich.birch.relay.mailchannels.net ([23.83.209.138]:44370) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hSSEm-0005c5-L5 for 34939@debbugs.gnu.org; Sun, 19 May 2019 16:16:53 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 85773141912; Sun, 19 May 2019 20:16:51 +0000 (UTC) Received: from pdx1-sub0-mail-a42.g.dreamhost.com (100-96-85-27.trex.outbound.svc.cluster.local [100.96.85.27]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0D027140DC8; Sun, 19 May 2019 20:16:51 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a42.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Sun, 19 May 2019 20:16:51 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Invention-Stop: 3e54d1644a38d019_1558297011394_3744610469 X-MC-Loop-Signature: 1558297011394:2975229376 X-MC-Ingress-Time: 1558297011393 Received: from pdx1-sub0-mail-a42.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a42.g.dreamhost.com (Postfix) with ESMTP id B395980053; Sun, 19 May 2019 13:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=cRf4rTfnbiwDMQP58lHRxxlFm0Y=; b= Taiqjuuu29agEOQDxgniqwRjhBXAL/dVEiFEzAoPI+BOroLQ2yrPtGHHZWReZIq7 m1e8yEAtdcEHeD2rKaFOMu1PQ4ulizdenzFn9gqcHwADcUj5vD8CRq/VBiJxZd+h 3TIH77dxA9Rr+Lk/WycCcYiFh4h7xyWO2rV4ERaey9M= Received: from mail.jurta.org (m91-129-96-230.cust.tele2.ee [91.129.96.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a42.g.dreamhost.com (Postfix) with ESMTPSA id D06D480045; Sun, 19 May 2019 13:16:40 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a42 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87sgv2pz3c.fsf@mail.linkov.net> Date: Sun, 19 May 2019 23:16:18 +0300 In-Reply-To: (Dmitry Gutov's message of "Mon, 1 Apr 2019 16:08:40 +0300") Message-ID: <87zhnip5d9.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddtiedgudehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirddvfedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirddvfedtpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> There is another place where messages conceal the minibuffer: >> running a version-control command that asks for a branch name >> and typing TAB for completion runs a command to fetch branch names. >> Its output conceals the minibuffer when vc-command-messages is non-nil. >> Here is a fix: > > The patch is okay Pushed to master. From debbugs-submit-bounces@debbugs.gnu.org Fri May 24 18:49:13 2019 Received: (at 34939) by debbugs.gnu.org; 24 May 2019 22:49:13 +0000 Received: from localhost ([127.0.0.1]:47573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUIzx-0007BU-6O for submit@debbugs.gnu.org; Fri, 24 May 2019 18:49:13 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:39619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hUIzv-0007BD-Oo for 34939@debbugs.gnu.org; Fri, 24 May 2019 18:49:12 -0400 Received: by mail-wr1-f45.google.com with SMTP id e2so2641988wrv.6 for <34939@debbugs.gnu.org>; Fri, 24 May 2019 15:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=En55Q+7y2ldf6Wc1y0YsdML7T0NGY5MGuK1CrhLYX9I=; b=NTNV/iZ9vMu8hwgQcs9tHbc4o06Uw8LAnOC9IRN2qppp1gYniFMznNaBZhOayEFhqI Jd1tchRgAjwj45erCmRuAS5NXCaKcJ2cMeCzXQtXI0jY+UVbbZJBQyRAN31wuwfPbyiG loxYL+Do8AHu5Ol7KCRrNToyFDkKga/LaUSduGxBKcsbbEYtDhziX9mehmiQ9MG3kVF7 q/Xci6y4n0JF1I8d5WF0qZrXQVimTRmD/g7xlYI+JTm0qXBQpfs0YRSgUlPtFw9haNrv y2bB5UOronpHzwBL8NhVv/SucHgBc+MAwBz7az6M0O3CJT9PEoU4OChvgIp4I3TOwrh7 Dprw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=En55Q+7y2ldf6Wc1y0YsdML7T0NGY5MGuK1CrhLYX9I=; b=Vqy4RxcEAAeQkFexuT5Dd6Amv+58OwlkitBAwdUU9cnmcIySrvNeuQXb3Tx/+EX/01 pAFQT74dsEcYDSEBrbkFJL7frPf5IzjghEecgGbhaiZTdtqHiLc8smsiCuO1mvLBJu33 WNRZAjfOJgNae4Q/GGBERwJneGWRKQsDt0ObkE2N1wO3KzE3Nxg11+iMzO5oknhifjy1 xlLBsLHMCJbX71/k2TQVWp/4R+A/lMdYzGLcOsyZ4j4HuBlqlD3paEQJFkcZeL6Depd0 syLj6Rf6h90g3oGlRFFSGmC2cPW4ZpJnM8VK1wgzXiVLmAa7uzc2SyXGH2BA1mkZrWTP 6z6A== X-Gm-Message-State: APjAAAWtNpm0IHIK5x98W13x0PWZTDnfUerEgizdpvaYqjhSOPKTx3HT safHVJPdDM5M0lYkilU2lgsurPO9 X-Google-Smtp-Source: APXvYqymX9xNSvFzyPyXJWIFjP0dd0bNMfoUdRk9pexKG/z0gaokVagjvQZgLIyqd7XZ/2HCBoSP+g== X-Received: by 2002:adf:c506:: with SMTP id q6mr4077478wrf.219.1558738145592; Fri, 24 May 2019 15:49:05 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id x68sm4776794wmf.13.2019.05.24.15.49.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 15:49:04 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov , pinkanon pinkanon References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Sat, 25 May 2019 01:49:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87a7hasuz4.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 31.03.2019 22:49, Juri Linkov wrote: > There is a special function minibuffer-message for this purpose: > > (add-hook 'minibuffer-setup-hook > (lambda () > (setq-local command-error-function > (lambda (error context _command) > (minibuffer-message > (concat context (get (car error) > 'error-message))))))) So um, what's the best way to make this behavior the default? From debbugs-submit-bounces@debbugs.gnu.org Mon May 27 16:16:20 2019 Received: (at 34939) by debbugs.gnu.org; 27 May 2019 20:16:20 +0000 Received: from localhost ([127.0.0.1]:54250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVM2e-0000Kz-IG for submit@debbugs.gnu.org; Mon, 27 May 2019 16:16:20 -0400 Received: from cichlid.maple.relay.mailchannels.net ([23.83.214.36]:22923) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVM2c-0000Kq-8C for 34939@debbugs.gnu.org; Mon, 27 May 2019 16:16:19 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 6F90814194C; Mon, 27 May 2019 20:16:16 +0000 (UTC) Received: from pdx1-sub0-mail-a50.g.dreamhost.com (100-96-88-48.trex.outbound.svc.cluster.local [100.96.88.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D1306141FD0; Mon, 27 May 2019 20:16:15 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a50.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 27 May 2019 20:16:16 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Squirrel-Shoe: 23d9d6fc215e8915_1558988176294_3743755973 X-MC-Loop-Signature: 1558988176294:3659015010 X-MC-Ingress-Time: 1558988176293 Received: from pdx1-sub0-mail-a50.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a50.g.dreamhost.com (Postfix) with ESMTP id 64C62832A6; Mon, 27 May 2019 13:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=YFppzO zprexcDc2ZlztrtueQHfU=; b=Cs8Uq9q0Fa2bUuNts1Wem5TF8dKvIPLjjNhgKW A2JyK9Q3y3L3nw7PozovPBi2hU/YpKQIiHpMH3Ea4rBUy47RKJkMUhR+GbGORI3P Q2PWHziTWbPYmBP8j6Ztgzo3GbMQWU4XAAdvWlbe/sP+yVrYPunRxmsEeOFRcl49 zgKoY= Received: from mail.jurta.org (m91-129-96-73.cust.tele2.ee [91.129.96.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a50.g.dreamhost.com (Postfix) with ESMTPSA id E6BBF83283; Mon, 27 May 2019 13:16:06 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a50 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> Date: Mon, 27 May 2019 23:15:34 +0300 In-Reply-To: (Dmitry Gutov's message of "Sat, 25 May 2019 01:49:00 +0300") Message-ID: <87imtvd57d.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvfedgudegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgfgsehtkeertddtreejnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirdejfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrjeefpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughguhhtohhvseihrghnuggvgidrrhhunecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.3 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.3 (-) >> There is a special function minibuffer-message for this purpose: >> >> (add-hook 'minibuffer-setup-hook >> (lambda () >> (setq-local command-error-function >> (lambda (error context _command) >> (minibuffer-message >> (concat context (get (car error) >> 'error-message)))))= )) > > So um, what's the best way to make this behavior the default? This is a nice behavior but the problem is that overriding command-error-function also removes other useful default features such as logging error messages to the *Messages* buffer (see more at =E2=80=98print_error_message=E2=80=99). From debbugs-submit-bounces@debbugs.gnu.org Mon May 27 16:58:15 2019 Received: (at 34939) by debbugs.gnu.org; 27 May 2019 20:58:15 +0000 Received: from localhost ([127.0.0.1]:54315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVMhC-0003WY-ST for submit@debbugs.gnu.org; Mon, 27 May 2019 16:58:15 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:43883) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hVMhA-0003WG-PU for 34939@debbugs.gnu.org; Mon, 27 May 2019 16:58:13 -0400 Received: by mail-wr1-f42.google.com with SMTP id l17so9565276wrm.10 for <34939@debbugs.gnu.org>; Mon, 27 May 2019 13:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=cBQyAYhEV442Qp9MgPlOl0W3Qd29ZLAljowhwj43F5o=; b=IQ1SIWnN4RaJ5jMwrYyOJ5E+PmkayWfyUP6o0tBO+pmwkdji8o+AjwTgSe7ZiF7niX PyCYmEd0nqrOQAMCs9dfRL+qRjJWGJEFf1ViPHn/1LQt3HY5AomlNl9m1HQ1vKTNnq0E DY7f3HhVdMtuoY/thdTXIsI0mrL8bEILKXj/tyAeC0rVjv5C/OgR2SdmCMtxvXW8NLZY S/ZjHV4gwYW17KJnIbCLkmBoBqmzIdUV8ZKoYnEvjCKmSx8um5xGJ3XLq7tCRw0tw7Gx cwMoXWHeMtraLcELSUDNPtMJpSudJwW0Ddc4pY2IV8yMm+LGvcgx9Xe0FmWJVmUB/Bup 6WZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=cBQyAYhEV442Qp9MgPlOl0W3Qd29ZLAljowhwj43F5o=; b=nBioAwYzTbCxLTFSVXKMRauIaoQBuuxMDDhYVquSHJt2Fwaq/D/qgdZDckakEfT3q2 o0JcNbOiCcEwmkMs/XF//tok2bHfgJ271k9Cray1bF0kEU4lLGhWNJ9SKyy/SlA9wPz2 J5czKha0GwBd6ifpLYu+3VaIKlGrXoNOrAo13bBWIj4xXz9ex3SpywUpdcSPk7MPnhRZ kXnbusxpTBs1NsX10xqYil6WyaY9H5VuNbV7BHR21DPdwnVNKyZAELxX7oWakEPNI+RR 1kr0LsRoDXWnnQD7O7U+HFFN4esXeFyVGUhs2JkBTcrgT70VMqlJ/H3BaQqouKEwBPfG by3w== X-Gm-Message-State: APjAAAVKVWUwXaInploLsuNFqEq4vdPInxO8XsK5A92oQpRPDrORVhMj FmLGceb6ttVIXYSl5vCKcrw0g+fk X-Google-Smtp-Source: APXvYqysiH6L4KfMy9qV6bK+07w4pt6jvZ6YdiRATLuLkSybbJZOpnpm75wlJwNIigIP8dPhOoCoRQ== X-Received: by 2002:adf:8306:: with SMTP id 6mr62279262wrd.155.1558990686424; Mon, 27 May 2019 13:58:06 -0700 (PDT) Received: from [192.168.1.3] ([185.105.174.23]) by smtp.googlemail.com with ESMTPSA id b12sm418158wmg.27.2019.05.27.13.58.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 May 2019 13:58:05 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: Date: Mon, 27 May 2019 23:58:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <87imtvd57d.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) On 27.05.2019 23:15, Juri Linkov wrote: >> So um, what's the best way to make this behavior the default? > > This is a nice behavior but the problem is that overriding > command-error-function also removes other useful default features > such as logging error messages to the *Messages* buffer > (see more at ‘print_error_message’). Could we first print it and then call minibuffer-message? From debbugs-submit-bounces@debbugs.gnu.org Wed May 29 17:57:00 2019 Received: (at 34939) by debbugs.gnu.org; 29 May 2019 21:57:00 +0000 Received: from localhost ([127.0.0.1]:60195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hW6ZA-00041E-6w for submit@debbugs.gnu.org; Wed, 29 May 2019 17:57:00 -0400 Received: from bisque.maple.relay.mailchannels.net ([23.83.214.18]:64367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hW6Z8-000413-1D for 34939@debbugs.gnu.org; Wed, 29 May 2019 17:56:59 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 5D25E5E23C5; Wed, 29 May 2019 21:56:56 +0000 (UTC) Received: from pdx1-sub0-mail-a6.g.dreamhost.com (100-96-85-75.trex.outbound.svc.cluster.local [100.96.85.75]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 79DFA5E2572; Wed, 29 May 2019 21:56:55 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a6.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 29 May 2019 21:56:56 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Cellar-Interest: 7096e297284252f1_1559167016109_1935566507 X-MC-Loop-Signature: 1559167016108:351685638 X-MC-Ingress-Time: 1559167016108 Received: from pdx1-sub0-mail-a6.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTP id B85D5802AC; Wed, 29 May 2019 14:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=g9dexxbszWC5UGJnqRwNyQiig9U=; b= AYXQdy/1G1dC29UnwsToX7LXeSM9L9BdpIQXG2cexTggiidE59TYaRxIMQ/FUHhJ c5dXyYFJ2Mo8TdgAsi+WewLUtYKg6Dx0qd+jIkXlEf4jxfYpUCfTHHH019EOFCX/ BvH3oZHdVeKqqf2Ex2h7odUGbuLMCuV7cSC1WrdYprU= Received: from mail.jurta.org (m91-129-96-73.cust.tele2.ee [91.129.96.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a6.g.dreamhost.com (Postfix) with ESMTPSA id 769AC802A7; Wed, 29 May 2019 14:56:48 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a6 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> Date: Thu, 30 May 2019 00:53:46 +0300 In-Reply-To: (Dmitry Gutov's message of "Mon, 27 May 2019 23:58:00 +0300") Message-ID: <877ea96i6t.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvkedgtdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhofhffjgfkfgggtgesmhdtreertderjeenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdeliedrjeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirdejfedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegughhuthhovheshigrnhguvgigrdhruhenucevlhhushhtvghrufhiiigvpedt X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable >>> So um, what's the best way to make this behavior the default? >> >> This is a nice behavior but the problem is that overriding >> command-error-function also removes other useful default features >> such as logging error messages to the *Messages* buffer >> (see more at =E2=80=98print_error_message=E2=80=99). > > Could we first print it and then call minibuffer-message? Here is a complete 1-to-1 rewrite of the C function =E2=80=98print_error_= message=E2=80=99 in Lisp that now can be used for more user-friendly displaying error mess= ages in the minibuffer: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=minibuffer-error-function.patch diff --git a/lisp/simple.el b/lisp/simple.el index 4454791ad2..5f5c6b1a59 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -2440,6 +2440,45 @@ minibuffer-history-isearch-pop-state (goto-history-element hist-pos)) +(add-hook 'minibuffer-setup-hook 'minibuffer-error-initialize) + +(defun minibuffer-error-initialize () + "Set up minibuffer error processing." + (setq-local command-error-function 'minibuffer-error-function)) + +(defun minibuffer-error-function (data context caller) + "Display output error messages in the active minibuffer. +Its arguments are the same as in `command-error-default-function'." + (discard-input) + (ding) + (let* ((errname (car data)) + errmsg file-error tail text + (sep ": ")) + (cond + ((eq errname 'error) + (setq data (cdr data)) + (when (consp data) (setq data nil)) + (setq errmsg (car data))) + (t + (setq errmsg (substitute-command-keys (get errname 'error-message)) + file-error (memq 'file-error (get errname 'error-conditions))))) + (setq tail (cdr-safe data)) + (when (and file-error (consp tail)) + (setq errmsg (car tail) + tail (cdr tail))) + (setq text (if (stringp errmsg) errmsg "peculiar error")) + (while tail + (setq text (concat text sep)) + (if (or file-error (eq errname 'end-of-file) (eq errname 'user-error)) + (setq text (concat text (format "%s" (car tail)))) + (setq text (concat text (format "%S" (car tail))))) + (setq sep ", ") + (setq tail (cdr tail))) + (let ((inhibit-message t)) + (message "%s%s" (if caller (format "%s: " caller) "") text)) + (minibuffer-message (concat context text)))) + + ;Put this on C-x u, so we can force that rather than C-_ into startup msg (define-obsolete-function-alias 'advertised-undo 'undo "23.2") --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed May 29 18:26:29 2019 Received: (at 34939) by debbugs.gnu.org; 29 May 2019 22:26:29 +0000 Received: from localhost ([127.0.0.1]:60248 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hW71g-0004kq-SC for submit@debbugs.gnu.org; Wed, 29 May 2019 18:26:29 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:39876) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hW71d-0004kZ-SH for 34939@debbugs.gnu.org; Wed, 29 May 2019 18:26:26 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4TM43oK030558; Wed, 29 May 2019 22:26:18 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=Y/rm102IDATX91O4oo9UK45eNXYzu6GlbpkvRN296CM=; b=Jt3Kl2M2JzRKXGmuY491CCQhRwVZSH+GaZWR/7TkwMnhS6uynZESrfZwrcT/WCScmcul VkAj80PF76jWf4zx2hbfvvDDrAkpLyqNv6mWCpOMRpoM1BUNZz2siSMusMbB6e/OMLDn SaajjWP27CIbQYz9fFfqi9Stxf8SkuvtPNHHFdeezit98j4sQTzsEwb4Jc/WMI5ch52a +nJ8vpIAw74Jzqkg2vgOfPS9ULMHdGNUxA/emW9f27Ap/7Lyy0/R9MjXx+TXHhSWccjK sCqEKKENRVuwkqLVgkrTsqZFz5/VItXw+Pvcsn+qp4Kas98CvQZyGg6MSDkp/MjmlNM/ Mw== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2spxbqcp3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 May 2019 22:26:18 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4TMOi1V169367; Wed, 29 May 2019 22:26:17 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3020.oracle.com with ESMTP id 2sqh73yknx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 29 May 2019 22:26:17 +0000 Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x4TMQGgn020940; Wed, 29 May 2019 22:26:16 GMT MIME-Version: 1.0 Message-ID: <0501caa5-0196-45fd-8bc6-8dbb176622ce@default> Date: Wed, 29 May 2019 15:26:15 -0700 (PDT) From: Drew Adams To: Juri Linkov , Dmitry Gutov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> <877ea96i6t.fsf@mail.linkov.net> In-Reply-To: <877ea96i6t.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4849.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9272 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905290138 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9272 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905290138 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: pinkanon pinkanon , 34939@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Here is a complete 1-to-1 rewrite of the C function =E2=80=98print_error_= message=E2=80=99 > in Lisp that now can be used for more user-friendly displaying error mess= ages ^^^^^^^^^^^ > in the minibuffer I haven't been following this thread. But it looks like this will use `minibuffer-message' for errors raised during minibuffer input, and block `message', except for logging. Is that right? If not, just what does this change represent? If so, please do not do this. We should continue to use `message' by default - have normal error messaging, whether the minibuffer is active or not - there's no substitute for `message' in this context. If a particular user wants to add this function to `minibuffer-setup-hook' she can do so, but it should not be the default behavior. Your "can be used" is appropriate for a user choice. It's not appropriate for changing the default behavior. From debbugs-submit-bounces@debbugs.gnu.org Thu May 30 15:54:29 2019 Received: (at 34939) by debbugs.gnu.org; 30 May 2019 19:54:29 +0000 Received: from localhost ([127.0.0.1]:33950 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hWR89-0001Qh-4C for submit@debbugs.gnu.org; Thu, 30 May 2019 15:54:29 -0400 Received: from ostrich.birch.relay.mailchannels.net ([23.83.209.138]:10013) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hWR85-0001QX-5o for 34939@debbugs.gnu.org; Thu, 30 May 2019 15:54:27 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D30AC141E86; Thu, 30 May 2019 19:54:23 +0000 (UTC) Received: from pdx1-sub0-mail-a100.g.dreamhost.com (100-96-91-66.trex.outbound.svc.cluster.local [100.96.91.66]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2D2F4142272; Thu, 30 May 2019 19:54:23 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a100.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 30 May 2019 19:54:23 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Desert-Cellar: 4769e8d2438b9fd4_1559246063688_1736218256 X-MC-Loop-Signature: 1559246063688:2803512178 X-MC-Ingress-Time: 1559246063688 Received: from pdx1-sub0-mail-a100.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTP id 931307F582; Thu, 30 May 2019 12:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=o+lI+h FrgS4iwzOSAM0SBALiFNg=; b=TB3BmYL9DcIYqx5rgxwZ+KuDZK7fqITgJh0lA7 Q8YIF2yX0EKRW9x7UDTtQ0UZ8tEuC/NFvt47jEb7q/F6qrCA6xpLQ5hPYpb+SLmI oiaerpNSCYRKL5Vbk0aSTwRR2b1l+GDEbmELkorRrEBBReS7NsHah7oO47MLU9d6 ZoNEo= Received: from mail.jurta.org (m91-129-96-73.cust.tele2.ee [91.129.96.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTPSA id BF9FB7F58F; Thu, 30 May 2019 12:54:16 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a100 From: Juri Linkov To: Drew Adams Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> <877ea96i6t.fsf@mail.linkov.net> <0501caa5-0196-45fd-8bc6-8dbb176622ce@default> Date: Thu, 30 May 2019 22:50:16 +0300 In-Reply-To: <0501caa5-0196-45fd-8bc6-8dbb176622ce@default> (Drew Adams's message of "Wed, 29 May 2019 15:26:15 -0700 (PDT)") Message-ID: <87ef4foh6v.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvledgudeggecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtgfesthekredttderjeenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdeliedrjeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirdejfedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegurhgvfidrrggurghmshesohhrrggtlhgvrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org, pinkanon pinkanon , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> Here is a complete 1-to-1 rewrite of the C function =E2=80=98print_err= or_message=E2=80=99 >> in Lisp that now can be used for more user-friendly displaying error m= essages > ^^^^^^^^^^^^^ >> in the minibuffer > > I haven't been following this thread. But it looks > like this will use `minibuffer-message' for errors > raised during minibuffer input, and block `message', > except for logging. Is that right? No, it won't block messages. > If not, just what does this change represent? It will display messages together with the minibuffer contents instead of replacing it. Currently it requires the user to wait 2 seconds before the user can see the minibuffer contents again. Most often, this happens after typing M-n to see if any default values are available, and it replaces the minibuffer contents with the message =E2=80=9CEnd of history; no default available=E2=80=9D. I have to wait s= everal times per day for this message to go away. Totally it takes ~1 minute per day, ~300 minutes (5 hours) per year, and ~50 hours per decade - this is a whole workweek of just looking at the message and waiting for Godot. From debbugs-submit-bounces@debbugs.gnu.org Thu May 30 17:00:40 2019 Received: (at 34939) by debbugs.gnu.org; 30 May 2019 21:00:40 +0000 Received: from localhost ([127.0.0.1]:34065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hWSAC-0003Ox-7N for submit@debbugs.gnu.org; Thu, 30 May 2019 17:00:40 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:53624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hWSA9-0003Oh-NN for 34939@debbugs.gnu.org; Thu, 30 May 2019 17:00:38 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4UKwhtN118590; Thu, 30 May 2019 21:00:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=2ZygadGx85Zx+HIQJpx3xLx/i7H8pJIY/zzpxwQzgaA=; b=Tdpf0+nkRM3kNVgEIwpjMQmbVlmFW+lFGmDBgTR2ip9ncTtuU7w4BUwyjmKQS/7R2eX5 S33GP25+IQagRXmduNoyLXdI9p3PZTi4WWNt0dhwWRdKc9EQJbluL0abLnqBo+OG7HW5 Juk21Zf29BMy/5k9dK5N1ew4eieua1jyE7SRKcevGAPo8EAJHDdv/TrFIRFSQfha1e6b D+pwFbeChaf6Btk89JTjbM0T7Jl/VyS3N/GeI1yjf7EA6Ay34J6sBh9pqZ0stoQiz346 7tRybGsn/iRWqcJZ4a8nuxW2LZbij942lUpZEhcVRbv8Y5oCi+LrRR9mlqJSXADdF4K9 Lg== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2120.oracle.com with ESMTP id 2spxbqjjk6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 May 2019 21:00:31 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x4UKxx1p142965; Thu, 30 May 2019 21:00:30 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 2srbdy7x27-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 May 2019 21:00:30 +0000 Received: from abhmp0006.oracle.com (abhmp0006.oracle.com [141.146.116.12]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id x4UL0RbB025851; Thu, 30 May 2019 21:00:28 GMT MIME-Version: 1.0 Message-ID: Date: Thu, 30 May 2019 14:00:27 -0700 (PDT) From: Drew Adams To: Juri Linkov Subject: RE: bug#34939: Some minibuffer behaviour is annoying References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> <877ea96i6t.fsf@mail.linkov.net> <0501caa5-0196-45fd-8bc6-8dbb176622ce@default> <87ef4foh6v.fsf@mail.linkov.net> In-Reply-To: <87ef4foh6v.fsf@mail.linkov.net> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4849.0 (x86)] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9273 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=18 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=969 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905300149 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9273 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=18 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905300149 X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org, pinkanon pinkanon , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > > I haven't been following this thread. But it looks > > like this will use `minibuffer-message' for errors > > raised during minibuffer input, and block `message', > > except for logging. Is that right? >=20 > No, it won't block messages. It will block `message', not messages. It will hijack `message' to effect instead `minibuffer-message'. That's not right or fair. Code that calls `message' should get `message' behavior. > It will display messages together with the minibuffer contents > instead of replacing it. Which means that code that _intends_ `message' behavior, which does (temporarily) replace your input in the minibuffer, no longer does that. No way around it - `message' just gets hijacked. It is so _easy_ for any code to explicitly call `minibuffer-message' when it wants that effect. But now you want to make it impossible for code that calls `message' to get `message' behavior. Not needed and not the right thing. You're impoverishing Emacs behavior by replacing two possible behaviors with one. > Currently it requires the user to wait 2 seconds > before the user can see the minibuffer contents again. No, it does not. User input cancels the `message' text. And this is during an overall input reading, remember? And code that calls `message' can invoke `(message nil)' to also cancel the `message' text at _any_ time it deems appropriate. There is no mandatory 2-sec wait, such as you suggest. > Most often, this happens after typing M-n to see if any default values > are available, and it replaces the minibuffer contents with the message > =E2=80=9CEnd of history; no default available=E2=80=9D. If you think there is a _particular_ context or use of `message' that is problematic then fix that. What you're proposing/doing instead is smashing with a sledgehammer. > I have to wait several times > per day for this message to go away. Totally it takes ~1 minute per day, > ~300 minutes (5 hours) per year, and ~50 hours per decade - this is > a whole workweek of just looking at the message and waiting for Godot. Ridiculous exaggeration. I use `M-n' all the time and have never had to wait like that. This is a bad idea. If you want to let users opt in to such a reduction in behaviors then fine, please do create a user option that lets them opt in for that. No one will have a problem with that. From debbugs-submit-bounces@debbugs.gnu.org Thu May 30 17:37:02 2019 Received: (at 34939) by debbugs.gnu.org; 30 May 2019 21:37:02 +0000 Received: from localhost ([127.0.0.1]:34123 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hWSjO-0004PO-5d for submit@debbugs.gnu.org; Thu, 30 May 2019 17:37:02 -0400 Received: from common.maple.relay.mailchannels.net ([23.83.214.38]:34129) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hWSjL-0004Oy-Sq for 34939@debbugs.gnu.org; Thu, 30 May 2019 17:37:01 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 7115B5017CF; Thu, 30 May 2019 21:36:58 +0000 (UTC) Received: from pdx1-sub0-mail-a100.g.dreamhost.com (100-96-11-129.trex.outbound.svc.cluster.local [100.96.11.129]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D502B5022B1; Thu, 30 May 2019 21:36:57 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a100.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 30 May 2019 21:36:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Harbor-Arch: 2490d1102e78c8c7_1559252218262_1393117469 X-MC-Loop-Signature: 1559252218262:376781690 X-MC-Ingress-Time: 1559252218262 Received: from pdx1-sub0-mail-a100.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTP id 456717F59C; Thu, 30 May 2019 14:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=linkov.net; bh=m6ZssYsGTXGbSNHgfTX+RPuE91I=; b= GssQ8ndN9cd+2LadFkqC7EcKmkVeb5sxwnJFWivorKmbRd+xwS4MIiOOo7NURiuc F2Ue2PnW4nqgpRvWrMLlYcJF609t5EnletXMOSSEPrjM1zDzfTZHaM+5X26t/NmM Z9DYYCMJWa1c1A0J8J5fjd6GUKCvGM0axu11nFK0kGQ= Received: from mail.jurta.org (m91-129-96-73.cust.tele2.ee [91.129.96.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a100.g.dreamhost.com (Postfix) with ESMTPSA id 5C67E7F57F; Thu, 30 May 2019 14:36:51 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a100 From: Juri Linkov To: Drew Adams Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> <877ea96i6t.fsf@mail.linkov.net> <0501caa5-0196-45fd-8bc6-8dbb176622ce@default> <87ef4foh6v.fsf@mail.linkov.net> Date: Fri, 31 May 2019 00:35:16 +0300 In-Reply-To: (Drew Adams's message of "Thu, 30 May 2019 14:00:27 -0700 (PDT)") Message-ID: <87tvdbmxrf.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddvledgudeigecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtsehttdertddtredtnecuhfhrohhmpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqnecukfhppeeluddruddvledrleeirdejfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghlohepmhgrihhlrdhjuhhrthgrrdhorhhgpdhinhgvthepledurdduvdelrdeliedrjeefpdhrvghtuhhrnhdqphgrthhhpefluhhrihcunfhinhhkohhvuceojhhurhhisehlihhnkhhovhdrnhgvtheqpdhmrghilhhfrhhomhepjhhurhhisehlihhnkhhovhdrnhgvthdpnhhrtghpthhtohepughrvgifrdgruggrmhhssehorhgrtghlvgdrtghomhenucevlhhushhtvghrufhiiigvpedt X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939 Cc: 34939@debbugs.gnu.org, pinkanon pinkanon , Dmitry Gutov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >> > I haven't been following this thread. But it looks >> > like this will use `minibuffer-message' for errors >> > raised during minibuffer input, and block `message', >> > except for logging. Is that right? >> >> No, it won't block messages. > > It will block `message', not messages. It will hijack > `message' to effect instead `minibuffer-message'. > > That's not right or fair. Code that calls `message' > should get `message' behavior. What `message' are you talking about? Currently `message' is not called during error processing at all. >> Currently it requires the user to wait 2 seconds >> before the user can see the minibuffer contents again. > > No, it does not. User input cancels the `message' > text. It's dangerous and error-prone to type any keys blindly while the minibuffer contents is obscured by the error message. From debbugs-submit-bounces@debbugs.gnu.org Mon Jun 03 16:28:06 2019 Received: (at 34939-done) by debbugs.gnu.org; 3 Jun 2019 20:28:06 +0000 Received: from localhost ([127.0.0.1]:43252 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXtYs-0001iG-4o for submit@debbugs.gnu.org; Mon, 03 Jun 2019 16:28:06 -0400 Received: from aye.elm.relay.mailchannels.net ([23.83.212.6]:45929) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hXtYp-0001i7-Mv for 34939-done@debbugs.gnu.org; Mon, 03 Jun 2019 16:28:04 -0400 X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 84B545E2F2D; Mon, 3 Jun 2019 20:28:01 +0000 (UTC) Received: from pdx1-sub0-mail-a11.g.dreamhost.com (100-96-88-48.trex.outbound.svc.cluster.local [100.96.88.48]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id E962F5E2E39; Mon, 3 Jun 2019 20:28:00 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|jurta@jurta.org Received: from pdx1-sub0-mail-a11.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 03 Jun 2019 20:28:01 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|jurta@jurta.org X-MailChannels-Auth-Id: dreamhost X-Company-Print: 71df55e40f98e786_1559593681384_3198030284 X-MC-Loop-Signature: 1559593681384:3589133251 X-MC-Ingress-Time: 1559593681384 Received: from pdx1-sub0-mail-a11.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTP id 476B0809AC; Mon, 3 Jun 2019 13:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=linkov.net; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=linkov.net; bh=x50gzm KZ25JTacxQjWwRTEnfX7E=; b=ut+SVYEr+D4Q1KIf/bdPp0E7k4+dG121oaN3oX JKlWLwMHx991fjtz/F0jU5GbMfPxf7CBwzuAFaq/oDAA8DOS83DU51ET6ZS6u7WH ZQ16Fmpq09WiDcGAcCaT71jWhlAdm8tYNcS+eAgg3viYYa3eCdAilCmJD7VZK/B9 HEtN8= Received: from mail.jurta.org (m91-129-96-73.cust.tele2.ee [91.129.96.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jurta@jurta.org) by pdx1-sub0-mail-a11.g.dreamhost.com (Postfix) with ESMTPSA id E7533809A6; Mon, 3 Jun 2019 13:27:53 -0700 (PDT) X-DH-BACKEND: pdx1-sub0-mail-a11 From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#34939: Some minibuffer behaviour is annoying Organization: LINKOV.NET References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> <877ea96i6t.fsf@mail.linkov.net> Date: Mon, 03 Jun 2019 23:27:32 +0300 In-Reply-To: <877ea96i6t.fsf@mail.linkov.net> (Juri Linkov's message of "Thu, 30 May 2019 00:53:46 +0300") Message-ID: <87ef4aza6j.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrudefjedgudegjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffuohhfffgjkfgfgggtgfesthekredttderjeenucfhrhhomheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqeenucfkphepledurdduvdelrdeliedrjeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehmrghilhdrjhhurhhtrgdrohhrghdpihhnvghtpeeluddruddvledrleeirdejfedprhgvthhurhhnqdhprghthheplfhurhhiucfnihhnkhhovhcuoehjuhhriheslhhinhhkohhvrdhnvghtqedpmhgrihhlfhhrohhmpehjuhhriheslhhinhhkohhvrdhnvghtpdhnrhgtphhtthhopegughhuthhovheshigrnhguvgigrdhruhenucevlhhushhtvghrufhiiigvpedt Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939-done Cc: pinkanon pinkanon , 34939-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) >>>> So um, what's the best way to make this behavior the default? >>> >>> This is a nice behavior but the problem is that overriding >>> command-error-function also removes other useful default features >>> such as logging error messages to the *Messages* buffer >>> (see more at =E2=80=98print_error_message=E2=80=99). >> >> Could we first print it and then call minibuffer-message? > > more user-friendly displaying error messages in the minibuffer: With no more comments received, pushed to master and closed. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 04 11:15:56 2019 Received: (at 34939-done) by debbugs.gnu.org; 4 Jun 2019 15:15:56 +0000 Received: from localhost ([127.0.0.1]:45605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYBAK-0002lY-Ap for submit@debbugs.gnu.org; Tue, 04 Jun 2019 11:15:56 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:36707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hYBAJ-0002lK-5p for 34939-done@debbugs.gnu.org; Tue, 04 Jun 2019 11:15:55 -0400 Received: by mail-wr1-f42.google.com with SMTP id n4so13216102wrs.3 for <34939-done@debbugs.gnu.org>; Tue, 04 Jun 2019 08:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=y85IsJVz0GbcbuXlBQyEhZh5DaBw/iL0TYF4XqatDNM=; b=haUXfPA+qvuyUix5tsYJyrmxJFJpT4lzqIxwHg+KoJqz+kXPkqB8jzyht1C1MCT8sH azPWdP0EVZuZ7i6FrdS8snzNqBE6sb5j0xW8BoivN/T1tb0YgX+pH7DEny9AfbUNiR1c KYOcQdQWxve1+WdIZYdivPyZVjN/EizvjVlvMW+CaGadVEWvUKjNgA8195Wr00t8skqA QT+JvmzN7NrBRz8WWhPEfe/MZHKt9oLICd/J0szwFL952/OH7VOSeSiF33/l8kziCIDh LZsegHeQKRXSucekREhGSiVikq9zEXvId6dHLyCIk7wS+vsgq6kKmLqR3oZ4+P6f2Wuc rgRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=y85IsJVz0GbcbuXlBQyEhZh5DaBw/iL0TYF4XqatDNM=; b=eVD7ww9C5UODKSHsOCo0Pf9NKjLHAVmMKxx3CvDxVgkDFIdZoaIe0O6gX7BIlCNHWR Q5O2Jdbs2VK5P0fZsTeyuw8JR3B95TdyyLPc9Y6APoxD/kH+dJihPboURxN6L7DIIOeU P7QDb7l8dak7AbhFm4I4AIiNymDhR4yX8QilwazR/CHZkuG3Bggwoz+ZBUuBPGJGHhV5 Jf0kBe3ar4av9qbkb10az1rzSiEQmlGNFJauP1JpShKFa236YvAuTOAZMA922EE0WI94 9Gbs3bRiVx0jryyYtaIWH8XvKFLu6cpeaLLbVOnqhpPwHSvRbPbqqRgmGGPPyO4RVktY kbrg== X-Gm-Message-State: APjAAAXEnbCvUA8IMiYtXllCBu+5FosSaUSFW7lVES8jmqLPdOB3+Pfr PcFFE/vALFV3vMOXaAD1d9g8XUPV X-Google-Smtp-Source: APXvYqxaRnSo/BQABTsmDEckpDE9ucMXlo+tEgKAwAQBObUCXqKHDQ/wCnFya0wPsH/pFuMuhKB6RQ== X-Received: by 2002:a5d:6b12:: with SMTP id v18mr21202712wrw.306.1559661348924; Tue, 04 Jun 2019 08:15:48 -0700 (PDT) Received: from [192.168.0.195] ([109.110.245.170]) by smtp.googlemail.com with ESMTPSA id p11sm12917840wrs.5.2019.06.04.08.15.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Jun 2019 08:15:44 -0700 (PDT) Subject: Re: bug#34939: Some minibuffer behaviour is annoying To: Juri Linkov References: <1879851553195601@myt3-2475c4d2af83.qloud-c.yandex.net> <87a7hasuz4.fsf@mail.linkov.net> <87imtvd57d.fsf@mail.linkov.net> <877ea96i6t.fsf@mail.linkov.net> <87ef4aza6j.fsf@mail.linkov.net> From: Dmitry Gutov Message-ID: <68ecd024-7fd1-a369-8bdc-d77e3992db26@yandex.ru> Date: Tue, 4 Jun 2019 18:15:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <87ef4aza6j.fsf@mail.linkov.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34939-done Cc: pinkanon pinkanon , 34939-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On 03.06.2019 23:27, Juri Linkov wrote: > With no more comments received, pushed to master and closed. Thank you Juri. But you pushed a different patch than the one you showed here (1-to-1 rewrite of the C function ‘print_error_message’), didn't you? From unknown Fri Jun 13 10:12:08 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 03 Jul 2019 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator