From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el(read-regexp): Let-bind `default' to the first Date: Fri, 8 Mar 2013 10:53:54 -0800 Message-ID: <812C4DC04A0D46B8AC5B11170E06A75C@us.oracle.com> References: <877glsyecw.fsf@gmail.com> <87621cfhff.fsf@mail.jurta.org><87zjykygjk.fsf@mail.jurta.org> <87vc92gi37.fsf@gmail.com><1751CEB23B214A3AADCCFD9F007425DE@us.oracle.com><87li9xer9u.fsf@mail.jurta.org> <8738w5n3rg.fsf@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1362768880 22611 80.91.229.3 (8 Mar 2013 18:54:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 18:54:40 +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 Fri Mar 08 19:55:04 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 1UE2RV-000304-FQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Mar 2013 19:54:57 +0100 Original-Received: from localhost ([::1]:59026 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2R9-00087W-Kd for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Mar 2013 13:54:35 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:60498) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2R2-00087O-OR for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:54:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE2Qx-00075J-Rc for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:54:28 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35774) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2Qx-00075F-NR for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:54:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UE2RZ-0006cB-UM for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Mar 2013 18:55:01 +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.136276889325413 (code B ref 13687); Fri, 08 Mar 2013 18:55:01 +0000 Original-Received: (at 13687) by debbugs.gnu.org; 8 Mar 2013 18:54:53 +0000 Original-Received: from localhost ([127.0.0.1]:39883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE2RQ-0006bp-An for submit@debbugs.gnu.org; Fri, 08 Mar 2013 13:54:52 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:46219) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE2RN-0006bb-La for 13687@debbugs.gnu.org; Fri, 08 Mar 2013 13:54:50 -0500 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r28Is4gn012361 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Mar 2013 18:54:04 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r28Is3W8018084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Mar 2013 18:54:03 GMT Original-Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r28Is3YK020027; Fri, 8 Mar 2013 12:54:03 -0600 Original-Received: from dradamslap1 (/10.159.244.176) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Mar 2013 10:54:02 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <8738w5n3rg.fsf@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4cKvl5oHOt+wqlRHKqNjUHS6XgcQAAKUag X-Source-IP: acsinet22.oracle.com [141.146.126.238] 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:72238 Archived-At: > > E.g., in the code I cited, if a user does not want the same > > defaulting behavior for commands `occur', `how-many', etc., > > she can set option `search/replace-default-fn' to a function > > that distinguishes them (e.g., using `this-command', as > > Jambunathan suggested). > > Interesting suggestion there. > > This makes me think that there is no need for multiple > `hi-lock-read-regexp-defaults-function' and a separate > `occur-read-regexp-defaults-function' etc. But a single > `read-regexp-defaults-function' that cases on `this-command'. The question, as I said, is whether it makes sense, for the particular commands that we group to use the same option, to provide the default regexp (or other string) in the same way. I can't speak to whether that is the case for hi-lock, occur, etc. But if it is true, then yes, a single option for such a group of commands makes sense. > The function can return a symbol token like `t' for > `this-command's which it doesn't want to meddle with but > return nil or a regexp or list of regexps for commands it > wants to insinuate. That is not what I suggested. I suggested that the option value be a function that returns a string to use as the default value when reading user input. What I said in the passage you cite is that that function (the value of the option) could, if the user so wants, itself test `this-command' and provide a different string depending on the current command. > Is there any problem with this > `read-regexp-defaults-function' approach? I think you're suggesting that the option value be a function that returns t or nil, instead of returning a default-value string. It's not clear to me how a given command such as `occur' would make use of that Boolean return value. As I noted before, I would not _encourage_ users to use a dispatching function as the option value, but that would not (could not) be prevented. They can do anything they want using any function they want. The out-of-the-box design should make a reasonable assumption about which commands to group (i.e., which should use the same option). If it is expected that some command that reads a regexp would generally be better off with a different defaulting behavior, then that command should not use the group option. It could use its own, similar option, with a different default option value (a different default-value-providing function). Or it could hard-code its defaulting, or whatever. The use of a function to dispatch according to the current command should be exceptional, IMO - only a fallback possibility and not something to be encouraged.