From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.devel Subject: Re: read-regexp Date: Sun, 19 Oct 2008 02:29:57 +0300 Organization: JURTA Message-ID: <87r66dmr66.fsf@jurta.org> References: <87iqrp7wgm.fsf@jurta.org> <87ljwlr8ch.fsf@jurta.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1224373800 4903 80.91.229.12 (18 Oct 2008 23:50:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Oct 2008 23:50:00 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Oct 19 01:51:04 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KrLZV-0004Dc-Cn for ged-emacs-devel@m.gmane.org; Sun, 19 Oct 2008 01:51:01 +0200 Original-Received: from localhost ([127.0.0.1]:55854 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrLYQ-0004jk-F7 for ged-emacs-devel@m.gmane.org; Sat, 18 Oct 2008 19:49:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KrLXg-0004Lo-4Y for emacs-devel@gnu.org; Sat, 18 Oct 2008 19:49:08 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KrLXe-0004LA-Ms for emacs-devel@gnu.org; Sat, 18 Oct 2008 19:49:07 -0400 Original-Received: from [199.232.76.173] (port=60452 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KrLXe-0004L4-Ei for emacs-devel@gnu.org; Sat, 18 Oct 2008 19:49:06 -0400 Original-Received: from relay02.kiev.sovam.com ([62.64.120.197]:53534) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KrLXc-0007g0-Do; Sat, 18 Oct 2008 19:49:04 -0400 Original-Received: from [83.170.232.243] (helo=smtp.svitonline.com) by relay02.kiev.sovam.com with esmtp (Exim 4.67) (envelope-from ) id 1KrLXZ-000KxR-0r; Sun, 19 Oct 2008 02:49:01 +0300 In-Reply-To: (Stefan Monnier's message of "Sat, 18 Oct 2008 17:47:52 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (x86_64-pc-linux-gnu) X-Scanner-Signature: d0b3bc0b24c4067239780ad28ae5b444 X-DrWeb-checked: yes X-SpamTest-Envelope-From: juri@jurta.org X-SpamTest-Group-ID: 00000000 X-SpamTest-Header: Trusted X-SpamTest-Info: Profiles 5422 [Oct 16 2008] X-SpamTest-Info: {received from trusted relay: common white list} X-SpamTest-Info: {HEADERS: header Content-Type found without required header Content-Transfer-Encoding} X-SpamTest-Method: white ip list X-SpamTest-Rate: 10 X-SpamTest-Status: Trusted X-SpamTest-Status-Extended: trusted X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0278], KAS30/Release X-detected-operating-system: by monty-python.gnu.org: FreeBSD 6.x (1) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:104616 Archived-At: >>>> The problem is in the ambiguous name of the argument DEFAULT. >>>> It was intended to provide exactly the same functionality as the >>>> argument STRING-DESCRIBING-DEFAULT of the function `read-face-name', >>>> i.e. to display in the minibuffer prompt what default the function >>>> will use if the user types RET. >>> >>> The question is rather: why isn't that string available via M-n as >>> defaults usually do? I think adding that regexp to M-n is a better >>> option, and that makes the use of the name `default' >>> completely justified. > >> This string is not available via M-n due to historical requirements of >> `occur'. It used to display the last element of regexp-history >> in the prompt and use it when the user types RET. Other commands >> that use read-regexp historically don't require such a string. > > I still don't understand. Your occur explanation explains why it's > displayed in the prompt and used as default value, but not why it's not > in the M-n. It's not in the M-n because the last history element is available in the history list via M-p. Since the same value is already available via M-p and RET, we can avoid putting it to the third place - M-n, thus making access to other values on M-n more easy with less keystrokes. -- Juri Linkov http://www.jurta.org/emacs/