From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el (read-regexp): Let-bind `default' to the first Date: Thu, 28 Feb 2013 20:12:30 +0200 Organization: JURTA Message-ID: <87621cfhff.fsf@mail.jurta.org> References: <877glsyecw.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1362075373 30607 80.91.229.3 (28 Feb 2013 18:16:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Feb 2013 18:16:13 +0000 (UTC) Cc: 13687@debbugs.gnu.org To: Jambunathan K Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Feb 28 19:16:35 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UB81y-0005Nr-0N for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Feb 2013 19:16:34 +0100 Original-Received: from localhost ([::1]:41194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB81c-0005sP-Vm for geb-bug-gnu-emacs@m.gmane.org; Thu, 28 Feb 2013 13:16:12 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:38626) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB81X-0005rG-QM for bug-gnu-emacs@gnu.org; Thu, 28 Feb 2013 13:16:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UB81V-0007Fi-IO for bug-gnu-emacs@gnu.org; Thu, 28 Feb 2013 13:16:07 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:51107) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UB81V-0007FZ-EZ for bug-gnu-emacs@gnu.org; Thu, 28 Feb 2013 13:16:05 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UB83O-0005BH-8r for bug-gnu-emacs@gnu.org; Thu, 28 Feb 2013 13:18:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Feb 2013 18:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13687 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 13687-submit@debbugs.gnu.org id=B13687.136207543219843 (code B ref 13687); Thu, 28 Feb 2013 18:18:02 +0000 Original-Received: (at 13687) by debbugs.gnu.org; 28 Feb 2013 18:17:12 +0000 Original-Received: from localhost ([127.0.0.1]:56571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UB82a-00059z-2A for submit@debbugs.gnu.org; Thu, 28 Feb 2013 13:17:12 -0500 Original-Received: from ps18281.dreamhost.com ([69.163.218.105]:47301 helo=ps18281.dreamhostps.com) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UB82X-00059r-EC for 13687@debbugs.gnu.org; Thu, 28 Feb 2013 13:17:11 -0500 Original-Received: from localhost (ps18281.dreamhostps.com [69.163.218.105]) by ps18281.dreamhostps.com (Postfix) with ESMTP id 3C29C258B92900; Thu, 28 Feb 2013 10:15:09 -0800 (PST) In-Reply-To: <877glsyecw.fsf@gmail.com> (Jambunathan K.'s message of "Thu, 28 Feb 2013 15:00:55 +0530") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (x86_64-pc-linux-gnu) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:71961 Archived-At: > emacs -Q > M-s h r > > I find the following error > > ,---- > | Debugger entered--Lisp error: (error "Regexp cannot match an empty string") > | signal(error ("Regexp cannot match an empty string")) > | error("Regexp cannot match an empty string") > | hi-lock-regexp-okay("") > | byte-code("..." [regexp-history hi-lock-regexp-okay read-regexp "Regexp to highlight" hi-lock-read-face-name] 4) > | call-interactively(highlight-regexp nil nil) > | command-execute(highlight-regexp) > `---- > > So, if one does > (read-regexp something) ;; something is nil or evals to nil > > what should the interpretation be. > > With your change, a `nil' default will provide an empty string as input > and force user to enter a regexp or rely on M-n. > > We seem to be bumping in to each other in this area. Comments ...? > > ,---- Stefan @ http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13687#11 > | I disagree: read-regexp is a generic function which can be used in > | various contexts, some of which might not care at all about the text > | around point. So the caller should have control over the first default > | (of course, it's perfectly fine to always add the current tag in the > | subsequent defaults). > | > | This said your patch seems to leave the caller's provided `defaults' at > | the beginning of the minibuffer's `defaults', so I think your patch is > | fine, feel free to install it. > `---- > > I am wondering how we can resolve the contex-free read-regexp and > context-dependent regexp. Any suggestions? It's a responsibility of the caller to provide the default value. `M-s h r' (`highlight-regexp') provides the default value as `(car regexp-history)'. When it is called the first time after `emacs -Q', the history is empty, so its default value is nil (this fact is indicated with missing default value in the prompt, so the user is aware that RET with empty input will do nothing.) When `highlight-regexp' is called the second time and more, it gets the default value from `regexp-history', so you can't provide the tag at point as the default for later invocations of `highlight-regexp' anyway. So the question is: should the default value in the caller `highlight-regexp' be changed from `(car regexp-history)' to code that gets the tag at point? You could propose such a change, but since it changes the long-standing behavior, expect some disagreement (not from me :-)