From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#48134: When sitting on top of a M-x item in the manual Date: Mon, 03 May 2021 11:00:44 +0200 Message-ID: <87zgxcchtv.fsf@gnus.org> References: <87fsz73t9z.8.fsf@jidanni.org> <87sg36rfrw.fsf@gmail.com> <87pmyaodji.5.fsf@jidanni.org> <87czu9li9o.fsf@gnus.org> <875z01jewz.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40225"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: =?UTF-8?Q?=E7=A9=8D=E4=B8=B9=E5=B0=BC?= Dan Jacobson , 48134@debbugs.gnu.org To: =?UTF-8?Q?K=C3=A9vin?= Le Gouguec Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon May 03 11:01:50 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldUSc-000AF3-9S for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 May 2021 11:01:50 +0200 Original-Received: from localhost ([::1]:45236 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ldUSb-0004ES-3A for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 03 May 2021 05:01:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ldURq-0004CV-4V for bug-gnu-emacs@gnu.org; Mon, 03 May 2021 05:01:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34654) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ldURp-0005jq-S5 for bug-gnu-emacs@gnu.org; Mon, 03 May 2021 05:01:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ldURp-0000DF-OI for bug-gnu-emacs@gnu.org; Mon, 03 May 2021 05:01:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 May 2021 09:01:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48134 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 48134-submit@debbugs.gnu.org id=B48134.1620032459667 (code B ref 48134); Mon, 03 May 2021 09:01:01 +0000 Original-Received: (at 48134) by debbugs.gnu.org; 3 May 2021 09:00:59 +0000 Original-Received: from localhost ([127.0.0.1]:46200 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldURn-0000AM-3c for submit@debbugs.gnu.org; Mon, 03 May 2021 05:00:59 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:39346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ldURi-0008TE-9A for 48134@debbugs.gnu.org; Mon, 03 May 2021 05:00:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Imd5GcsWAcvayz0jL9TFN0SQXWBBU5aJ/3uORTycL2A=; b=DTQN+su0CTMWcPewPIeSr5ld/A 0ao9+eK2XCjd2LTqSXPVtMo7uhwL/oYLIYTBWq/D6w3f6KDkp6oXxnT2gUUp4l9tr4QO3N1vNCOVB Qy0WgWDRw/UFFxXGfIgSbFSvl9fYMP6KSxa7otEeHnzjyCNHlD50iCtpTKZzAQE9K8NY=; Original-Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ldURZ-0002kG-2P; Mon, 03 May 2021 11:00:47 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEX18e6IenU7KCq6 qqP////NhAZvAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+UFAwgtITJYGwYAAAF1SURBVDjLnZRrloMg DIVD2YAJGzCwgdDsf29zA45infnT9Gg1H3kSJPpCWOoiysyiAwy91op3KLkQveoJtIm6O2V3I6oL 4KoFYOjTAgaDCfQOT3egbPjbwtPiSmrTZuMpfQDVsXbKLXj7A6jRG87JUcfdAu87kXWfIh+AjvQW C1wnuLmq/wFcrfOGarxH/DVGo7Q9LUquuyWT9wN43ayb9Bp1NFkAGpJ2YXkAaVT22kbheoENd9eC taOfi4UBNI+tD/a60rWuljmAyplViXidkmEi5tasLXFKvoUuVr0WgHGiXeoeJbZ0AI8oeEIG6rFv 7zmi1V7TokSmcraEIyR6mC2y6PyxH5hbnW2W+jlwI7nN+QEEHSyWDXs1gYxTAAs0tzg0uU+gA7Sw Mh+L0wUQOqatxWSdoHicgHASwxa36YpxKHCSMn4oPl8xmOdcTgNbY/ipyTdQfkEocdbyAU5PA4T4 BDeDKWkNbvRrmQ+LNz/lm0/PD+2LX9+nW6Z9AAAAJXRFWHRkYXRlOmNyZWF0ZQAyMDIxLTA1LTAz VDA4OjQ1OjMzKzAwOjAwv2JNrwAAACV0RVh0ZGF0ZTptb2RpZnkAMjAyMS0wNS0wM1QwODo0NToz MyswMDowMM4/9RMAAAAASUVORK5CYII= X-Now-Playing: The Style Council's _The Complete Adventures (1)_: "Me Ship Came In!" In-Reply-To: <875z01jewz.fsf@gmail.com> ("=?UTF-8?Q?K=C3=A9vin?= Le Gouguec"'s message of "Sun, 02 May 2021 18:09:32 +0200") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:205484 Archived-At: K=C3=A9vin Le Gouguec writes: > I see that (info "(emacs) Minibuffer History") mentions its DWIM > behaviour and gives examples for filename prompts, but given how > ubiquitous and useful M-n is, I wonder if we couldn't do more to > advertise it. Yeah, it is perhaps a too-hidden feature. > I realize that this would probably not be trivial to implement though. > Looking up "future history in minibuffer input" in the Elisp manual > brought me to (info "(elisp) Text from Minibuffer"), which lured me into > thinking that this hypothetical hint could simply be added in > read-from-minibuffer, by looking at the DEFAULT argument; a stroll > through read-extended-command taught me that some functions compute > their "future history" dynamically with minibuffer-default-add-function, > which I guess complicates things a bit? Yes, in general we don't really know whether we have anything in the future history until the user hits `M-n', I think? We could say something in the instances where we do know in advance, but users might infer from that that there's nothing in `M-n' if the message doesn't appear. And saying "M-n might reveal something" isn't very helpful either. --=20 (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no