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:16:14 -0800 Message-ID: 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> 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 1362766703 1388 80.91.229.3 (8 Mar 2013 18:18:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 18:18:23 +0000 (UTC) Cc: 'Jambunathan K' , 13687@debbugs.gnu.org To: "'Juri Linkov'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Mar 08 19:18:43 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 1UE1sJ-0007M4-L8 for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Mar 2013 19:18:35 +0100 Original-Received: from localhost ([::1]:49878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE1rx-0006fs-Oc for geb-bug-gnu-emacs@m.gmane.org; Fri, 08 Mar 2013 13:18:13 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50859) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE1ra-0006c6-F3 for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:18:11 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UE1r9-0001pN-Kd for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:17:50 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UE1r9-0001pE-Ei for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:17:23 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UE1rl-0005lj-Of for bug-gnu-emacs@gnu.org; Fri, 08 Mar 2013 13:18: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:18: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.136276663922120 (code B ref 13687); Fri, 08 Mar 2013 18:18:01 +0000 Original-Received: (at 13687) by debbugs.gnu.org; 8 Mar 2013 18:17:19 +0000 Original-Received: from localhost ([127.0.0.1]:39835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE1r1-0005ke-Hc for submit@debbugs.gnu.org; Fri, 08 Mar 2013 13:17:19 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:25594) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UE1qv-0005kM-1I for 13687@debbugs.gnu.org; Fri, 08 Mar 2013 13:17:14 -0500 Original-Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r28IGO5D002387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 8 Mar 2013 18:16:24 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r28IGNTo028719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Mar 2013 18:16:23 GMT Original-Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r28IGMDT022672; Fri, 8 Mar 2013 12:16:23 -0600 Original-Received: from dradamslap1 (/10.159.244.176) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Mar 2013 10:16:22 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87li9xer9u.fsf@mail.jurta.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4cItWxQ0FU7zT2S5aIFFYpwxGt7wAAN3UA X-Source-IP: ucsinet21.oracle.com [156.151.31.93] 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:72236 Archived-At: > > Let the command decide its own defaulting. Individual > > commands that read the minibuffer should control such defaulting, > > at the point of call. > > Since when the command commands the user, and not other way round? Straw man. No one proposed that the command command the user. It is normal, typical, and traditional, for a command that calls a function to read input, to provide whatever defaults are appropriate. Appropriate for that particular command. And of course appropriate for a user who chooses to invoke that command. > Perhaps you missed the whole thread, but see what the users > are forced to use > http://stackoverflow.com/questions/15161592/make-emacs-rgrep-default-to-last-sea rch-term-rather-than-word-at-point > in the absence of customizable options. Did you hear me propose to get rid of customizable options? FWIW, I see nothing wrong with the request of that user. What I suggested would be a misguided approach is to have an option that tries to configure defaulting for a whole slew of possibly unrelated commands. That's all. I pointed to an alternative approach that provides an option specific to a command or to a group of related commands, the option value being a default-value-providing function. All commands in the group use the same defaulting function. I even mentioned that if some user wanted to be more specific about defaulting behavior within the group of related commands, s?he could always do so by providing as the option value a function that dispatches among the commands - just like option `minibuffer-defaults'. The design would not encourage that, but it would anyway allow for it. 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). But a priori (according to the developer of replace+.el), a user would want the same defaulting behavior for such commands, and that's why they were grouped to use a common option. If it was thought that most users would want separate defaulting behavior here, then the design would reflect that, providing separate options. The point is to keep things narrowed in focus, promoting modularity. I would group some commands together for convenience in customizing their defaulting behavior, but only if such grouping (common behavior) made sense. You would apparently group any and all commands - across the entire Emacs spectrum, providing a single option (`minibuffer-defaults') that dispatches according to the given command. IMO, that's not the best approach; that's all. > > FWIW, in my code I do something that I'm guessing might be > > similar to the _effect_ you want, but I stay completely away > > from command lookup/dispatching. > > There is no command lookup/dispatching since Jambunathan implements > the third variant, and not the second cited above. Sorry, dunno what that means. I was writing only in reaction to the (your?) proposed `minibuffer-defaults' option that is an alist of (COMMAND . FUNCTION) entries and that seemed to me to dispatch defaulting based on the COMMAND. > > I have a user option, `search/replace-default-fn', whose > > value (a function) provides the default value(s) for functions > > `query-replace', `occur', `how-many', `flush-lines',... > > Your `search/replace-default-fn' is exactly the same thing as > `occur-read-regexp-defaults-function', so why do you object? See above. 1. I admitted that I did not follow the thread. 2. I made clear that I was commenting only on the proposal of a `minibuffer-defaults' option that dispatches defaulting according to the command. 3. Wrt that proposal I suggested an alternative approach. If such an alternative is what is really being used, wunderbar.