From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Ponce Newsgroups: gmane.emacs.bugs Subject: bug#65496: 30.0.50; Issue with the regexp used to auto-detect PBM image data Date: Mon, 4 Sep 2023 18:32:22 +0200 Message-ID: References: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17298"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.15.0 To: 65496@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 04 18:33:09 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qdCVg-0004Hi-4F for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Sep 2023 18:33:08 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qdCVb-00010T-SP; Mon, 04 Sep 2023 12:33:03 -0400 Original-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 1qdCVa-0000vd-NN for bug-gnu-emacs@gnu.org; Mon, 04 Sep 2023 12:33:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qdCVZ-0003Uc-TC for bug-gnu-emacs@gnu.org; Mon, 04 Sep 2023 12:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qdCVZ-0007Rh-RU for bug-gnu-emacs@gnu.org; Mon, 04 Sep 2023 12:33:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Ponce Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Sep 2023 16:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 65496 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 65496-submit@debbugs.gnu.org id=B65496.169384514828580 (code B ref 65496); Mon, 04 Sep 2023 16:33:01 +0000 Original-Received: (at 65496) by debbugs.gnu.org; 4 Sep 2023 16:32:28 +0000 Original-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 Original-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 Original-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 Content-Language: fr, en-US In-Reply-To: <2fea228e-a8e8-5b8e-b91d-2d808d624649@orange.fr> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:269262 Archived-At: 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