From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: "Miguel V. S. Frasson" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 26 Jan 2019 23:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 34214@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.154854621528928 (code B ref -1); Sat, 26 Jan 2019 23:44:02 +0000 Received: (at submit) by debbugs.gnu.org; 26 Jan 2019 23:43:35 +0000 Received: from localhost ([127.0.0.1]:46854 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gnXbq-0007WU-LR for submit@debbugs.gnu.org; Sat, 26 Jan 2019 18:43:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48320) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gnXbp-0007WJ-Oi for submit@debbugs.gnu.org; Sat, 26 Jan 2019 18:43:34 -0500 Received: from lists.gnu.org ([209.51.188.17]:42974) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gnXbj-0005b2-OA for submit@debbugs.gnu.org; Sat, 26 Jan 2019 18:43:28 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58514) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gnXbi-0006js-JK for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2019 18:43:27 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gnXbh-0005aU-57 for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2019 18:43:26 -0500 Received: from mail-io1-xd32.google.com ([2607:f8b0:4864:20::d32]:45293) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gnXbg-0005a6-V3 for bug-gnu-emacs@gnu.org; Sat, 26 Jan 2019 18:43:25 -0500 Received: by mail-io1-xd32.google.com with SMTP id c2so10587597iom.12 for ; Sat, 26 Jan 2019 15:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=sHwj5+mTaGRP/Kv0S/r7J8EjoI/BUkl0c7n1MJvRBMU=; b=RN1/CTFLZbWlJECo3yblGZKwyXxxnMkF53kZxlie1t8BLlrrtj0sWbFPX8OeV8QfpO YINtlj6eLu046AL2ObHPIOicSdNSX+WE5ldV2Syhnwb7kHwUY4jTl814NCNV7gm5nK7r ms5TRJyE3xOxU5P0mc1ZX/CTKa1OfhZnmu0cxNlieeRHSar/OKa/HgOnv9VSgFih7Cad FVgN4GyfYxP7SCr4+PLHB4am65IPzzoCFTdiMiJu/NKRmiW0Mpgh7JFgd6Ywz+VStsNv UhTGEzBMo/DqXseokuUBmws24sQxKrRVe5iTeJ6ZO+jK+qCcPJmAVQle7ekvxJ3RURJi R/Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sHwj5+mTaGRP/Kv0S/r7J8EjoI/BUkl0c7n1MJvRBMU=; b=q78RuAHQ5qwKjXAneoNR1XX+KfJmbuOVg9f1Pc1O4R2NfEmJoqIoNcwVdtiJQyKEXe TIg9yYpCCPscQJy4S5SIXP7EkmzALQfwPTAPX1/bG3KFSppYfUDhGvTCMLF4YHHaYdzY qx7+hzo3/gNVDPDmaylHnUI1KZFkQllmQayMhdUU1MsSnAvbZVEsrPhWNGSGZzqpZ4rA r/ekIrwv2V8kMeqPC7pVe02wix3P24r9VExJIkNktzTHnk/e3o2wz08qaU3vtCeWGWsy g5VXI/O5ENX0ebgv/dBT5NqGsfK0q7gRgVt+zX1zQN7lxb/+C+mQWF4Ik8RxbpPwv0fy VCRw== X-Gm-Message-State: AJcUukcj2L4tdj75tv1x/3eESzq6F+wuPWzul56ZzrYQAKPJYYrmjoAz 7oXrpcBd38kjrlXm4ryMyfLWrydKJGwgwdQB9+3CziRG X-Google-Smtp-Source: AHgI3IbziIe2Uc31P7iiVNiqtBtWRTvIqReWt31rW9mZZhsar2HMgrDa6D4k/M7xqRQhTL1O6sTi2wByWqQwd7Cpb7Y= X-Received: by 2002:a6b:b6c4:: with SMTP id g187mr9329969iof.197.1548546199500; Sat, 26 Jan 2019 15:43:19 -0800 (PST) MIME-Version: 1.0 From: "Miguel V. S. Frasson" Date: Sat, 26 Jan 2019 21:42:53 -0200 Message-ID: Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::d32 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Programming an Emacs lisp program that uses match-data, debugging pieces by hand, I realized that managing matchs was a nightmare. At first I thought that navigation commands like C-a or C-M-f were messing match-data (as one could think they use searching). It could be. But for sure, that very handy help line that shows function arguments are messing match data, making difficult to program Emacs lisp. How to reproduce: 1) emacs -Q 2) type or paste the following code on *scratch* buffer (must be a lisp programming mode): (string-match "f" "foo") (match-string 0 "foo") Normal behavior 3) Go to end of string-match line, evaluate with C-x C-e C-n (or down) so that point goes to end of 2nd line *Very quickly* (do not let help for match-string appear), type C-b C-f (or left right) and evaluate: C-x C-e I get correct result "f" Now the bug 4) Go to end of string-match line, evaluate with C-x C-e C-n (getting to end of 2nd line) C-b (or left) ...wait minibuffer function help for match-string show... C-f (or right) C-x C-e I get ERROR 'args-out-of-range "foo" 15 21' What I observed: Steps 3) and 4) are (almost) identical except for time spent between C-b and C-f commands. Error is probably due to a match-data change, probably caused by minibuffer function help mechanism. What I expect: No unnecessary side-effects like change match-data should happen while simply navigating through code. Lisp modes should protect searches on background with save-match-data, because it makes a nightmare to evaluate code by hand. In GNU Emacs 25.3.2 (x86_64-pc-linux-gnu, GTK+ Version 3.22.29) of 2018-04-19 built on lgw01-amd64-039 Windowing system distributor 'The X.Org Foundation', version 11.0.11906000 System Description: Ubuntu 18.04.1 LTS Configured using: 'configure --build=x86_64-linux-gnu --prefix=/usr '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --sharedstatedir=/var/lib --program-suffix=25 --with-modules --with-x=yes --with-x-toolkit=gtk3 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/emacs25-0g8uTI/emacs25-25.3~1.gite0284ab=. -fstack-protector-strong -Wformat -Werror=format-security -no-pie' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -no-pie'' Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES Important settings: value of $LANG: pt_BR.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t transient-mark-mode: t Recent messages: View mode: type C-h for help, h for commands, q to quit. Mark saved where search started next-line: End of buffer Mark set next-line: End of buffer Quit "foo" 0 (#o0, #x0, ?\C-@) "f" [4 times] Entering debugger... Quit Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message dired format-spec rfc822 mml mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils goto-addr thingatpt noutline outline easy-mmode view misearch multi-isearch jka-compr find-func cl-extra help-fns help-mode easymenu cl-loaddefs pcase cl-lib debug time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote dbusbind inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 91561 9006) (symbols 48 20270 0) (miscs 40 67 207) (strings 32 15835 4067) (string-bytes 1 452038) (vectors 16 12415) (vector-slots 8 437769 6180) (floats 8 173 356) (intervals 56 313 13) (buffers 976 20)) -- Miguel Vinicius Santini Frasson mvsfrasson@gmail.com From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 27 Jan 2019 13:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "Miguel V. S. Frasson" Cc: 34214@debbugs.gnu.org Received: via spool by 34214-submit@debbugs.gnu.org id=B34214.154859753020427 (code B ref 34214); Sun, 27 Jan 2019 13:59:02 +0000 Received: (at 34214) by debbugs.gnu.org; 27 Jan 2019 13:58:50 +0000 Received: from localhost ([127.0.0.1]:47103 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gnkxW-0005JM-0a for submit@debbugs.gnu.org; Sun, 27 Jan 2019 08:58:50 -0500 Received: from mail-ot1-f48.google.com ([209.85.210.48]:39464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gnkxU-0005J9-8u for 34214@debbugs.gnu.org; Sun, 27 Jan 2019 08:58:48 -0500 Received: by mail-ot1-f48.google.com with SMTP id n8so12532800otl.6 for <34214@debbugs.gnu.org>; Sun, 27 Jan 2019 05:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5l1GRPsN/LfUOL1Hin9TCYAjLZK0xvN6fm/vTxkIoAI=; b=AkhsJQl03XVn7pkxXAouvaZeNBHE0VbELphmJL1tT0D2wIIwcKLlnh71ozDT9g5zAM qZyzEYy0iYP9aXcsD+ppf/wMm+li2g3DIfIPkbV51kfVbab4wA8LD/maDPnAcshYPUhN /8bw4wLIug7lPub6qQBtx2RSJtmKC4T7g7jfNjJpf0aG5keptiNC+PpO2ZI+Rk8ev7Q2 SLDGSFHhz/RuKnPleP2Z9K8yctpL9GF+7KA3OYgn9rQNK7tSmdeP44rYTgLTkkUNiWzb VLgEgSDqfF+i6XtkOKw1Lj7bSg92x0LA9dA+h7nzXRdl4XiHKya7Y5Cw7i/eAr2Gv6+7 Zy9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5l1GRPsN/LfUOL1Hin9TCYAjLZK0xvN6fm/vTxkIoAI=; b=QN95ww3CBMit9JYUvc410dm8TWBMUX+jGCHt5BjzkEFRJJj7GWSh9F7x++rk1Yh6N9 3F0trRsCfR+2y+EV+OALwXmbPlh4Z8gf69h/iuSbmE5WaFEbvj6CF3Qj9n9Ilcisiy3Z Rt6azRA0Lv0e5pn3Bcnfo0kvES04T0xGKwQgFKN4IK9ZvrFxwaR1nHtMi3ZPFCS6rFZh vyS+/1PxCeOLhTkE60NEADw0zMNnU80PWnDsvVh4utMgcbglbmqtw8peXIPPfQAICufi /KUa+3RL5hZfa+bGKnnd5pUYXQARpbe1NyoMkHFgfxG0Kwbi8BCq+BULqyTgkXO0n57n 7+Qg== X-Gm-Message-State: AJcUukf46Fd13eUdw/7cpUjpnlJjtFNxdR2sKRcDCVJILbpZ/T67PeHa 9AvutLVxyKEE1IA4tX6/KPb8xsN/iu3GKHFYmf0= X-Google-Smtp-Source: ALg8bN7tsBTMfNfZI7H6eGcN8yVQqZzsrQHVcMyAKTxoZtTyXL5bNsPOpxhpoTDtHSzN2htsER9SgHiZ/ALMKlsuKjU= X-Received: by 2002:a9d:4687:: with SMTP id z7mr14310883ote.350.1548597522061; Sun, 27 Jan 2019 05:58:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philipp Stephani Date: Sun, 27 Jan 2019 14:58:31 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.2 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.8 (/) Am So., 27. Jan. 2019 um 00:44 Uhr schrieb Miguel V. S. Frasson : > > Programming an Emacs lisp program that uses match-data, debugging pieces > by hand, I realized that managing matchs was a nightmare. At first I > thought that navigation commands like C-a or C-M-f were messing > match-data (as one could think they use searching). It could be. But > for sure, that very handy help line that shows function arguments are > messing match data, making difficult to program Emacs lisp. > > How to reproduce: > > 1) emacs -Q > > 2) type or paste the following code on *scratch* buffer > (must be a lisp programming mode): > > (string-match "f" "foo") > (match-string 0 "foo") > > Normal behavior > > 3) Go to end of string-match line, evaluate with C-x C-e > C-n (or down) so that point goes to end of 2nd line > *Very quickly* (do not let help for match-string appear), type > C-b C-f (or left right) > and evaluate: C-x C-e > I get correct result "f" > > Now the bug > > 4) Go to end of string-match line, evaluate with C-x C-e > C-n (getting to end of 2nd line) > C-b (or left) > ...wait minibuffer function help for match-string show... > C-f (or right) > C-x C-e > I get ERROR 'args-out-of-range "foo" 15 21' > > What I observed: > > Steps 3) and 4) are (almost) identical except for time spent between C-b > and C-f commands. Error is probably due to a match-data change, probably > caused by minibuffer function help mechanism. > > What I expect: > > No unnecessary side-effects like change match-data should happen while > simply navigating through code. Lisp modes should protect searches on > background with save-match-data, because it makes a nightmare to > evaluate code by hand. > Any function is allowed to change the match data, see https://www.gnu.org/software/emacs/manual/html_node/elisp/Match-Data.html: "Notice that all functions are allowed to overwrite the match data unless they're explicitly documented not to do so.". In general you almost always want to immediately bind the match results to variables, like so: (when (string-match "f" "foo") (let ((match (match-string 0 "foo"))) ... match)) Evaluating the entire 'when' form will then work as intended. From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Aug 2020 11:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 34214@debbugs.gnu.org, "Miguel V. S. Frasson" Received: via spool by 34214-submit@debbugs.gnu.org id=B34214.159731863513507 (code B ref 34214); Thu, 13 Aug 2020 11:38:01 +0000 Received: (at 34214) by debbugs.gnu.org; 13 Aug 2020 11:37:15 +0000 Received: from localhost ([127.0.0.1]:47261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6BXn-0003Vh-0p for submit@debbugs.gnu.org; Thu, 13 Aug 2020 07:37:15 -0400 Received: from mail-yb1-f196.google.com ([209.85.219.196]:36085) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6BXj-0003VL-UG for 34214@debbugs.gnu.org; Thu, 13 Aug 2020 07:37:13 -0400 Received: by mail-yb1-f196.google.com with SMTP id g3so3138938ybc.3 for <34214@debbugs.gnu.org>; Thu, 13 Aug 2020 04:37:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=/FfQFgrw7f+axOa9Nc2B+yAyFGZrMPY0Dpu6B47kqjM=; b=lErQASGIz8Jc4jXNg2vOLQGDdS0SZREzAhTwgRVfEtLkPiKjTVL9xI8JikBFY/hnv4 t5KxlfIahUYGUXujIOU0X0a8ZbW/Cm2HzW7cSB7QkdSkZD4UNsGmDQUMAljyJGYUpuBP CJEmN1XveT72GVkY9iKexmJy9Lo7XcCvwEezaH7xb0JCdVjZIgmo+Sinojj5t8WHlnc4 Mtn39nWpQGux5RSTGez8lV565OsbhmJO/bDtJuvFUlzDDP8iJFHLXnfgR0hgv3fW0BrD KzSZYPeRAq/Y+mqOJOnOam+CVcvqMvzVfXv05uhrIwf9rpBsZL5N0ihlTmfFKQ8fWSbZ S2tA== X-Gm-Message-State: AOAM531bMVYY1TvTOjVp8z81YiQXxjDpo3OJaV4HOjZRxkLdc37fZA5s 3NUgic9tZtYuZ66lPXr3gLfeTk93oAugU2LyX/0= X-Google-Smtp-Source: ABdhPJydalTK8HI3BeNURqEK9XC0Y5AVJqNyJucY4mOZpxgPKZZT+Fsm9UXvN3I4scYFFrGn0+NISbJjZDOaELAKJvQ= X-Received: by 2002:a25:b88b:: with SMTP id w11mr6140759ybj.129.1597318626299; Thu, 13 Aug 2020 04:37:06 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 13 Aug 2020 04:37:05 -0700 From: Stefan Kangas In-Reply-To: (Philipp Stephani's message of "Sun, 27 Jan 2019 14:58:31 +0100") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Date: Thu, 13 Aug 2020 04:37:05 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 34214 + notabug thanks Philipp Stephani writes: >> Programming an Emacs lisp program that uses match-data, debugging pieces >> by hand, I realized that managing matchs was a nightmare. At first I >> thought that navigation commands like C-a or C-M-f were messing >> match-data (as one could think they use searching). It could be. But >> for sure, that very handy help line that shows function arguments are >> messing match data, making difficult to program Emacs lisp. [...] >> What I expect: >> >> No unnecessary side-effects like change match-data should happen while >> simply navigating through code. Lisp modes should protect searches on >> background with save-match-data, because it makes a nightmare to >> evaluate code by hand. >> > > Any function is allowed to change the match data, see > https://www.gnu.org/software/emacs/manual/html_node/elisp/Match-Data.html: > "Notice that all functions are allowed to overwrite the match data > unless they're explicitly documented not to do so.". > In general you almost always want to immediately bind the match > results to variables, like so: > > (when (string-match "f" "foo") > (let ((match (match-string 0 "foo"))) > ... > match)) > > Evaluating the entire 'when' form will then work as intended. Agreed, I don't think there's a bug here. This is just how this works, and is documented to work. Any other opinions? Best regards, Stefan Kangas From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Aug 2020 14:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: "Miguel V. S. Frasson" Cc: 34214@debbugs.gnu.org Received: via spool by 34214-submit@debbugs.gnu.org id=B34214.159732904426396 (code B ref 34214); Thu, 13 Aug 2020 14:31:01 +0000 Received: (at 34214) by debbugs.gnu.org; 13 Aug 2020 14:30:44 +0000 Received: from localhost ([127.0.0.1]:50614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6EFg-0006rg-IR for submit@debbugs.gnu.org; Thu, 13 Aug 2020 10:30:44 -0400 Received: from mail-yb1-f182.google.com ([209.85.219.182]:46279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6EFd-0006rQ-HN for 34214@debbugs.gnu.org; Thu, 13 Aug 2020 10:30:43 -0400 Received: by mail-yb1-f182.google.com with SMTP id x10so3384589ybj.13 for <34214@debbugs.gnu.org>; Thu, 13 Aug 2020 07:30:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ZxRZlnkPBUJnTnJz0KJlNFlJ5MQ3yWsqOLr9Yq9+Fkw=; b=QgBHLn++OfrubnM3FgCE+hpGR/owtbrcQq/1Q0YPWskvUTIaJG9rtjDJQ2unvoImIT CmGCeJxKkslzo2wNDXSmvZotQsma1xUDJrPPe7NLqwCUvRJTn62DZimZeAaQhbR8UX+8 /4VzJ6WugC5RKzucJSJxCDATvJi3H/Mm31RCCMMOv3I+16yC4hCDjKR5glyu5bFm+imU vGQiGvdTaXDjXpnjtiVEd5vhPPOkstnMUheXLP7Gp/R3UetitHoVmr2OZr+V7U15eU86 RSlKeVTOp2tIHGz3dgimZewIgohNSNqQY8xEXl5SiGPhFDJl6skXwQkSHFHyVR2NKZCQ vGUg== X-Gm-Message-State: AOAM532xrvoCg5+LZCphRIWiuvdMzahsIWjQ781qQMERC1fxmhDCF34B Zn1CwnhAkDTYSw9jC4bUYRfHHNDr0di8GyDFgdU= X-Google-Smtp-Source: ABdhPJygmihPpmk9TfmC38IgCPEbawwIBZnS0Tc+Bo0t6jslk+VEgu5uzPXAV2m2RfqsRAWaWBipPXPtqiYHx4+7xZM= X-Received: by 2002:a25:4609:: with SMTP id t9mr6683735yba.231.1597329035816; Thu, 13 Aug 2020 07:30:35 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 13 Aug 2020 07:30:35 -0700 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 13 Aug 2020 07:30:35 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [Please use "Reply to all" so that your replies get recorded in the bug tracker.] "Miguel V. S. Frasson" writes: > Hi. > > The "documented" behavior is in Elisp Reference, but not in doc-strings of > functions that rely on match data. So they are not so easily spotted by > non-experienced users. > > This bug teached me a lesson, but it took me a lot of time to realize how > volatile match-data is, changed even by a helper mode like eldoc. > > IMO it is so easy to avoid interference into user experience in this case, > adding convenience, just by saving match data inside eldoc... > > Should a helper mode "confuse" non-experienced users because it could rely > on "documented" behavior? If so, why does Emacs have disabled commands, if > they are also documented? > > Best regards > > Miguel Actually, you may have a point regarding eldoc, if it's clobbering match data just by moving around the buffer. I guess it would be nice to avoid that. Let's see if anyone else has something to say here. Best regards, Stefan Kangas From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: "Miguel V. S. Frasson" Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 13 Aug 2020 17:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: Stefan Kangas Cc: 34214@debbugs.gnu.org, Philipp Stephani Received: via spool by 34214-submit@debbugs.gnu.org id=B34214.159733888128641 (code B ref 34214); Thu, 13 Aug 2020 17:15:01 +0000 Received: (at 34214) by debbugs.gnu.org; 13 Aug 2020 17:14:41 +0000 Received: from localhost ([127.0.0.1]:50920 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6GoK-0007Rr-Tg for submit@debbugs.gnu.org; Thu, 13 Aug 2020 13:14:41 -0400 Received: from mail-lf1-f46.google.com ([209.85.167.46]:46858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k6GoI-0007Rc-By for 34214@debbugs.gnu.org; Thu, 13 Aug 2020 13:14:39 -0400 Received: by mail-lf1-f46.google.com with SMTP id i80so3407537lfi.13 for <34214@debbugs.gnu.org>; Thu, 13 Aug 2020 10:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oHLKPz5GuYlj3YqE67ClKdr7czn6H2R55d+WKHsZJjo=; b=jT9gv2eXxLCb4QKvpwYks1M3huWQLrChEfbnH25RiFL5Mfmx04KY9JXlsyAwNSmvhI 8Nw4D9nvl7cC471ZgkIiPhBHjLpP3dJA9wQPd2RWTHyiKKwuNx+Ft5CjSqgW6ZvY8FNB HJAipG0/ejxAKfaRXSifhxOnw86ER5TOAu9qOmMasf520eq3TFzbmpj2JWD4IKtTbuqA IMAeObEuBYCziER6oMF+Bmy0hSz/JtO25P74iPOf/lH/u62BgsF3JBhRblgdZAGYvumR Rh5hzW/XCtWZ3r9YApweV3ogtSfIEx+5VizIJsECjueLLVe/Vok7MxTvbPy5JYZEmGeS MyjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oHLKPz5GuYlj3YqE67ClKdr7czn6H2R55d+WKHsZJjo=; b=jbaZH5LGEQwsooGOIwmY+sVEEsZeScRDWfMZKvGoHu3Ii+QvxQ6+pGOWxyFvv327Wx CDUhp4u+F63ryWNgf9VIt/PMCrnKEWrFOG8U13uPr+JG+/BrnowqXqLs7oxNh7s8do4o D82y6giC59zJSoA2Ry4DN4PcaI5YTfBQUBM8k0Wg+3jGoeOCTm6SWtxDT9ZOAqkfTig4 TXlhZpD4CyOYf92e9bZ/72WEW6rYnbQqBkh/+ubvRKjwYqXH/YDyhiIwqyQynnv7n64i 5c/NmXBHyKtAsmRt4jpstizThgs0J4d348oyp1EHuBYw9cLwbVwCgIZKXJYKi0uiw6HP 2UNw== X-Gm-Message-State: AOAM530XNp5ypIIkpI//ynRQhbh/64IY1LqlsM0aNHz+JciXshQG5VYf t2pJO9VNBWd9d9vTku1mPb9NI5O5UGkEGNsNAB8= X-Google-Smtp-Source: ABdhPJw+p+kLvmR02lipfQwb9X+p9lVFy5ObE2XMuH0sQvXI6AaUslKjuYFzgNIOocoRZCKnWlyup73Ai+AEWVaZq3A= X-Received: by 2002:a19:7ec3:: with SMTP id z186mr2665717lfc.3.1597338872094; Thu, 13 Aug 2020 10:14:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Miguel V. S. Frasson" Date: Thu, 13 Aug 2020 14:14:05 -0300 Message-ID: Content-Type: multipart/alternative; boundary="0000000000000eaa1d05acc570ed" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000000eaa1d05acc570ed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi. The "documented" behavior is in Elisp Reference, but not in doc-strings of functions that rely on match data. So they are not so easily spotted by non-experienced users. This bug teached me a lesson, because it took me a lot of time to realize how volatile match-data is, changed even by a helper mode like eldoc. IMO it is so easy to avoid interference into user experience in this case, adding convenience, just by saving match data inside eldoc... Should a helper mode be able to "confuse" non-experienced users because it could rely on "documented" behavior? If so, why does Emacs have disabled commands, if they are also documented? Best regards Miguel Em qui., 13 de ago. de 2020 =C3=A0s 08:37, Stefan Kangas escreveu: > tags 34214 + notabug > thanks > > Philipp Stephani writes: > > >> Programming an Emacs lisp program that uses match-data, debugging piec= es > >> by hand, I realized that managing matchs was a nightmare. At first I > >> thought that navigation commands like C-a or C-M-f were messing > >> match-data (as one could think they use searching). It could be. But > >> for sure, that very handy help line that shows function arguments are > >> messing match data, making difficult to program Emacs lisp. > [...] > >> What I expect: > >> > >> No unnecessary side-effects like change match-data should happen while > >> simply navigating through code. Lisp modes should protect searches on > >> background with save-match-data, because it makes a nightmare to > >> evaluate code by hand. > >> > > > > Any function is allowed to change the match data, see > > > https://www.gnu.org/software/emacs/manual/html_node/elisp/Match-Data.html= : > > "Notice that all functions are allowed to overwrite the match data > > unless they're explicitly documented not to do so.". > > In general you almost always want to immediately bind the match > > results to variables, like so: > > > > (when (string-match "f" "foo") > > (let ((match (match-string 0 "foo"))) > > ... > > match)) > > > > Evaluating the entire 'when' form will then work as intended. > > Agreed, I don't think there's a bug here. This is just how this works, > and is documented to work. > > Any other opinions? > > Best regards, > Stefan Kangas > --=20 Miguel Vinicius Santini Frasson mvsfrasson@gmail.com --0000000000000eaa1d05acc570ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi.

The "documented&quo= t; behavior is in Elisp=20 Reference, but not in doc-strings of functions that rely on match data.=20 So they are not so easily spotted by non-experienced users.
<= br>
This bug teached me a lesson, because it took me a lot of time to realize how= =20 volatile match-data is, changed even by a helper mode like eldoc.

IMO it is so easy to avoid interference into user experience in this case,=20 adding convenience, just by saving match data inside eldoc...

Should a helper mode be able to "confuse" non-experienced users because= it could rely on=20 "documented" behavior? If so, why does Emacs have disabled comman= ds, if=20 they are also documented?

Best reg= ards

Miguel=C2=A0

Em qui., 13 de ago. de 202= 0 =C3=A0s 08:37, Stefan Kangas <ste= fan@marxist.se> escreveu:
tags 34214 + notabug
thanks

Philipp Stephani <p.stephani2@gmail.com> writes:

>> Programming an Emacs lisp program that uses match-data, debugging = pieces
>> by hand, I realized that managing matchs was a nightmare.=C2=A0 At= first I
>> thought that navigation commands like C-a or C-M-f were messing >> match-data (as one could think they use searching).=C2=A0 It could= be.=C2=A0 But
>> for sure, that very handy help line that shows function arguments = are
>> messing match data, making difficult to program Emacs lisp.
[...]
>> What I expect:
>>
>> No unnecessary side-effects like change match-data should happen w= hile
>> simply navigating through code.=C2=A0 Lisp modes should protect se= arches on
>> background with save-match-data, because it makes a nightmare to >> evaluate code by hand.
>>
>
> Any function is allowed to change the match data, see
> https://www.gnu.org/so= ftware/emacs/manual/html_node/elisp/Match-Data.html:
> "Notice that all functions are allowed to overwrite the match dat= a
> unless they're explicitly documented not to do so.".
> In general you almost always want to immediately bind the match
> results to variables, like so:
>
> (when (string-match "f" "foo")
>=C2=A0 =C2=A0(let ((match (match-string 0 "foo")))
>=C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0match))
>
> Evaluating the entire 'when' form will then work as intended.<= br>
Agreed, I don't think there's a bug here.=C2=A0 This is just how th= is works,
and is documented to work.

Any other opinions?

Best regards,
Stefan Kangas


--
Miguel Vinicius Santini Frasson
mvsfrasson@gmail.com
--0000000000000eaa1d05acc570ed-- From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 18 Sep 2020 09:52:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug To: "Miguel V. S. Frasson" Cc: 34214@debbugs.gnu.org, Philipp Stephani Received: via spool by 34214-submit@debbugs.gnu.org id=B34214.160042270613331 (code B ref 34214); Fri, 18 Sep 2020 09:52:02 +0000 Received: (at 34214) by debbugs.gnu.org; 18 Sep 2020 09:51:46 +0000 Received: from localhost ([127.0.0.1]:40930 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJD3S-0003Sw-Cm for submit@debbugs.gnu.org; Fri, 18 Sep 2020 05:51:46 -0400 Received: from mail-ej1-f42.google.com ([209.85.218.42]:44568) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kJD3P-0003SH-5S for 34214@debbugs.gnu.org; Fri, 18 Sep 2020 05:51:43 -0400 Received: by mail-ej1-f42.google.com with SMTP id r7so7221401ejs.11 for <34214@debbugs.gnu.org>; Fri, 18 Sep 2020 02:51:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:user-agent :mime-version:date:message-id:subject:to:cc; bh=f00a0q1limnYNueOfYtgX+pt9rxId0JqTkzmkdHd2mg=; b=rnlsfIadVdJVFg+jNV2lxbh3O89va4Gb9pg4iCOR701r3M+e4x9klUm/s0LC87Dsg3 i9DZ4XvqwdbxmRcolAoAt5rhfG2XxCW4DsfMcfrk47MYQEuwcI0ZnUH7mJfUburO1Anr IG93mlcPZpWmDMi8K4bLm+i1CSOCwT1OLdognQthmL0rOlgwGxSuh54FT/1F9TK/er7E Kidpd4FKldi/sgwWTTqBIRtQV5y4HEwhZvEy7612TB5QK6YwOwTHt9CZpX8xtB9RC2ii 7De+zGRFPbzL24UGygJ+cGaBhosUEG1F8ZxIYmRdtu0ko+D5xkNV09KI8LdqWZPjxz/Z YPaQ== X-Gm-Message-State: AOAM531stKKyHx5/HUU1FSUE7Cj7XO0mG2KsLzGqeWGvnDY/dHzHMQtz 7GW5RMrV8/w77mSXnE4XtkmRA/Ty0gwlfdq3Pdg= X-Google-Smtp-Source: ABdhPJw8eSqBfV1hprXoJKb+OeH2aMW54mAe4hu9oXFOs9NCxbqjQ0E56rRHzkm+JW2jIXz747GHHOsFm34zlq+UhTA= X-Received: by 2002:a17:906:bc52:: with SMTP id s18mr33196244ejv.398.1600422697369; Fri, 18 Sep 2020 02:51:37 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 18 Sep 2020 02:51:36 -0700 From: Stefan Kangas In-Reply-To: (Miguel V. S. Frasson's message of "Thu, 13 Aug 2020 14:14:05 -0300") References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Date: Fri, 18 Sep 2020 02:51:36 -0700 Message-ID: Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) tags 34214 - notabug thanks "Miguel V. S. Frasson" writes: > The "documented" behavior is in Elisp Reference, but not in > doc-strings of functions that rely on match data. So they are not so > easily spotted by non-experienced users. I agree that this could be documented in `match-string'. > IMO it is so easy to avoid interference into user experience in this > case, adding convenience, just by saving match data inside eldoc... > > Should a helper mode be able to "confuse" non-experienced users > because it could rely on "documented" behavior? If so, why does Emacs > have disabled commands, if they are also documented? I have no strong opinion here. Maybe you're right. Anyone else? From unknown Sat Jun 14 05:32:30 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34214: 25.3; minibuffer function help in lisp modes changes match-data Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Sep 2021 22:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34214 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Kangas Cc: 34214@debbugs.gnu.org, Philipp Stephani , "Miguel V. S. Frasson" Received: via spool by 34214-submit@debbugs.gnu.org id=B34214.163234861923015 (code B ref 34214); Wed, 22 Sep 2021 22:11:01 +0000 Received: (at 34214) by debbugs.gnu.org; 22 Sep 2021 22:10:19 +0000 Received: from localhost ([127.0.0.1]:52039 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTARX-0005z8-8c for submit@debbugs.gnu.org; Wed, 22 Sep 2021 18:10:19 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35074) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTARU-0005ym-H0 for 34214@debbugs.gnu.org; Wed, 22 Sep 2021 18:10:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/otIWmDDQkr+ByIga0FDxRgDTlyUheAUwB5n0AaH7DU=; b=GkYt2XMuS/I4qQe1WY06DPyW4h oUlqlMkwLRF8gSn1osylR6MOParwu5fp2nQ1YT5T9cKvlIiaw6eRWpeDpK87UdlUWjW9h2KBZQHES Tp3m0P5sUIlD3HbgzJRdFx/sLOoerGUHDJZ4XMD1feqtsaRbtGT6k+v6DaC8Z1SKn7pI=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mTARI-0007tb-Kp; Thu, 23 Sep 2021 00:10:08 +0200 From: Lars Ingebrigtsen References: X-Now-Playing: The Meters's _Gettin' Funkier All The Time (6): Be My Lady [New Directions]_: "No More Okey Doke" Date: Thu, 23 Sep 2021 00:10:03 +0200 In-Reply-To: (Stefan Kangas's message of "Fri, 18 Sep 2020 02:51:36 -0700") Message-ID: <871r5gqn2c.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Kangas writes: >> The "documented" behavior is in Elisp Reference, but not in >> doc-strings of functions that rely on match data. So they are not so >> easily spotted by non-experienced users. > > I agree that this [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Kangas writes: >> The "documented" behavior is in Elisp Reference, but not in >> doc-strings of functions that rely on match data. So they are not so >> easily spotted by non-experienced users. > > I agree that this could be documented in `match-string'. I've now done so in Emacs 28. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 22 18:10:24 2021 Received: (at control) by debbugs.gnu.org; 22 Sep 2021 22:10:24 +0000 Received: from localhost ([127.0.0.1]:52042 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTARb-0005zU-FV for submit@debbugs.gnu.org; Wed, 22 Sep 2021 18:10:24 -0400 Received: from quimby.gnus.org ([95.216.78.240]:35090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mTARY-0005yy-Md for control@debbugs.gnu.org; Wed, 22 Sep 2021 18:10:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=GCeC21Vt4wHmF3eUqcI7SZEIdsdTtN51trWxtZY/Yuk=; b=eu8cs7Owen1b/Pbl//q2qGkxGx nbnM1oRM6v7jS8Q4c4UFiQ2t9fXHYU+C6RpiYtT07zG+wV5+4ubmcXvialGlMa9Dt6axw/AmCtGbA BJyTiWGKzCmTloikFim0QP9k1W3ldw+YajD2zwVXK83ENCzJuIuKmf7biwwGBwBQs26U=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mTARP-0007ti-HA for control@debbugs.gnu.org; Thu, 23 Sep 2021 00:10:15 +0200 Date: Thu, 23 Sep 2021 00:10:10 +0200 Message-Id: <87zgs4p8hp.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #34214 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 34214 28.1 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) close 34214 28.1 quit