From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.devel Subject: Re: Saving match data Date: Wed, 28 Sep 2016 18:49:37 +0200 Message-ID: <87twd0j7fi.fsf@web.de> References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1475081469 20849 195.159.176.226 (28 Sep 2016 16:51:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Sep 2016 16:51:09 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 28 18:51:02 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 1bpI4C-0002lF-Kg for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2016 18:50:44 +0200 Original-Received: from localhost ([::1]:60103 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpI4B-0005EP-1U for ged-emacs-devel@m.gmane.org; Wed, 28 Sep 2016 12:50:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpI3S-00055J-AJ for emacs-devel@gnu.org; Wed, 28 Sep 2016 12:50:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bpI3J-0006Qq-JC for emacs-devel@gnu.org; Wed, 28 Sep 2016 12:49:57 -0400 Original-Received: from mout.web.de ([212.227.17.12]:59089) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bpI3J-0006Pl-6q for emacs-devel@gnu.org; Wed, 28 Sep 2016 12:49:49 -0400 Original-Received: from drachen.dragon ([90.186.2.35]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0M9ojk-1beGUO2hAW-00B6nQ; Wed, 28 Sep 2016 18:49:40 +0200 In-Reply-To: (Stefan Monnier's message of "Wed, 28 Sep 2016 12:11:00 -0400") X-Provags-ID: V03:K0:ZfBI1h1z/22u0nUx3nY4iIcuW0+jGpvJ8/QhuRPN4tGuu77oBvX aB6C7g8qAlwAPpTGokPTduVzF0CArwcPLa4KRcTuclZZuo0D76BwcBOFyi7XoZ9PmJaPJBS n6K6ZQFx5rcxa+/gNb/EBvOjESz0uI/cjOca++Gs0NnInfBlJ/4GvU4pQdDqSEeC8NqhcF3 w6uOXbA5cr7EYFSOx13/A== X-UI-Out-Filterresults: notjunk:1;V01:K0:zIH7385d/dQ=:8TQFVB0GoFbfCt6C0hs7ub nOFBlhEdzK/YTMAJJL76RARmOKpVqr0nQ2Fo74KTxRkkgjif6WB86JArhrJg8eZJdi1t+y9GM TG8HOdDfG71gcbWdV1T9bB2+jShQr1aey6N89HSub/qosrZAlzJ3rMgjJxV04Swp4z2fcjX1W r4gQdccNscdG6rPiiO2NU40Pb0584Gf32nTgZmZCt3XlSQlBXQzOIB7OH4lup/M0kpBep2p6p 0Km+YX7Nb4QLkZwrNsuaRjRe8tSy3wq5cpaNP1o/Y4adeFp/zeWm7NNcwXr4hSpGDM06WNwmy BikpZvAPeOCz/XECEsT/OIFCS3/xQqdjEsyJHGfAFGuJs8INnvpztcAQbuPPt/16s4+MTlU5k D53E2Ed2AHmucIMa3ilzHIcTaHJqi3S/YFyO+fjfAcjTSSNNkhhM5kRrURo+iyA42n26e1yd6 ePD9ioRemq0uV0g/41mlIbuMrNl29uyral9zknZxEP3z9p+12CyzvWlZAasmKRdnKdyl7jNPk bSP9RSzNeSDGu5uen2lbEnm5klUs5wADCF8ldmXl+SxLuM5yyxorhHbR8cTzYqOzrfx8WDIiw ZdMUUDc0Yot7b0siegz0GuQVKgo46Q+v3WU4xGVY58pj1TDXz9tiGE7XxLe82kI/D/ifOlNbg Ts28U5mnJEZJ2ziH9WHBxk94DisgSekxoyUCzGKeiTnfe++cBRJP1b+aiTYjfHqMms9v3eOeJ 10Ny7jehyiKZs0HNX7QYpB7vDl7NlEqkwiq2aoaUPCahfCvy37qHTrq2F+Y+8k1cKFUF8/px X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.17.12 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:207865 Archived-At: Stefan Monnier writes: > That would imply adding save-match-data *everywhere*. It's an enormous > amount of work, can't be automated, and comes with only two obvious > results: > - our Elisp source code will be significantly larger. > - Emacs will be slower. This sounds crazy. Sorry about this ignorant question: Why do we use this model of match data: a global state that is changed as a side effect in thousands of circumstances. If you really need the match data, the common way is to suppress that it is changed. This discussion shows that this approach seems to have great downsides, and it doesn't seem very "lispy" anyway. Why don't we just let the programmer explicitly save the match data (e.g. to a symbol) when he is interested in it (FWIW this is already possible with `match-data' and `save-match-data'). That would be more transparent and work around this kind of problem. Michael.