From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 24 06:55:28 2023 Received: (at submit) by debbugs.gnu.org; 24 Aug 2023 10:55:28 +0000 Received: from localhost ([127.0.0.1]:36254 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ7zs-0007Xq-6v for submit@debbugs.gnu.org; Thu, 24 Aug 2023 06:55:28 -0400 Received: from lists.gnu.org ([2001:470:142::17]:57764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZ7zn-0007Xa-TQ for submit@debbugs.gnu.org; Thu, 24 Aug 2023 06:55:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qZ7ze-0002vz-E4 for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 06:55:14 -0400 Received: from smtp-15.smtpout.orange.fr ([80.12.242.15] helo=smtp.smtpout.orange.fr) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qZ7zY-0006PG-LX for bug-gnu-emacs@gnu.org; Thu, 24 Aug 2023 06:55:14 -0400 Received: from [192.168.1.15] ([2.7.71.181]) by smtp.orange.fr with ESMTPA id Z7zTqUnKG9KIfZ7zUqv7YT; Thu, 24 Aug 2023 12:55:04 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1692874504; bh=a0rhOg4Gx5s3YAYYVjWZ2A5NgmgLwKpK99Vf/v+sxI8=; h=Date:To:From:Subject; b=NYHt6iCv8X4Ke+9gTDzzCMPoSZImzJhjYwzpr8eqd0/T/QQYRo/pCh9A3BROWg13B jbE7sLoWnmOvXSkk9aF2tk/FAXar9aYvkNpGhh0BLnHr3xiJgGZoJeumIaDgUPz/Xx EJ03HWDQTa2IPTOPt7XquMEvF1fvWdRhVwwkMHBU1CrAYrN8gQ/4udBsQMI5ci7PEu qVCe9Pj1VzMDbdxrkVbAj2+lOklxz9dWdDVPthGZwT5WooOQkdYBrKyvL5XVyK2TcZ 0N6RPSN5094+zp/54BB79RBQ0BPp8qh7TuKwMlULdgXPPrMBOsG+gmSOFy5PniEYej 5Y1OI2Wy+elEA== X-ME-Helo: [192.168.1.15] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Thu, 24 Aug 2023 12:55:04 +0200 X-ME-IP: 2.7.71.181 Content-Type: multipart/mixed; boundary="------------D0ZDEeHl1sZXilCxsFxaFTlT" Message-ID: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> Date: Thu, 24 Aug 2023 12:55:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.14.0 Content-Language: fr, en-US To: bug-gnu-emacs@gnu.org From: David Ponce Subject: 30.0.50; Issue with the regexp used to auto-detect PBM image data Received-SPF: pass client-ip=80.12.242.15; envelope-from=da_vid@orange.fr; helo=smtp.smtpout.orange.fr X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: submit 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.3 (/) This is a multi-part message in MIME format. --------------D0ZDEeHl1sZXilCxsFxaFTlT Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, While experimenting with code to create image from data, I encountered an issue with the regexp in `image-type-header-regexps' used to auto-detect PBM image type from the first bytes of image data. That is: "\\`P[1-6]\\(?:\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\ \\)\\{2\\}" Here is a simple recipe to illustrate the issue: In *scratch* buffer eval: ------------------------- ;; Get content of a pbm file. (setq test-data (with-current-buffer (find-file-noselect "[YourEmacsPath]/etc/images/splash.pbm") (prog1 (buffer-substring-no-properties (point-min) (point-max)) (kill-buffer (current-buffer))))) ;; Check string data fail for pbm image-type! (image-type-from-data test-data) >>> nil ;; With a temp buffer current, the same test works! (with-temp-buffer (image-type-from-data test-data)) >>> pbm ------------------------- After further digging, I found that the problem might be due to the use of the [:space:] character class whose meaning, according to the manual, depends on the syntax of whitespace characters setup in current buffer. So, using discrete values in place of syntax class seems to solve the issue: (setcar (nth 1 image-type-header-regexps) "\\`P[1-6]\\(?:\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[ \t\r\n]\\)+\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\ \\)\\{2\\}") (image-type-from-data test-data) >>> pbm I attached a patch proposal. Hope it will help. Regards In GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.38, cairo version 1.17.8) of 2023-08-23 Repository revision: 26ca3e84e167f975afb4e9e9a838935bfe4a19a7 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12014000 System Description: Fedora Linux 38 (KDE Plasma) Configured using: 'configure --with-x-toolkit=gtk3 --with-native-compilation=no PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:/usr/lib/pkgconfig' Configured features: ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS TREE_SITTER WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB Important settings: value of $LC_TIME: fr_FR.utf8 value of $LANG: fr_FR.UTF-8 locale-coding-system: utf-8-unix --------------D0ZDEeHl1sZXilCxsFxaFTlT Content-Type: text/x-patch; charset=UTF-8; name="image-type-header-regexps-patch-V0.patch" Content-Disposition: attachment; filename="image-type-header-regexps-patch-V0.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL2xpc3AvaW1hZ2UuZWwgYi9saXNwL2ltYWdlLmVsCmluZGV4IDA4MTkw Y2Y4NmJjLi5lMjBmYmNmNGM5OCAxMDA2NDQKLS0tIGEvbGlzcC9pbWFnZS5lbAorKysgYi9s aXNwL2ltYWdlLmVsCkBAIC0zOCw3ICszOCw3IEBAIGltYWdlCiAoZGVmY29uc3QgaW1hZ2Ut dHlwZS1oZWFkZXItcmVnZXhwcwogICBgKCgiXFxgL1tcdFxuXHIgXSpcXCouKlhQTS5cXCov IiAuIHhwbSkKICAgICAoIlxcYFBbMS02XVxcKD86XAotXFwoPzpcXCg/OiNbXlxyXG5dKltc clxuXVxcKSpbWzpzcGFjZTpdXVxcKStcCitcXCg/OlxcKD86I1teXHJcbl0qW1xyXG5dXFwp KlsgXHRcclxuXVxcKStcCiBcXCg/OlxcKD86I1teXHJcbl0qW1xyXG5dXFwpKlswLTldXFwp K1wKIFxcKVxcezJcXH0iIC4gcGJtKQogICAgICgiXFxgR0lGOFs3OV1hIiAuIGdpZikK --------------D0ZDEeHl1sZXilCxsFxaFTlT-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 24 16:45:21 2023 Received: (at control) by debbugs.gnu.org; 24 Aug 2023 20:45:21 +0000 Received: from localhost ([127.0.0.1]:38710 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZHCi-0001LI-Vi for submit@debbugs.gnu.org; Thu, 24 Aug 2023 16:45:21 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:42435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qZHCh-0001L2-60 for control@debbugs.gnu.org; Thu, 24 Aug 2023 16:45:19 -0400 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-5298e43bb67so648233a12.1 for ; Thu, 24 Aug 2023 13:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692909909; x=1693514709; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=o5LPqNU3552izd5xR4Uf0cdCdKqH90y5a1fwRJIfIFE=; b=ljN1G5w0s1ffOe49VAYB6XB/1usL8LVCm38JvK+jEBbljdmSBQEh6ThDYQT8oPNYOp ZXEfuHqXSCPS6/hX03uRfQVVD0cJCfuzxq6mn2hEanioaTBRSYC7E4R/8MPVo8XplET/ nv/lBoaT1FB3M4UuewSm1eFeA9WGz9lgscjPsa0bcdq6kbHUgPIbC3RMSHI1KXNy1Ny0 ulgBrlij0Z8JZY+SCJv9j9dxzFd68Hp/pPJwvPyyIqL4erfusYkjLBNYYTrx4NY4M9aj DGkRKfCGRDpQALTYPioEyfrxWnGEecNyOAfisAfVbAEWKHYRazMcnCohOPCbncnAN3A0 dh/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692909909; x=1693514709; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=o5LPqNU3552izd5xR4Uf0cdCdKqH90y5a1fwRJIfIFE=; b=fU1jqY0iUAgMqmv4o8SqGf6fxSPfVbf5KKn1/FJx7A6eQ+u3AyndPbqrvkjzdt1bGP kH4/qdqxPxe119VQoIHhZTS+/dxSJhnA87g0Ow/qmDbKLS67AF07OZBDcoKdI24/2u3/ 8na2uvywa5k/N8GQ8oc+IrUeRDQ1Td2N90EXARumYAy5fCwfEgPbMb2NC9eVIpLvrBs5 C7Ff1brcjfqQ4N0tNSJnGOgxj8IZVftEp5e7UnEJjTpBKn8m4VIl1CGJej/CtAXag9iD +Yz5LUSTxaw5z0+q8w3xz/tHW0WZLJmW8rwv60p7V91kWaBEoFeKb1X+dVt3i/3QA2yj +vgQ== X-Gm-Message-State: AOJu0YwV8jaMAsW5TLHf+L1OcJc3Yp2aQdELCsO5jjdjv+GnmOsUeAGt uEddYlVEpr9PexGOSNOZFnfBziaTdVnyNWLZOBcM+cpiyfY= X-Google-Smtp-Source: AGHT+IET1G3pD93gz0wvSzNR850Znj/OB+JVkXSE+r8JB6XNSnyL1PV1c7SVkjKhLzvIfZgokWJeR+5pofJ1/C78XIg= X-Received: by 2002:aa7:d5d2:0:b0:523:c36e:ec8b with SMTP id d18-20020aa7d5d2000000b00523c36eec8bmr17665868eds.9.1692909909089; Thu, 24 Aug 2023 13:45:09 -0700 (PDT) MIME-Version: 1.0 From: Stefan Kangas Date: Thu, 24 Aug 2023 22:44:58 +0200 Message-ID: Subject: To: control Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: tags 65496 + patch thanks Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stefankangas[at]gmail.com) 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2a00:1450:4864:20:0:0:0:52e listed in] [list.dnswl.org] 2.0 BLANK_SUBJECT Subject is present but empty 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: 1.0 (+) tags 65496 + patch thanks From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 04 12:32:28 2023 Received: (at 65496) by debbugs.gnu.org; 4 Sep 2023 16:32:28 +0000 Received: from localhost ([127.0.0.1]:52422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdCV2-0007Qu-53 for submit@debbugs.gnu.org; Mon, 04 Sep 2023 12:32:28 -0400 Received: from smtp-16.smtpout.orange.fr ([80.12.242.16]:49388 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdCUz-0007Qi-0c for 65496@debbugs.gnu.org; Mon, 04 Sep 2023 12:32:26 -0400 Received: from [192.168.1.15] ([2.7.71.181]) by smtp.orange.fr with ESMTPA id dCUwqwnNuvfOmdCUwqtCBc; Mon, 04 Sep 2023 18:32:23 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1693845143; bh=Kt0SZZmpypYw9nxBpbr6wDbFfL/e8dlQoQlARt/deJ8=; h=Date:From:Subject:References:To:In-Reply-To; b=ePgpYZLxLU/GGtUqcn+n2AFC9VMjmojXhje/NTPkhz6mPoVee/qU2hSrm+AnKERYY 3jxOILdoLiCx6VZ80agfAet85EiSCYgJ5kpPAGqu3Hyxd8LhvazzkU8LyvBg6Maw2X QZFgX2Mc621Em0S3NPgvbPL1WAMVdOm4GOhCM02rGMyYvnH23xyawms+sTcxPIQfg8 jXidExvJj0K42LoSUbltQD/yfArgQn0RZFpakiDKpPGrcedIA/xgX6NXxfhcr3MYzK athVo2vonwFnOwZvXQ/h1M1Buy1PTbFrE01V2CrjI6nUSfxqgLWPjXgrrbbN5tRzmX UZyYjcbzY7YGQ== X-ME-Helo: [192.168.1.15] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Mon, 04 Sep 2023 18:32:23 +0200 X-ME-IP: 2.7.71.181 Message-ID: Date: Mon, 4 Sep 2023 18:32:22 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 From: David Ponce Subject: Re: 30.0.50; Issue with the regexp used to auto-detect PBM image data References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> Content-Language: fr, en-US To: 65496@debbugs.gnu.org In-Reply-To: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 65496 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: -2.5 (--) On 24/08/2023 12:55, David Ponce wrote: > Hello, > > While experimenting with code to create image from data, I encountered > an issue with the regexp in `image-type-header-regexps' used to > auto-detect PBM image type from the first bytes of image data. That is: > > "\\`P[1-6]\\(?:\ > \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\ > \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\ > \\)\\{2\\}" > > Here is a simple recipe to illustrate the issue: > > In *scratch* buffer eval: > ------------------------- > ;; Get content of a pbm file. > (setq test-data >       (with-current-buffer >           (find-file-noselect "[YourEmacsPath]/etc/images/splash.pbm") >         (prog1 (buffer-substring-no-properties (point-min) (point-max)) >           (kill-buffer (current-buffer))))) > > ;; Check string data fail for pbm image-type! > (image-type-from-data test-data) >>>> nil > ;; With a temp buffer current, the same test works! > (with-temp-buffer >  (image-type-from-data test-data)) >>>> pbm > ------------------------- > > After further digging, I found that the problem might be due to the use > of the [:space:] character class whose meaning, according to the manual, > depends on the syntax of whitespace characters setup in current buffer. > So, using discrete values in place of syntax class seems to solve the > issue: > > (setcar (nth 1 image-type-header-regexps) >         "\\`P[1-6]\\(?:\ > \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[ \t\r\n]\\)+\ > \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\ > \\)\\{2\\}") > > (image-type-from-data test-data) >>>> pbm > > I attached a patch proposal. > Hope it will help. > Regards Some additions. Basic string matching recipe: In *scratch* buffer eval: ------------------------- (let ((re "\\`P[1-6]\\(?:\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\ \\)\\{2\\}") (text "P4 333 233")) (string-match-p re text)) >>> nil (with-syntax-table (standard-syntax-table) (let ((re "\\`P[1-6]\\(?:\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[[:space:]]\\)+\ \\(?:\\(?:#[^\r\n]*[\r\n]\\)*[0-9]\\)+\ \\)\\{2\\}") (text "P4 333 233")) (string-match-p re text))) >>> 0 I wonder if it is expected that matching a regular expression against a string object depends on the syntax-table setup in current buffer? Shouldn't (standard-syntax-table) implied when matching a regexp against a string object, that is, regardless of any buffer context? Regards From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 04 13:36:36 2023 Received: (at 65496) by debbugs.gnu.org; 4 Sep 2023 17:36:37 +0000 Received: from localhost ([127.0.0.1]:52491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdDV6-0000gd-Jo for submit@debbugs.gnu.org; Mon, 04 Sep 2023 13:36:36 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60014) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdDV1-0000gK-Ej for 65496@debbugs.gnu.org; Mon, 04 Sep 2023 13:36:35 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdDUv-0000RH-FR; Mon, 04 Sep 2023 13:36:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=KmDwH/W1jXTyVvR3YKHBqo28dZiiAQQPxS38j06m/VU=; b=QFWwfLq38SeR 3DIw0o79Zbmm/jIWhfl1LW+Ve6m8pkEMe2rWXFt/H8/7i2gINsYUOSTqfuHF6S22+X2h8P6z3avhW bQj/1KSETFt7eUaIoE23GN3lpI/KdU0fSyH+ohG/LUdoMpoBRiieJuU5ntT/as5r4ZRUSVWqPY3yh bcQsooIqj8GmI8GthCOSP4h4GkLw62xdxNfp3HJYtI6SLA2EK9bQ3DuwJP1UHQVEm1RsRsq1TYKZi 3O30/OVHfO2FVAZYyc7fX8ePj6zy/kKzdw962ql90HKrPwJL6AZngTKNGvwZ4R89zEK08o//PMMeb 3ae28mf1Mt+CapP7Yr5yjA==; Date: Mon, 04 Sep 2023 20:36:06 +0300 Message-Id: <83wmx54z95.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: (message from David Ponce on Mon, 4 Sep 2023 18:32:22 +0200) Subject: Re: bug#65496: 30.0.50; Issue with the regexp used to auto-detect PBM image data References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65496 Cc: 65496@debbugs.gnu.org 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 (---) > Date: Mon, 4 Sep 2023 18:32:22 +0200 > From: David Ponce > > I wonder if it is expected that matching a regular expression > against a string object depends on the syntax-table setup in current > buffer? Shouldn't (standard-syntax-table) implied when matching a > regexp against a string object, that is, regardless of any buffer > context? Not necessarily, because you wouldn't expect, say, looking-at to return a different result than (string-match-p (buffer-string)), would you? This belongs to the gray areas of Emacs. The same situation exists with functions like downcase, which use the buffer-local value of case-table. From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 05 07:08:40 2023 Received: (at 65496) by debbugs.gnu.org; 5 Sep 2023 11:08:40 +0000 Received: from localhost ([127.0.0.1]:54382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdTvE-0008UB-9b for submit@debbugs.gnu.org; Tue, 05 Sep 2023 07:08:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:42532) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdTvC-0008Tv-3k for 65496@debbugs.gnu.org; Tue, 05 Sep 2023 07:08:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qdTv6-0002GT-C2; Tue, 05 Sep 2023 07:08:32 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mVYfWsWmFVdBERpeQJJFPEJ7LviEqg695N6XheUb4YI=; b=shPDE5seU4I7 u+QDNe4GZHPErx6FFRr5zDFnkOm5YmNywyaf/epAA+BcPfw2686L/hrnD/6SsL3u23LwgOcKMayHb 0lhtkP2X2L5/3CkFEgoHet+c0XeTwikaKoI4v0kSSOBXkrV//R+3J2RB0jSDRA/mTGixbApRtN7Sf 3iF0yU02cI3KRp0dmoJr4Gqx4kR9JTjby6tNmNAAOdNfroMrOUK8eRaQ+J9zVBRB2BMa83OLCNeQC J94NuB5fraCXC2dVuogPbnYqW/65VNOPI62fkADTednsQSWxz+s/Ts5huLFYY4lul/X7HwT6zNENM YQso33uWaOd1LVsiFx2tow==; Date: Tue, 05 Sep 2023 14:08:15 +0300 Message-Id: <83ledk5140.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <6e4af25a-03b1-ef82-b1c0-2da81938e215@orange.fr> (message from David Ponce on Mon, 4 Sep 2023 23:43:56 +0200) Subject: Re: bug#65496: 30.0.50; Issue with the regexp used to auto-detect PBM image data References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> <83wmx54z95.fsf@gnu.org> <6e4af25a-03b1-ef82-b1c0-2da81938e215@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65496 Cc: 65496@debbugs.gnu.org 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 (---) [I presume you didn't intend to discuss this only with me in private.] > Date: Mon, 4 Sep 2023 23:43:56 +0200 > From: David Ponce > > On 04/09/2023 19:36, Eli Zaretskii wrote: > >> Date: Mon, 4 Sep 2023 18:32:22 +0200 > >> From: David Ponce > >> > >> I wonder if it is expected that matching a regular expression > >> against a string object depends on the syntax-table setup in current > >> buffer? Shouldn't (standard-syntax-table) implied when matching a > >> regexp against a string object, that is, regardless of any buffer > >> context? > > > > Not necessarily, because you wouldn't expect, say, looking-at to > > return a different result than (string-match-p (buffer-string)), would > > you? > > Sure, from this perspective you are right. However, for other cases > where the string object is not related to a buffer value, it's not so > clear ;-) > > > This belongs to the gray areas of Emacs. The same situation exists > > with functions like downcase, which use the buffer-local value of > > case-table. > > I can understand that. Many things are not only black or white ;-) > > Maybe for the use case of auto-detecting image type from image data, > my proposed patch to replace character class by a list of unambiguous > explicit character values in the regexp could make sense? Yes, it makes sense, but are you sure you mention there all the characters that can happen in PBM images, and only those characters? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 06 10:05:44 2023 Received: (at 65496) by debbugs.gnu.org; 6 Sep 2023 14:05:45 +0000 Received: from localhost ([127.0.0.1]:37055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdtA8-0003Ek-Gb for submit@debbugs.gnu.org; Wed, 06 Sep 2023 10:05:44 -0400 Received: from smtp-25.smtpout.orange.fr ([80.12.242.25]:56698 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdtA6-0003Ea-7B for 65496@debbugs.gnu.org; Wed, 06 Sep 2023 10:05:43 -0400 Received: from [192.168.1.15] ([2.7.71.181]) by smtp.orange.fr with ESMTPA id dtA3qUEYV1in9dtA3qhkim; Wed, 06 Sep 2023 16:05:39 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1694009139; bh=ZkgmNEG1V+Cxn4IgXP0ZCtJpSaot3v1gKfgtI6c1gr8=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=gOPRs1HyylrLuAuqg6WmrIZuLa+QLYCVFi+6KbWjm2TWQnFzsIJs3bwKmviZm0b0v gD2Rtt1AJBQIfXKiXb0Rb8+q0yiDc7SeTSAk6vpZWXpziTkm5pr9uv6IjrQbj1Zf7Z cJmlXHQ2ARtQWlhmGpIgtuYZYursqHEFd2fANtptMxQaVUEQknmlCUKuXH7Vncos+f 6emCGzJq0QQ+gaGl+VF0TtrUepW9YgKo7ZW3dL5HCgJpPnsHOxCObrfUW1oqCZVW2X Vbq8aCMV1M9YI7Sj/0lMW6Pq0cniHG1OdzBBY+y6SaekcrqZiwah26czlbLAlzJo9r BySzRfJmg0plQ== X-ME-Helo: [192.168.1.15] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Wed, 06 Sep 2023 16:05:39 +0200 X-ME-IP: 2.7.71.181 Message-ID: <92beee30-616b-0f9d-c3ec-52ef66fc9db3@orange.fr> Date: Wed, 6 Sep 2023 16:05:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: bug#65496: 30.0.50; Issue with the regexp used to auto-detect PBM image data To: Eli Zaretskii References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> <83wmx54z95.fsf@gnu.org> <6e4af25a-03b1-ef82-b1c0-2da81938e215@orange.fr> <83ledk5140.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <83ledk5140.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 65496 Cc: 65496@debbugs.gnu.org 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: -2.5 (--) On 05/09/2023 13:08, Eli Zaretskii wrote: > [I presume you didn't intend to discuss this only with me in private.] Hi Eli, You are right, my mistake, I did reply instead of reply to all :-\ I am sorry. > >> Date: Mon, 4 Sep 2023 23:43:56 +0200 >> From: David Ponce >> >> On 04/09/2023 19:36, Eli Zaretskii wrote: >>>> Date: Mon, 4 Sep 2023 18:32:22 +0200 >>>> From: David Ponce >>>> >>>> I wonder if it is expected that matching a regular expression >>>> against a string object depends on the syntax-table setup in current >>>> buffer? Shouldn't (standard-syntax-table) implied when matching a >>>> regexp against a string object, that is, regardless of any buffer >>>> context? >>> >>> Not necessarily, because you wouldn't expect, say, looking-at to >>> return a different result than (string-match-p (buffer-string)), would >>> you? >> >> Sure, from this perspective you are right. However, for other cases >> where the string object is not related to a buffer value, it's not so >> clear ;-) >> >>> This belongs to the gray areas of Emacs. The same situation exists >>> with functions like downcase, which use the buffer-local value of >>> case-table. >> >> I can understand that. Many things are not only black or white ;-) >> >> Maybe for the use case of auto-detecting image type from image data, >> my proposed patch to replace character class by a list of unambiguous >> explicit character values in the regexp could make sense? > > Yes, it makes sense, but are you sure you mention there all the > characters that can happen in PBM images, and only those characters? Yes, according to the specification of pbm available at : "Each PBM image consists of the following: * A "magic number" for identifying the file type. A pbm image's magic number is the two characters "P4". ==> * Whitespace (blanks, TABs, CRs, LFs). <== * The width in pixels of the image, formatted as ASCII characters in decimal. ..." Thanks From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 06 12:01:03 2023 Received: (at 65496-done) by debbugs.gnu.org; 6 Sep 2023 16:01:03 +0000 Received: from localhost ([127.0.0.1]:37199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qduxi-0005ws-DJ for submit@debbugs.gnu.org; Wed, 06 Sep 2023 12:01:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qduxc-0005wK-HH for 65496-done@debbugs.gnu.org; Wed, 06 Sep 2023 12:01:00 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qduxU-00053H-B1; Wed, 06 Sep 2023 12:00:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=5cttabboHhsL8ucXbxR/lkP3HQllnYbyXZvFwAV6d2U=; b=EyvGyCi/YVzs rT3Z3LFApZvuAPARFQQJrYA4e8FVORvVdMALfkcdtnJhfG1t2YZmGEgy1id7QPq+W6treLHlescUZ Gt4TDWpACj0WHf9eH9/2Tkjn1FaZlvmfh1udHC7vt+P910gu29mH5zQYmmzXSjgO2J1Hg9FrxeGl2 KgQ27feFj/yMjaiCoui0N38i2qwAnA0+LCFBBiz4DlIj3XKREsdACKIm1Eh+vy20+QapvmVprCSza N5J/gHFJKg8o/9aAQXf8N3VuXYsgiH3Bdx7LRIemSALcc46Ry+pvpk/1DN3x6dUnkkpglXUsMRaSO SJEB8ynC+poD6E2eliZ17g==; Date: Wed, 06 Sep 2023 19:00:28 +0300 Message-Id: <83il8n1ecj.fsf@gnu.org> From: Eli Zaretskii To: David Ponce In-Reply-To: <92beee30-616b-0f9d-c3ec-52ef66fc9db3@orange.fr> (message from David Ponce on Wed, 6 Sep 2023 16:05:39 +0200) Subject: Re: bug#65496: 30.0.50; Issue with the regexp used to auto-detect PBM image data References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> <83wmx54z95.fsf@gnu.org> <6e4af25a-03b1-ef82-b1c0-2da81938e215@orange.fr> <83ledk5140.fsf@gnu.org> <92beee30-616b-0f9d-c3ec-52ef66fc9db3@orange.fr> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 65496-done Cc: 65496-done@debbugs.gnu.org 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 (---) > Date: Wed, 6 Sep 2023 16:05:39 +0200 > Cc: 65496@debbugs.gnu.org > From: David Ponce > > >> Maybe for the use case of auto-detecting image type from image data, > >> my proposed patch to replace character class by a list of unambiguous > >> explicit character values in the regexp could make sense? > > > > Yes, it makes sense, but are you sure you mention there all the > > characters that can happen in PBM images, and only those characters? > > Yes, according to the specification of pbm available at > : > > "Each PBM image consists of the following: > > * A "magic number" for identifying the file type. > A pbm image's magic number is the two characters "P4". > > ==> * Whitespace (blanks, TABs, CRs, LFs). <== > > * The width in pixels of the image, formatted as ASCII characters in decimal. > > ..." Thanks, I've now installed your patch on the emacs-29 branch, and I'm closing this bug. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 06 12:19:44 2023 Received: (at 65496-done) by debbugs.gnu.org; 6 Sep 2023 16:19:44 +0000 Received: from localhost ([127.0.0.1]:37217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdvFn-0006R1-Qq for submit@debbugs.gnu.org; Wed, 06 Sep 2023 12:19:44 -0400 Received: from smtp-18.smtpout.orange.fr ([80.12.242.18]:61261 helo=smtp.smtpout.orange.fr) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qdvFi-0006Qp-Q9 for 65496-done@debbugs.gnu.org; Wed, 06 Sep 2023 12:19:42 -0400 Received: from [192.168.1.15] ([2.7.71.181]) by smtp.orange.fr with ESMTPA id dvFdqnOirhaW6dvFfqC8BW; Wed, 06 Sep 2023 18:19:36 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1694017176; bh=w3TRoV+uOp53nvEeKqtHGGzT4DeRAMzcumI7Ez9KuVM=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=b40JfGemyujGKhL8SJO/gbwynbJY/KbV4jdK8wrb9PS60fMSJHLLcIHoU0ho3O8JU wnpPGDP+eH8VrUzkM8YeCVnAeLFBEdrUzKMkS6G408wHsqvLAKfMEGRMkBQkYgiIDj ziwSLprxB4KeBTvPi7S2gEOe+7XtBhJq4M1qyA0sH/o+HZ7sJ1APwR0BkNIR0wlStK BlorZjk8i3jBM0/p/UFIFmUllnMRNbREitIxI3yqr3nsp+m1rxY2DqW27hTGBPVDou GAf1BKWFOCwhHjJzePODGNhHepYS/3CLAQy0DAPi/ulV6wW/RR6rlhN5c5L8nBeCAk WrlLnSzrD3TPg== X-ME-Helo: [192.168.1.15] X-ME-Auth: ZGFfdmlkQHdhbmFkb28uZnI= X-ME-Date: Wed, 06 Sep 2023 18:19:36 +0200 X-ME-IP: 2.7.71.181 Message-ID: Date: Wed, 6 Sep 2023 18:19:33 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 Subject: Re: bug#65496: 30.0.50; Issue with the regexp used to auto-detect PBM image data To: Eli Zaretskii References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> <83wmx54z95.fsf@gnu.org> <6e4af25a-03b1-ef82-b1c0-2da81938e215@orange.fr> <83ledk5140.fsf@gnu.org> <92beee30-616b-0f9d-c3ec-52ef66fc9db3@orange.fr> <83il8n1ecj.fsf@gnu.org> Content-Language: fr, en-US From: David Ponce In-Reply-To: <83il8n1ecj.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.5 (-) X-Debbugs-Envelope-To: 65496-done Cc: 65496-done@debbugs.gnu.org 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: -2.5 (--) On 06/09/2023 18:00, Eli Zaretskii wrote: [...] > > Thanks, I've now installed your patch on the emacs-29 branch, and I'm > closing this bug. Great! Thank you very much! From unknown Sun Aug 17 22:05:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Thu, 05 Oct 2023 11:24:14 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator