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: Sat, 9 Mar 2013 07:08:54 -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><8738w5n3rg.fsf@gmail.com> <87d2v9rmcl.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 1362841830 12319 80.91.229.3 (9 Mar 2013 15:10:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Mar 2013 15:10:30 +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 Sat Mar 09 16:10:55 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 1UELQE-0000zk-5c for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Mar 2013 16:10:54 +0100 Original-Received: from localhost ([::1]:52720 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UELPs-0006Vk-4x for geb-bug-gnu-emacs@m.gmane.org; Sat, 09 Mar 2013 10:10:32 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:50861) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UELPk-0006VR-Rh for bug-gnu-emacs@gnu.org; Sat, 09 Mar 2013 10:10:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UELPe-0003Ev-Lx for bug-gnu-emacs@gnu.org; Sat, 09 Mar 2013 10:10:24 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:37793) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UELPe-0003E0-JL for bug-gnu-emacs@gnu.org; Sat, 09 Mar 2013 10:10:18 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1UELQL-0004aS-Jm for bug-gnu-emacs@gnu.org; Sat, 09 Mar 2013 10:11: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: Sat, 09 Mar 2013 15:11: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.136284180817572 (code B ref 13687); Sat, 09 Mar 2013 15:11:01 +0000 Original-Received: (at 13687) by debbugs.gnu.org; 9 Mar 2013 15:10:08 +0000 Original-Received: from localhost ([127.0.0.1]:41901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UELPQ-0004ZJ-CB for submit@debbugs.gnu.org; Sat, 09 Mar 2013 10:10:08 -0500 Original-Received: from userp1040.oracle.com ([156.151.31.81]:29112) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1UELPJ-0004Ye-UY for 13687@debbugs.gnu.org; Sat, 09 Mar 2013 10:10:02 -0500 Original-Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r29F970o028507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 9 Mar 2013 15:09:08 GMT Original-Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r29F978j000663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Mar 2013 15:09:07 GMT Original-Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r29F95uV012030; Sat, 9 Mar 2013 09:09:05 -0600 Original-Received: from dradamslap1 (/71.202.147.44) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 09 Mar 2013 07:09:05 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <87d2v9rmcl.fsf@gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Thread-Index: Ac4coreLtZlsGJ6oTRCNIzhLqvIQpgAMVRQQ X-Source-IP: ucsinet22.oracle.com [156.151.31.94] 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:72277 Archived-At: > EXPERIMENTAL and ABANDONED PATCH > > Use of `this-command' is very fragile and flaky. No, but it is somewhat fragile. > Consider `multi-occur-in-matching-buffers' which does multiple > `read-regexp' - one for the buffers and one for the actual > regexp. It is not possible to return a two different regexps > for the same `this-command'. You don't need to. If a user needs to test for `multi-occur-in-matching-buffers' via `this-command' then s?he can do that and act accordingly. No need for general code that tries to second-guess things. > Interestingly, I am attaching a long from *Messages* buffer > and it looks like `this-command' is not reliable (Do you see > `exit-minibuffer' in the logs.) See below. > So `this-command' could work for simple commands like highlighting > commands but will be flaky to be applied in general. > > Anyways good to experiment and see where an idea takes us... As I said, we should not encourage this. And yes, any use of `last-command' or `this-command' is somewhat fragile, because some functions intentionally change their values. And yes, comparing functions is also problematic in general. No eta reduction, for one thing: (equal (lambda (x) (car x)) 'car). See what I wrote earlier. Let users choose any string-returning function they want to use for defaulting. If a user wants to use a function that conditions its return value on `this-command', s?he can always do so. But there is no reason to encourage that. Any set of commands that we design to use the same defaulting choice (via the same user option) should be a cohesive group: the same choice should make sense across that set. If you have one or more commands that do not fit that, then give them their own defaulting options (grouping again, where appropriate). There is nothing new here - just common sense. The solution is simple, IMO. > Interestingly, I am attaching a long from *Messages* buffer > and it looks like `this-command' is not reliable (Do you see > `exit-minibuffer' in the logs.) > > cmd: exit-minibuffer defaults: nil Your code checks only (eq user-defaults t). When `user-defaults' is nil, this returns nil.