From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: find-file-noselect needs save-match-data Date: Wed, 06 Jun 2007 09:25:13 +0200 Message-ID: <86bqftlf3a.fsf@lola.quinscape.zz> References: <46665B1D.8000005@gmx.at> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181114737 15633 80.91.229.12 (6 Jun 2007 07:25:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2007 07:25:37 +0000 (UTC) Cc: Herbert Euler , monnier@iro.umontreal.ca, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 06 09:25:32 2007 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Hvptb-0006At-8q for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2007 09:25:31 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HvptZ-0000Iy-Bx for ged-emacs-devel@m.gmane.org; Wed, 06 Jun 2007 03:25:29 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1HvptV-0000Iq-Eh for emacs-devel@gnu.org; Wed, 06 Jun 2007 03:25:25 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1HvptR-0000IN-TU for emacs-devel@gnu.org; Wed, 06 Jun 2007 03:25:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1HvptR-0000II-OS for emacs-devel@gnu.org; Wed, 06 Jun 2007 03:25:21 -0400 Original-Received: from pc3.berlin.powerweb.de ([62.67.228.11]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1HvptQ-0001wY-2K for emacs-devel@gnu.org; Wed, 06 Jun 2007 03:25:21 -0400 Original-Received: from quinscape.de (dslnet.212-29-44.ip210.dokom.de [212.29.44.210] (may be forged)) by pc3.berlin.powerweb.de (8.9.3p3/8.9.3) with ESMTP id JAA02782 for ; Wed, 6 Jun 2007 09:25:13 +0200 X-Delivered-To: Original-Received: (qmail 1086 invoked from network); 6 Jun 2007 07:25:14 -0000 Original-Received: from unknown (HELO lola.quinscape.zz) ([10.0.3.43]) (envelope-sender ) by ns.quinscape.de (qmail-ldap-1.03) with SMTP for ; 6 Jun 2007 07:25:14 -0000 Original-Received: by lola.quinscape.zz (Postfix, from userid 1001) id EC2968F8EB; Wed, 6 Jun 2007 09:25:13 +0200 (CEST) In-Reply-To: <46665B1D.8000005@gmx.at> (martin rudalics's message of "Wed\, 06 Jun 2007 08\:58\:37 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.51 (gnu/linux) X-detected-kernel: Linux 2.4-2.6 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:72315 Archived-At: martin rudalics writes: >> I don't understand. In this case, `find-file-noselect' uses regexps, >> and is placed on `post-command-hook' indirectly (I don't know whether >> `post-command-hook' is sensitive). > > Every hook is sensitive. > >> Following your opinion, I conclude that it's type-break's >> responsibility to know `find-file-noselect' uses regexps and so it >> should use `save-match-data' when placing it to `post-command-hook'. >> While the name `find-file-noselect' does not indicate it uses regexps, >> and so does its document, it is more or less not appropriate of this >> conclusion to me. > > In any case we fill the stack with unneeded match-data. Stupid question: why does save-match-data not use (match-data t) and thus avoid the creation of markers? Match-data usually is _not_ adjusted for insertion/deletion in the buffer, is it? So it would seem rather self-defeating that (save-match-data (manipulate the buffer)) will adjust the match data for insertions/deletions in the buffer while (manipulate the buffer) in itself won't (assuming that it does not do any matching itself, of course). Try the following: (with-temp-buffer (list (progn (insert "woozle") (goto-char 1) (search-forward "z") (insert-before-markers "x") (match-beginning 0)) (match-end 0) (progn (goto-char 1) (search-forward "z") (save-match-data (insert-before-markers "x")) (match-beginning 0)) (match-end 0))) It will output (4 5 4 6). Namely, the _expensive_ operation of save-match-data _changes_ the outcome. I think this is a mistake. Here is the code: (defmacro save-match-data (&rest body) "Execute the BODY forms, restoring the global value of the match data. The value returned is the value of the last form in BODY." ;; It is better not to use backquote here, ;; because that makes a bootstrapping problem ;; if you need to recompile all the Lisp files using interpreted code. (declare (indent 0) (debug t)) (list 'let '((save-match-data-internal (match-data))) (list 'unwind-protect (cons 'progn body) ;; It is safe to free (evaporate) markers immediately here, ;; as Lisp programs should not copy from save-match-data-internal. '(set-match-data save-match-data-internal 'evaporate)))) If we call (match-data t) here, we don't need the 'evaporate argument. There is one potential problem: if some filter function uses save-match-data for the _undocumented side effect_ of adjusting the match data upon insertion, then this change will cause a change in behavior. So it is probably not something we want to try in the EMACS_22_BASE branch. But I definitely think we want it in the trunk. It seems way more sane, in addition to being more efficient. -- David Kastrup