From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jambunathan K Newsgroups: gmane.emacs.bugs Subject: bug#13687: /srv/bzr/emacs/trunk r111878: * lisp/replace.el(read-regexp): Let-bind `default' to the first Date: Sat, 09 Mar 2013 00:33:56 +0530 Message-ID: <87obetww6b.fsf@gmail.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> <812C4DC04A0D46B8AC5B11170E06A75C@us.oracle.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1362769475 27623 80.91.229.3 (8 Mar 2013 19:04:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 19:04:35 +0000 (UTC) Cc: 13687@debbugs.gnu.org To: "Drew Adams" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 08 20:04:59 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 1UE2bD-00076e-BQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Mar 2013 20:04:59 +0100 Original-Received: from localhost ([::1]:33543 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2ar-0002Mv-Em for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Mar 2013 14:04:37 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:34261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2aj-0002Mp-ON for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 14:04:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE2ae-0002JP-5e for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 14:04:29 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE2ae-0002JL-21 for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 14:04:24 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UE2bG-0007lD-G8 for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 14:05:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jambunathan K Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 08 Mar 2013 19:05: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.136276948429807 (code B ref 13687); Fri, 08 Mar 2013 19:05:02 +0000 Original-Received: (at 13687) by debbugs.gnu.org; 8 Mar 2013 19:04:44 +0000 Original-Received: from localhost ([127.0.0.1]:39911 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE2ax-0007ki-H0 for submit@debbugs.gnu.org; Fri, 08 Mar 2013 14:04:43 -0500 Original-Received: from mail-pb0-f52.google.com ([209.85.160.52]:42019) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE2au-0007kV-ST for 13687@debbugs.gnu.org; Fri, 08 Mar 2013 14:04:41 -0500 Original-Received: by mail-pb0-f52.google.com with SMTP id ma3so1482869pbc.11 for <13687@debbugs.gnu.org>; Fri, 08 Mar 2013 11:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=Wgr4h239zvgm0KFgVSMvZsMIEit5lLgMLxLQUwtKzAs=; b=IjHSOHPqbAmFjpCfhkHEazK8qjmoGgAxw9MSL4L9A0lpxhc5rM1JRlLHqI7tboUNvA jH0Z8OznhLBmK0UFRGEQtOzWLMj0iAX2Luluiv0HUIsoXbv4a3R74xfLLt4n+nKauA4s N1SCOaRcJ+yS3VbxpnOSnv2pkXKlmNFwTc/WSuaJUBJGX2FvKT+Cc/OgAlkn0hsTRcVQ 4PfbGab8auvZ2Qx0EBAfgLn9MTChVJLwgUn6wa66Olf+Jg0hAIL4WVSCys6XAiVkDhxP 8ZYBxwFluqB1ggrQ0JnlzRkgXM/bUI+9uo5xXYlYmqKJwN3f1T4Y/Vlo7TvbMFEmvAPS I8Dw== X-Received: by 10.68.196.129 with SMTP id im1mr4876133pbc.206.1362769436278; Fri, 08 Mar 2013 11:03:56 -0800 (PST) Original-Received: from debian-6.05 ([115.241.18.198]) by mx.google.com with ESMTPS id tm1sm6440995pbc.11.2013.03.08.11.03.52 (version=TLSv1.1 cipher=RC4-SHA bits=128/128); Fri, 08 Mar 2013 11:03:55 -0800 (PST) In-Reply-To: <812C4DC04A0D46B8AC5B11170E06A75C@us.oracle.com> (Drew Adams's message of "Fri, 8 Mar 2013 10:53:54 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) 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:72241 Archived-At: Suspend your judgement. I don't like to discuss (or rather I cannot discuss) in abstract. It is so error prone. I will show my wares tomorrow. "Drew Adams" writes: >> > 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.