From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Saving match data Date: Wed, 28 Sep 2016 14:01:23 +0000 Message-ID: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1141e66084e604053d91cc65 X-Trace: blaine.gmane.org 1475071351 15416 195.159.176.226 (28 Sep 2016 14:02:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2016 14:02:31 +0000 (UTC) To: Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 28 16:02:27 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bpFR7-0002E4-UW for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2016 16:02:14 +0200 Original-Received: from localhost ([::1]:59147 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpFR6-000455-FR for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2016 10:02:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49731) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpFQW-00044u-GQ for emacs-devel@gnu.org; Wed, 28 Sep 2016 10:01:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpFQV-0007hx-H2 for emacs-devel@gnu.org; Wed, 28 Sep 2016 10:01:36 -0400 Original-Received: from mail-wm0-x22e.google.com ([2a00:1450:400c:c09::22e]:37532) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpFQV-0007hn-A1 for emacs-devel@gnu.org; Wed, 28 Sep 2016 10:01:35 -0400 Original-Received: by mail-wm0-x22e.google.com with SMTP id b130so73346950wmc.0 for ; Wed, 28 Sep 2016 07:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=kOPiaIq9/gK7wFApXqc/aErTAwtUmhQWOCsS7ZA5ZPE=; b=SkBFiZlfIPQeT+fACdYicRm9+5t215FWfX72Tv3rDhoD0ZkNaA97UugSoeQxB27L3S CwVfYubdrfPfWJ6+SL5T8HoXIZgclBykYpatTcTsZ2tMATUnkjwqBFAbwmKxYrKyEre5 XsF0BHC0mJQTT0a2+DG7kK1qcTlsa9BeqKx5JcPguaWR117nG6D/kOG+2ztQDVXobUcT gmll/SR3uakxiLeQK0Lk//oA6tuGzi7TJWWgwrpXUMX4TdROzCBW6q3ATWPrCZKo6nnE 4eaJCOrxSjGVzQh/xrUDCT/HQFOts8UU0eAv0jJbfBgDMmd5qhhS2drA1OLyy6rt/ACC j+Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kOPiaIq9/gK7wFApXqc/aErTAwtUmhQWOCsS7ZA5ZPE=; b=mBeZZZjUS6xV28E08NV1vbyss5Cd93HkwtaBREb+MEoyo3cxS8h/uM2ojDIuFjaZ5J cmW/Nz5+FOdm/Zfe9ZO+pIVx081DMtimaAX3VvFH6s2KARaOfG1EQG1MGSiiZn0XcUfb d9kALllaP5x/SUAgQE9vLKMMVPizc2jhger0RsPToMk+/mUDucpcD7LD4Lima903dHl7 AmNppjWCvTihG3iHHOV1P5On8nO0pO7jmRWvTtXP2Yfj7mbpIiDRiBF96I/0/AbjLHhC xNweSOMwZEpVl0DkR9va9iMZdp5hxx8b8IbINYfHmm64hEBmGxQBFGncr9wMoFNzMU+M eHwA== X-Gm-Message-State: AA6/9Rl6Vk93/DqVBKG5V86wNUdeYLZcIc85JIK1r9vNeVVVuzy6injW5kqPbcpy5MWZEljfGviCpdBBnC7PjA== X-Received: by 10.28.125.209 with SMTP id y200mr8877708wmc.112.1475071294362; Wed, 28 Sep 2016 07:01:34 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:207858 Archived-At: --001a1141e66084e604053d91cc65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, the Elisp manual (section "The Match Data") says: "Notice that all functions are allowed to overwrite the match data unless they=E2=80=99re explicitly documented not to do so." I think this statement is surprising and puts unnecessary burden on Elisp programmers. The usual expectation is that global state is *not* modified unless explicitly specified. Taken literally, Elisp programmers need to surround even calls to `car' with `save-match-data' because the documentation of `car' doesn't specify that it doesn't change the match data. How about changing the statement to "Notice that no functions are allowed to overwrite the match data unless they're explicitly documented to do so." and then clean up existing documentation and add `save-match-data' where appropriate. Philipp --001a1141e66084e604053d91cc65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

the Elisp manual (section "The= Match Data") says:

"Notice that all fun= ctions are allowed to overwrite the match data
unless they=E2=80= =99re explicitly documented not to do so."

I = think this statement is surprising and puts unnecessary burden on Elisp pro= grammers. The usual expectation is that global state is *not* modified unle= ss explicitly specified. Taken literally, Elisp programmers need to surroun= d even calls to `car' with `save-match-data' because the documentat= ion of `car' doesn't specify that it doesn't change the match d= ata. How about changing the statement to

"Not= ice that no functions are allowed to overwrite the match data unless they&#= 39;re explicitly documented to do so."

and th= en clean up existing documentation and add `save-match-data' where appr= opriate.

Philipp
--001a1141e66084e604053d91cc65--