From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Daniel Lopez Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Feb 2019 08:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 34525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 34525@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.15504786524313 (code B ref -1); Mon, 18 Feb 2019 08:31:01 +0000 Received: (at submit) by debbugs.gnu.org; 18 Feb 2019 08:30:52 +0000 Received: from localhost ([127.0.0.1]:52053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gveKB-00017T-9F for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:30:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gveK9-00017H-Od for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:30:50 -0500 Received: from lists.gnu.org ([209.51.188.17]:55452) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gveK4-0004xr-Fg for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:30:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gveK2-0007Lz-KJ for bug-gnu-emacs@gnu.org; Mon, 18 Feb 2019 03:30:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,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 1gveJw-0004uX-0z for bug-gnu-emacs@gnu.org; Mon, 18 Feb 2019 03:30:42 -0500 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:44424) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gveJs-0004rm-PX for bug-gnu-emacs@gnu.org; Mon, 18 Feb 2019 03:30:34 -0500 Received: by mail-wr1-x42b.google.com with SMTP id w2so2680904wrt.11 for ; Mon, 18 Feb 2019 00:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=QKexhx5J5hqVApGXKje0qyOnN7FcAuu0zvPDSybMG5U=; b=iHT3Z9TrT7gxCqOYmatZ2DlHaDJY9bt5dvgwqxJReEznpU2io0snIZD6xdUM2p79IC BpPYxkYECHSkUDaFNjM4QB2LTdtyafkgyTv/dtsPxLhdAzRi+i/r5OnAS5YQQqvILHvD u+LMVvEY+pzf5645rcJKD8ZoNUKGYPEQmm+IwD9zjXobKqMLvq2YK9nUitkMCw8JqJJb he7qw9cbG1qbFP5ENo3U1ZmNZ2kzGQGG3nxXNsezL+Shcr0NOSLXk9+86YDBZTqqNgec 3K2hLpqmplhCYp6f5kKNHnyGaL70I04kH9xRLO2eWPyV3nCARax9LxfqFRrEYTH6X0za rZHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=QKexhx5J5hqVApGXKje0qyOnN7FcAuu0zvPDSybMG5U=; b=b67VdONad98vjKpFZzOu19avISuywmntVZUisrXARu1RfS3fNFU+6WDumfhLlcsEkx Mtc2xJ2ORh6usmYRKdcb4OC09yJ5nlBIU23U+pzZ/SUOcBkKYn9FdTmn0P87hO9qart0 tal+H2QBS8E7Xq0sWdk1WsVVlLq3bdn6FwTiTjacufAp1nWiT8eEYrtM7hneeMdn++Av F850k5EDcqxxn3+0YMOQuSRbUBoZICNcmSS2Ap3vkkrrW8nyS2Y3l1ROJS0dDRkqjw0W n2VaHFVnWav0D+12xDHhzZIMHfftnKvPDX6CWKqFJIh2MjNeljssnkz4HUnO/IrI8SKp RScw== X-Gm-Message-State: AHQUAuaWzXzEtwaPvvcafvKL6ey99FCrgLK50ZzEDDVsYknCD9O4LSXZ shTd0ylpEfaqKqoC+GdcJopqqlSH X-Google-Smtp-Source: AHgI3IZoZ7LCIUtegEOD+hXjXLacewaNGl7OLsqYV1BrOzoRK7GLmBuschRftXjyCAf6eAsuqpgT4A== X-Received: by 2002:a5d:5042:: with SMTP id h2mr15716070wrt.12.1550478627281; Mon, 18 Feb 2019 00:30:27 -0800 (PST) Received: from [192.168.2.2] (w-79.cust-5765.ip.static.uno.uk.net. [95.172.231.79]) by smtp.googlemail.com with ESMTPSA id u6sm7828452wmj.28.2019.02.18.00.30.25 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 00:30:26 -0800 (PST) From: Daniel Lopez Message-ID: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> Date: Mon, 18 Feb 2019 08:28:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------4A0208EF172FFB4FBC0E5D25" Content-Language: en-US-large X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42b X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.2 (+) 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: Reproduce: - Start "emacs -Q" and open the file BitmapFontFace.h - Evaluate the expression (replace-regexp "\\" "SharedBitmap") - The text "Replaced 8 occurrences" appears in the echo area. Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (daniel.lopez999[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (daniel.lopez999[at]gmail.com) 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 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.2 (/) This is a multi-part message in MIME format. --------------4A0208EF172FFB4FBC0E5D25 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Reproduce: - Start "emacs -Q" and open the file BitmapFontFace.h - Evaluate the expression (replace-regexp "\\" "SharedBitmap") - The text "Replaced 8 occurrences" appears in the echo area. Problem: There were actually 12 occurrences (ie. of the word "Bitmap" surrounded by word boundaries) in the file that should have been replaced. If I now move point back to the start of the buffer and evaluate the expression again, it says "Replaced 4 occurrences". The exact number of incorrect replacements perhaps varies over time. That is, I can test it five times in a row and get 8 initial replacments each time, but after trying some other search terms, messing with the file, restarting Emacs etc, I try my initial test again and then maybe it consistently replaces 10 the first time, for a while. So your exact numbers may vary. I debugged the Lisp as far as I could and it appears to be wrong answers coming out of the re-search-forward C call that is in isearch-search-fun-default. The bug filters up to a number of string replacement user actions - I first noticed it when trying to do this replacement interactively with query-replace on word boundaries (C-u M-%), entering "Bitmap" as search string, then "SharedBitmap" as replacement string. Trying now, as I press space repeatedly about once a second to confirm each one, I see the pink highlight skip valid matches to ask me about one that is further down even while I see the skipped one highlighted in blue a few lines above, and in the end it may have replaced only 6-8 of the occurrences. Though, if I press 'n' instead of space to skip without making any replacements, it does visit all of the occurrences. I see from the Lisp that plain (non-regexp) query-replace on word boundaries gets preprocessed into the equivalent regexp search as in my initial example. I don't think there are any problems with plain string search and replacement. Some more experimental observations: - The replacement text can be any string instead of "SharedBitmap", eg. "qwertyasdfgh", "qwer", etc, and the bug still happens. The number of matches seems to be related to the length of the replacement string. Currently 12 character replacement strings are causing replace-regexp to make 8 replacements on the first call for me, while 4 character strings cause 7 replacements. 6 character replacement strings - ie. same length as "Bitmap" - always work, replacing all 12 occurrences. - The bug doesn't happen in fundamental-mode, nor c-mode, js-mode, text-mode or any other major modes I tried. - I've seen this happen in other of my C++ files where I was making the same replacement, so the problem's not precisely unique to this one. I've been trying to simplify this one but haven't found anything much more revealing so far. For example if I delete all the comments and blank lines, then the first replacement finds 9 occurrences out of 10. If I cut the file in half by deleting line 140 onwards, the first replacement finds 3 occurrences out of 6. But if I do something very simple like just pasting "Bitmap" on 100 consecutive lines, it's not fooled and it replaces them all. I've tried this in GNU Emacs 26.1 on Arch Linux and 25.2.1 on Windows 7 and am seeing the same behaviour in both. Thanks, Daniel --------------4A0208EF172FFB4FBC0E5D25 Content-Type: text/x-chdr; name="BitmapFontFace.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="BitmapFontFace.h" // BitmapFontFace: A class to store a font in which the glyphs are stored in bitmaps. #pragma once // This namespace #include "FontFaceMetrics.h" // Dan std #include #include #include #include using dan::Error; // Boost #include using boost::scoped_array; #include // C++ std #include #include namespace dan { struct BitmapFontGlyph // Where to find the graphic for a single character // // (This is only used by BitmapFontFace but isn't declared within it as it doesn't need to // use BitmapFontFace's template parameters) { unsigned int bitmapNo; // Which bitmap of the BitmapFontFace contains the glyph of this character dan::math::Rect2I rect; // The position and size on the bitmap of the character's glyph dan::math::Vector2I bearing; // Distance from the drawing pen position to where the top-left of the glyph should be dan::math::Vector2I advance; // The number of pixels that the drawing pen position should be moved // after printing this character, to be ready for the next one BitmapFontGlyph(unsigned int i_bitmapNo, const dan::math::Rect2I & i_rect, const dan::math::Vector2I & i_bearing, const dan::math::Vector2I & i_advance) : bitmapNo(i_bitmapNo), rect(i_rect), bearing(i_bearing), advance(i_advance) {} }; typedef std::map BitmapFontCharmap; // Represents a character map, // ie. a full alphabet of mappings from character code numbers to glyphs. // This collection of mappings is also known as a character encoding. // // (This is only used by BitmapFontFace but isn't declared within it as it doesn't need to // use BitmapFontFace's template parameters) template class BitmapFontFace { // + Shared part {{{ protected: struct Shared { std::vector< Bitmap > m_bitmaps; std::vector m_charmaps; float m_emHeight; FontFaceMetrics m_metrics; unsigned int m_replacementForMissingCharCode = 0; // + Construction {{{ Shared(float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with no bitmaps or charmaps {} Shared(const std::vector< Bitmap > & i_bitmaps, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with multiple bitmaps and multiple charmaps { m_bitmaps.assign(i_bitmaps.begin(), i_bitmaps.end()); m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } Shared(const Bitmap & i_bitmap, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with single bitmap and multiple charmaps // (bitmap specified in Bitmap object) { m_bitmaps.push_back(i_bitmap); m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } Shared(PixelType * i_srcBitmap_pixels, unsigned int i_srcBitmap_width, unsigned int i_srcBitmap_height, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with single bitmap and multiple charmaps // (bitmap specified as buffer, width and height) { m_bitmaps.push_back(Bitmap(i_srcBitmap_pixels, i_srcBitmap_width, i_srcBitmap_height)); m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } Shared(const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct without any bitmaps stored (class stores font metadata only) { m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } // + }}} }; boost::shared_ptr m_shared; // + }}} // + Construction {{{ public: BitmapFontFace(float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_emHeight, i_metrics)) // Construct with no bitmaps or charmaps {} BitmapFontFace(const std::vector< Bitmap > & i_bitmaps, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_bitmaps, i_charmaps, i_emHeight, i_metrics)) // Construct with multiple bitmaps and multiple charmaps {} BitmapFontFace(const Bitmap & i_bitmap, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_bitmap, i_charmaps, i_emHeight, i_metrics)) // Construct with single bitmap and multiple charmaps // (bitmap specified in Bitmap object) {} BitmapFontFace(PixelType * i_srcBitmap_pixels, unsigned int i_srcBitmap_width, unsigned int i_srcBitmap_height, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_srcBitmap_pixels, i_srcBitmap_width, i_srcBitmap_height, i_charmaps, i_emHeight, i_metrics)) // Construct with single bitmap and multiple charmaps // (bitmap specified as buffer, width and height) {} BitmapFontFace(const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_charmaps, i_emHeight, i_metrics)) // Construct without any bitmaps stored (class stores font metadata only) {} // + }}} // + Bitmaps {{{ const std::vector< Bitmap > & bitmaps() const { return m_shared->m_bitmaps; } std::vector< Bitmap > & bitmaps() { return m_shared->m_bitmaps; } //void releaseBitmaps() //{ // m_bitmaps.clear(); //} // + }}} // + Charmaps {{{ const std::vector & charmaps() const { return m_shared->m_charmaps; } unsigned int charmap_count() const { return m_shared->m_charmaps.size(); } unsigned int charmap_charCount() const { return m_shared->m_charmaps.front().size(); } // + }}} // + Metrics {{{ unsigned int emHeight() const { return m_shared->m_emHeight; } FontFaceMetrics & metrics() const { return m_shared->m_metrics; } // + }}} // + Get details of a single char {{{ unsigned int replacementForMissingCharCode() const { return m_shared->m_replacementForMissingCharCode; } void replacementForMissingCharCode(unsigned int i_charCode) const { m_shared->m_replacementForMissingCharCode = i_charCode; } const BitmapFontGlyph & getGlyph(unsigned int i_charmapNo, unsigned int i_charCode) const { if (i_charmapNo >= m_shared->m_charmaps.size()) throw( Error(0, "in BitmapFontFace::getGlyph, i_charmapNo out of range") ); BitmapFontCharmap & charmap = m_shared->m_charmaps[i_charmapNo]; BitmapFontCharmap::const_iterator glyphItr = charmap.find(i_charCode); if (glyphItr == charmap.end()) { if (m_shared->m_replacementForMissingCharCode == 0) throw( Error(0, "in BitmapFontFace::getGlyph, no glyph in charmap for i_charCode") ); glyphItr = charmap.find(m_shared->m_replacementForMissingCharCode); if (glyphItr == charmap.end()) throw( Error(0, "in BitmapFontFace::getGlyph, no glyph in charmap for i_charCode or its replacement code") ); } return glyphItr->second; } const Bitmap & getGlyphBitmap(unsigned int i_charmapNo, unsigned int i_charCode) const { return m_shared->m_bitmaps[getGlyph(i_charmapNo, i_charCode).bitmapNo]; } const dan::math::Rect2I & getGlyphRect(unsigned int i_charmapNo, unsigned int i_charCode) const { return getGlyph(i_charmapNo, i_charCode).rect; } // + }}} dan::math::Vector2I charAdvanceMax() const { dan::math::Vector2I maxValue = 0; for (unsigned int charmapNo = 0; charmapNo < m_shared->m_charmaps.size(); ++charmapNo) { const BitmapFontCharmap & charmap = m_shared->m_charmaps[charmapNo]; for (BitmapFontCharmap::const_iterator glyphItr = charmap.begin(); glyphItr != charmap.end(); ++glyphItr) { if (glyphItr->second.advance[0] > maxValue[0]) maxValue[0] = glyphItr->second.advance[0]; if (glyphItr->second.advance[1] > maxValue[1]) maxValue[1] = glyphItr->second.advance[1]; } } return maxValue; } dan::math::Vector2I charRectSizeMax() const { dan::math::Vector2I maxValue = 0; for (unsigned int charmapNo = 0; charmapNo < m_shared->m_charmaps.size(); ++charmapNo) { const BitmapFontCharmap & charmap = m_shared->m_charmaps[charmapNo]; for (BitmapFontCharmap::const_iterator glyphItr = charmap.begin(); glyphItr != charmap.end(); ++glyphItr) { if (glyphItr->second.rect.width() > maxValue[0]) maxValue[0] = glyphItr->second.rect.width(); if (glyphItr->second.rect.height() > maxValue[1]) maxValue[1] = glyphItr->second.rect.height(); } } return maxValue; } }; } --------------4A0208EF172FFB4FBC0E5D25-- From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: Acknowledgement (replace-regexp missing some matches) Resent-From: Daniel Lopez Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Feb 2019 08:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15504791435038 (code B ref 34525); Mon, 18 Feb 2019 08:40:02 +0000 Received: (at 34525) by debbugs.gnu.org; 18 Feb 2019 08:39:03 +0000 Received: from localhost ([127.0.0.1]:52062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gveS7-0001JC-HN for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:39:03 -0500 Received: from mail-wr1-f48.google.com ([209.85.221.48]:33664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gveS5-0001Ih-NG for 34525@debbugs.gnu.org; Mon, 18 Feb 2019 03:39:02 -0500 Received: by mail-wr1-f48.google.com with SMTP id i12so17382802wrw.0 for <34525@debbugs.gnu.org>; Mon, 18 Feb 2019 00:39:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=RuYr3xLQBBTL6ZPeQCBIaMSDZwiPgE57BWmqIjukZAM=; b=TBoroXmwUBld/VVP7pDZC7Z7h7PpBk2camKuZq9sI9qT5yqewgQNSCTOudCZ3WnYb3 WuJ7COXdtmCA/m/qeuIiqrpyfHemGu1S1nmdIf91qIe8Q3z0WQfNN0nwovBcXoQi6/Un FHcW3HI5Qsm0xsRn4cambKJB43mDR3pAX0vMOSvMHHxHYedoCnlu3uJGvGMcub1dY1lZ 8RCuJZ+hCjbZvimcpcXBkX+QIFa+2v3MYXcRH5iekPP/xvOMmSD3TCuoShJdjGhT4Pg8 9s7XYRermRbck8ob3PqxKxVoGnZVZjFpxxzhUK6h+mHT8hwvM3Hikm2Q7YwZ0HEAOp6P JOVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=RuYr3xLQBBTL6ZPeQCBIaMSDZwiPgE57BWmqIjukZAM=; b=C7bpinPDkuo2MveyHNYS3wSYYOXLi4dPyf8EpyriEKyk6EPGvYhiPQi+H/Clu3hWV5 9N/E3rkS2uiYyjQZ8tFLB2Sn7mANGaQ/LGZ6hOvnsZSq4OVlYq6TaQTnEKAGQsH4eR8R nxW/FRvAq7Sc2ykvDKNNC7aOd60HAKqArvbeq/PRWbv00WwW64+hv5AHo3AnmB/ZBQ3q G9y8QUSvBOAUXmFssEBkzvKRLx17KgL/krBwsfgisF6qhg8s+24qNnTM2aFuU+WryJw0 TlGJAtcTJXF8hmQnjQoaz0FDfPhu47CzAfMscU21hhkSrhDIe16piJzfPMMaWtctGCJs Be1A== X-Gm-Message-State: AHQUAuZHnho1VoVrFgy2Y6DiW9zi1eTfwFPji3SZLBRcYEiDA42z8YGF l6uj1z67U+R46Bp6/5YdZiCnZ+Ue X-Google-Smtp-Source: AHgI3Ib//Kz3wsFUfzjswcnKLidawh4XH2jHa6Az8FEaThSNsg2nSOwrh8Y8YBFqeA+OzqhRw3Q5Iw== X-Received: by 2002:adf:ee01:: with SMTP id y1mr6924468wrn.268.1550479135538; Mon, 18 Feb 2019 00:38:55 -0800 (PST) Received: from [192.168.2.2] (w-79.cust-5765.ip.static.uno.uk.net. [95.172.231.79]) by smtp.googlemail.com with ESMTPSA id d9sm24637195wrn.72.2019.02.18.00.38.54 for <34525@debbugs.gnu.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 00:38:54 -0800 (PST) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> From: Daniel Lopez Message-ID: Date: Mon, 18 Feb 2019 08:37:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US-large Content-Transfer-Encoding: 7bit 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 (/) > - The bug doesn't happen in fundamental-mode, nor c-mode, js-mode, text-mode or any other major modes I tried. Whoops, I should just clarify this - it doesn't happen in any of those modes, but it is happening in c++-mode. Daniel From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Feb 2019 15:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Lopez , Alan Mackenzie Cc: 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155050501822392 (code B ref 34525); Mon, 18 Feb 2019 15:51:01 +0000 Received: (at 34525) by debbugs.gnu.org; 18 Feb 2019 15:50:18 +0000 Received: from localhost ([127.0.0.1]:53096 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gvlBR-0005p5-Mb for submit@debbugs.gnu.org; Mon, 18 Feb 2019 10:50:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gvlBQ-0005or-Pm for 34525@debbugs.gnu.org; Mon, 18 Feb 2019 10:50:17 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:45712) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gvlBK-0005MJ-R9; Mon, 18 Feb 2019 10:50:10 -0500 Received: from [176.228.60.248] (port=1262 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gvlBK-0005jh-01; Mon, 18 Feb 2019 10:50:10 -0500 Date: Mon, 18 Feb 2019 17:50:16 +0200 Message-Id: <83zhqtjdtz.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> (message from Daniel Lopez on Mon, 18 Feb 2019 08:28:35 +0000) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > From: Daniel Lopez > Date: Mon, 18 Feb 2019 08:28:35 +0000 > > - Start "emacs -Q" and open the file BitmapFontFace.h > - Evaluate the expression (replace-regexp "\\" "SharedBitmap") > - The text "Replaced 8 occurrences" appears in the echo area. > > Problem: > > There were actually 12 occurrences (ie. of the word "Bitmap" surrounded > by word boundaries) in the file that should have been replaced. If I now > move point back to the start of the buffer and evaluate the expression > again, it says "Replaced 4 occurrences". > > The exact number of incorrect replacements perhaps varies over time. > That is, I can test it five times in a row and get 8 initial replacments > each time, but after trying some other search terms, messing with the > file, restarting Emacs etc, I try my initial test again and then maybe > it consistently replaces 10 the first time, for a while. So your exact > numbers may vary. C++ Mode plays some funky games with the syntax of '<', so maybe this is the consequence. CC'ing Alan, in the hope that he might have something interesting to say about this. Thanks. From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 18 Feb 2019 16:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Lopez , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155050861828287 (code B ref 34525); Mon, 18 Feb 2019 16:51:02 +0000 Received: (at 34525) by debbugs.gnu.org; 18 Feb 2019 16:50:18 +0000 Received: from localhost ([127.0.0.1]:53139 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gvm7U-0007MA-Ld for submit@debbugs.gnu.org; Mon, 18 Feb 2019 11:50:16 -0500 Received: from colin.muc.de ([193.149.48.1]:36910 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gvm7T-0007M1-0q for 34525@debbugs.gnu.org; Mon, 18 Feb 2019 11:50:15 -0500 Received: (qmail 37162 invoked by uid 3782); 18 Feb 2019 16:50:13 -0000 Received: from acm.muc.de (p4FE15EC7.dip0.t-ipconnect.de [79.225.94.199]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 18 Feb 2019 17:50:11 +0100 Received: (qmail 13291 invoked by uid 1000); 18 Feb 2019 16:46:38 -0000 Date: Mon, 18 Feb 2019 16:46:38 +0000 Message-ID: <20190218164638.GC11724@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83zhqtjdtz.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Mon, Feb 18, 2019 at 17:50:16 +0200, Eli Zaretskii wrote: > > From: Daniel Lopez > > Date: Mon, 18 Feb 2019 08:28:35 +0000 > > - Start "emacs -Q" and open the file BitmapFontFace.h > > - Evaluate the expression (replace-regexp "\\" "SharedBitmap") > > - The text "Replaced 8 occurrences" appears in the echo area. > > Problem: > > There were actually 12 occurrences (ie. of the word "Bitmap" surrounded > > by word boundaries) in the file that should have been replaced. If I now > > move point back to the start of the buffer and evaluate the expression > > again, it says "Replaced 4 occurrences". > > The exact number of incorrect replacements perhaps varies over time. > > That is, I can test it five times in a row and get 8 initial replacments > > each time, but after trying some other search terms, messing with the > > file, restarting Emacs etc, I try my initial test again and then maybe > > it consistently replaces 10 the first time, for a while. So your exact > > numbers may vary. > C++ Mode plays some funky games with the syntax of '<', so maybe this > is the consequence. CC'ing Alan, in the hope that he might have > something interesting to say about this. Acknowledged. I can reproduce the error, but as yet have no idea of the cause. I'm looking into it. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 18 Feb 2019 21:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Lopez , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155052444728246 (code B ref 34525); Mon, 18 Feb 2019 21:15:01 +0000 Received: (at 34525) by debbugs.gnu.org; 18 Feb 2019 21:14:07 +0000 Received: from localhost ([127.0.0.1]:53285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gvqEo-0007LW-NQ for submit@debbugs.gnu.org; Mon, 18 Feb 2019 16:14:07 -0500 Received: from colin.muc.de ([193.149.48.1]:58883 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gvqEm-0007LJ-EL for 34525@debbugs.gnu.org; Mon, 18 Feb 2019 16:14:05 -0500 Received: (qmail 55429 invoked by uid 3782); 18 Feb 2019 21:14:01 -0000 Received: from acm.muc.de (p4FE15EC7.dip0.t-ipconnect.de [79.225.94.199]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 18 Feb 2019 22:13:59 +0100 Received: (qmail 14614 invoked by uid 1000); 18 Feb 2019 21:10:26 -0000 Date: Mon, 18 Feb 2019 21:10:26 +0000 Message-ID: <20190218211026.GD11724@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83zhqtjdtz.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, again. On Mon, Feb 18, 2019 at 17:50:16 +0200, Eli Zaretskii wrote: > > From: Daniel Lopez > > Date: Mon, 18 Feb 2019 08:28:35 +0000 > > - Start "emacs -Q" and open the file BitmapFontFace.h > > - Evaluate the expression (replace-regexp "\\" "SharedBitmap") > > - The text "Replaced 8 occurrences" appears in the echo area. > > Problem: > > There were actually 12 occurrences (ie. of the word "Bitmap" surrounded > > by word boundaries) in the file that should have been replaced. If I now > > move point back to the start of the buffer and evaluate the expression > > again, it says "Replaced 4 occurrences". > > The exact number of incorrect replacements perhaps varies over time. > > That is, I can test it five times in a row and get 8 initial replacments > > each time, but after trying some other search terms, messing with the > > file, restarting Emacs etc, I try my initial test again and then maybe > > it consistently replaces 10 the first time, for a while. So your exact > > numbers may vary. > C++ Mode plays some funky games with the syntax of '<', so maybe this > is the consequence. CC'ing Alan, in the hope that he might have > something interesting to say about this. I built a version of CC Mode with the use of the category properties on < and > disabled. This version used straight syntax-table text properties instead. The bug still happened. So, although I should probably get rid of this too "clever" use of category properties, they seem not to be the cause of this bug. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 20 Feb 2019 17:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Lopez , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155068267727441 (code B ref 34525); Wed, 20 Feb 2019 17:12:02 +0000 Received: (at 34525) by debbugs.gnu.org; 20 Feb 2019 17:11:17 +0000 Received: from localhost ([127.0.0.1]:58401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwVOv-00078W-GM for submit@debbugs.gnu.org; Wed, 20 Feb 2019 12:11:17 -0500 Received: from colin.muc.de ([193.149.48.1]:36584 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gwVOt-00078K-HG for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 12:11:16 -0500 Received: (qmail 42841 invoked by uid 3782); 20 Feb 2019 17:11:13 -0000 Received: from acm.muc.de (p4FE15C3F.dip0.t-ipconnect.de [79.225.92.63]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 20 Feb 2019 18:11:12 +0100 Received: (qmail 9860 invoked by uid 1000); 20 Feb 2019 17:07:22 -0000 Date: Wed, 20 Feb 2019 17:07:22 +0000 Message-ID: <20190220170722.GA9655@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83zhqtjdtz.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello again, Eli. On Mon, Feb 18, 2019 at 17:50:16 +0200, Eli Zaretskii wrote: > > From: Daniel Lopez > > Date: Mon, 18 Feb 2019 08:28:35 +0000 > > - Start "emacs -Q" and open the file BitmapFontFace.h > > - Evaluate the expression (replace-regexp "\\" "SharedBitmap") > > - The text "Replaced 8 occurrences" appears in the echo area. > > Problem: > > There were actually 12 occurrences (ie. of the word "Bitmap" surrounded > > by word boundaries) in the file that should have been replaced. If I now > > move point back to the start of the buffer and evaluate the expression > > again, it says "Replaced 4 occurrences". > > The exact number of incorrect replacements perhaps varies over time. > > That is, I can test it five times in a row and get 8 initial replacments > > each time, but after trying some other search terms, messing with the > > file, restarting Emacs etc, I try my initial test again and then maybe > > it consistently replaces 10 the first time, for a while. So your exact > > numbers may vary. > C++ Mode plays some funky games with the syntax of '<', so maybe this > is the consequence. CC'ing Alan, in the hope that he might have > something interesting to say about this. I have a lot interesting to say about this. Firstly, it is a difficult bug. I see the bug in master and Emacs 26.1 but not on Emacs 25.3. For the latter two, I tested with both -Q and --no-desktop in the command line. The bug would thus appear to be independent of the CC Mode version in use. The bug is definitely some sort of interaction between the regexp "\\" and the opening template delimiter < in code lines such as: std::vector< Bitmap > m_bitmaps; ^ . If a space is inserted before the marked <, the bug doesn't happen. Neither does it happen if the < is removed altogether. That < has a category property whose symbol contains the syntax-table property "(> " (i.e. "open paren" syntax with matching paren being ">"). I have checked, with a throwaway testing command, that all the Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 20 Feb 2019 18:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155068576532427 (code B ref 34525); Wed, 20 Feb 2019 18:03:02 +0000 Received: (at 34525) by debbugs.gnu.org; 20 Feb 2019 18:02:45 +0000 Received: from localhost ([127.0.0.1]:58431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwWCj-0008Qw-8j for submit@debbugs.gnu.org; Wed, 20 Feb 2019 13:02:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:41279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwWCf-0008Qh-Pf for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 13:02:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36556) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gwWCY-0004xx-UG; Wed, 20 Feb 2019 13:02:35 -0500 Received: from [176.228.60.248] (port=1084 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gwWCY-0001kb-I0; Wed, 20 Feb 2019 13:02:34 -0500 Date: Wed, 20 Feb 2019 20:02:45 +0200 Message-Id: <83sgwigwxm.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190220170722.GA9655@ACM> (message from Alan Mackenzie on Wed, 20 Feb 2019 17:07:22 +0000) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Wed, 20 Feb 2019 17:07:22 +0000 > Cc: Daniel Lopez , 34525@debbugs.gnu.org > From: Alan Mackenzie > > I think there's some unwanted interaction between redisplay, the syntax > functionality (in particular, the syntax-table text property), and the > regexp machinery. If you enlarge the dimensions of the window and/or decrease the size of the font, so that most or all of the text is visible at once, does that affect the number of matches found? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 20 Feb 2019 19:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15506893695343 (code B ref 34525); Wed, 20 Feb 2019 19:03:02 +0000 Received: (at 34525) by debbugs.gnu.org; 20 Feb 2019 19:02:49 +0000 Received: from localhost ([127.0.0.1]:58467 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwX8r-0001O6-9y for submit@debbugs.gnu.org; Wed, 20 Feb 2019 14:02:49 -0500 Received: from colin.muc.de ([193.149.48.1]:63188 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gwX8p-0001Nx-2d for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 14:02:48 -0500 Received: (qmail 88163 invoked by uid 3782); 20 Feb 2019 19:02:42 -0000 Received: from acm.muc.de (p4FE15C3F.dip0.t-ipconnect.de [79.225.92.63]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 20 Feb 2019 20:02:40 +0100 Received: (qmail 10618 invoked by uid 1000); 20 Feb 2019 18:58:50 -0000 Date: Wed, 20 Feb 2019 18:58:50 +0000 Message-ID: <20190220185850.GB9655@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83sgwigwxm.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Wed, Feb 20, 2019 at 20:02:45 +0200, Eli Zaretskii wrote: > > Date: Wed, 20 Feb 2019 17:07:22 +0000 > > Cc: Daniel Lopez , 34525@debbugs.gnu.org > > From: Alan Mackenzie > > I think there's some unwanted interaction between redisplay, the syntax > > functionality (in particular, the syntax-table text property), and the > > regexp machinery. > If you enlarge the dimensions of the window and/or decrease the size > of the font, so that most or all of the text is visible at once, does > that affect the number of matches found? It appears not to. I reduced the font size from 11 to 6, and enlarged the frame to compensate, giving a window displaying 95 lines. C-u M-% Bitmap -> SharedBitmap, on pressing s, visibly skipped lazily highlighted occurrences of Bitmap. In the end, just 6 matches (out of 12) got replaced. Just as a matter of interest, my initial observations were on a Linux virtual terminal (with a fixed window size of 65 lines), the above was in X-Windows. It would seem there is more to it than redisplay. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 20 Feb 2019 19:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15506908687812 (code B ref 34525); Wed, 20 Feb 2019 19:28:01 +0000 Received: (at 34525) by debbugs.gnu.org; 20 Feb 2019 19:27:48 +0000 Received: from localhost ([127.0.0.1]:58557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwXX2-00021w-D0 for submit@debbugs.gnu.org; Wed, 20 Feb 2019 14:27:48 -0500 Received: from eggs.gnu.org ([209.51.188.92]:39226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwXX0-00021k-Gj for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 14:27:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:38052) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gwXWo-0003HQ-8e; Wed, 20 Feb 2019 14:27:37 -0500 Received: from [176.228.60.248] (port=2651 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gwXWi-0003di-An; Wed, 20 Feb 2019 14:27:29 -0500 Date: Wed, 20 Feb 2019 21:27:24 +0200 Message-Id: <83lg2agt0j.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190220185850.GB9655@ACM> (message from Alan Mackenzie on Wed, 20 Feb 2019 18:58:50 +0000) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Wed, 20 Feb 2019 18:58:50 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > From: Alan Mackenzie > > It would seem there is more to it than redisplay. Maybe look at this from a different angle: what do we have in C++ mode that isn't present in C mode, and could potentially affect this use case? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Daniel Lopez Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 20 Feb 2019 21:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie , Eli Zaretskii Cc: 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155069804919681 (code B ref 34525); Wed, 20 Feb 2019 21:28:02 +0000 Received: (at 34525) by debbugs.gnu.org; 20 Feb 2019 21:27:29 +0000 Received: from localhost ([127.0.0.1]:58641 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwZOr-00057N-3z for submit@debbugs.gnu.org; Wed, 20 Feb 2019 16:27:29 -0500 Received: from mail-wr1-f44.google.com ([209.85.221.44]:37363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwZOp-00057A-DK for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 16:27:27 -0500 Received: by mail-wr1-f44.google.com with SMTP id c8so27680094wrs.4 for <34525@debbugs.gnu.org>; Wed, 20 Feb 2019 13:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=DQEr4NIOoljvuKG4TvfwneWgWgkf4nNQnNjht6HCwRw=; b=Q3BYuWCtCIeENDxeDEBq5CArc4vRJGTI3ofKMbrAGGQyC+salFhpn9jVJGrZ6ClsUS acXx6G3CreJ37QIkTRZKgQl1WK+FsHhCTOuq6WiYKy5PVKNapFBQ7yc2zFZETQ8Dz6Ha WAVQL3wiTM6q1IT5im6P3lJLpDByjSwj6Vtz4udHyVZUcpw5i/a5BYsg55TopbKjE90M WvZFhdTjNzKsKs0AUJeGCBbDtdUstC2IS/D10Y29Z/z5F6fhNqrzTZLX9JlXGSxh5csn u3ALPH19BUS2TyV4hEf0mrxOKFz6bu1u2yohKPzNz9IGxt6UxTbH+chLma6q6Bsu6s8U A/ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=DQEr4NIOoljvuKG4TvfwneWgWgkf4nNQnNjht6HCwRw=; b=M/Mz6eDubhjBOTCfsmN48BYezrX/z87wsViTG2z573IZMbt4UFuccLderNJOqjiw0c QBO0EklX13AZSSMskNEfWjxYE8nZLHPZpkuPpmXCT3fYAGIPuKD4tSZPDYhdGAGb+GuY oBebayjOWIO9jP+cIHcgvRzFo6jI1oP4X+dfFWXsMLBBOCUeERE42FKSclM3lRkY1cKJ wYonTNJFDIhm+0JPTUyQRDGaTCysu3TNLDE1TQFO1la9cXTBpD4yK+DIZ0F7N4PwlKLK jYToVfkdIyoKLvViHZrhejU0Fb+A+cf/cHBuk+4HGAoldRk8irVwe83k6plWfylWhIK1 07iA== X-Gm-Message-State: AHQUAuavNgwGCvoo/An8DLv8MVXsihBnFExDAlbj6WA8yx3hjKlhGCgP F/59POXTKOh1wBGmuHPjnvFX6rOt X-Google-Smtp-Source: AHgI3Ial5TxUB8jqdyA3tOfcw4QEamkbW0CGU0RTLvoTKerUKbWawgQ9h4j85R6tH9nrE8j9onDfOQ== X-Received: by 2002:adf:f3d0:: with SMTP id g16mr25642957wrp.29.1550698040137; Wed, 20 Feb 2019 13:27:20 -0800 (PST) Received: from [192.168.2.2] (w-79.cust-5765.ip.static.uno.uk.net. [95.172.231.79]) by smtp.googlemail.com with ESMTPSA id y22sm74160585wrd.45.2019.02.20.13.27.18 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 20 Feb 2019 13:27:18 -0800 (PST) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> From: Daniel Lopez Message-ID: <0e2f5e3a-4a1c-a118-5970-9053215ac7f0@gmail.com> Date: Wed, 20 Feb 2019 21:25:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190220185850.GB9655@ACM> Content-Type: multipart/mixed; boundary="------------E0073939F2DC5EB7FD5D2686" Content-Language: en-US-large 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 (/) This is a multi-part message in MIME format. --------------E0073939F2DC5EB7FD5D2686 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Eli and Alan, Thanks for investigating. Don't know if this is of much help, but here's a simpler test file (BitmapFontFace4.h). If I delete all the "YBitmapZ" lines so that only the full-word occurrences of "Bitmap" are left in the file, then C-u M-% replaces everything but replace-regexp doesn't still. Daniel --------------E0073939F2DC5EB7FD5D2686 Content-Type: text/x-chdr; name="BitmapFontFace4.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="BitmapFontFace4.h" class FontFace { protected: FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; FontFace(const std::vector & i_param) {} YBitmapZ; }; --------------E0073939F2DC5EB7FD5D2686-- From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 20 Feb 2019 21:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155069843820443 (code B ref 34525); Wed, 20 Feb 2019 21:34:02 +0000 Received: (at 34525) by debbugs.gnu.org; 20 Feb 2019 21:33:58 +0000 Received: from localhost ([127.0.0.1]:58658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwZV8-0005Je-FG for submit@debbugs.gnu.org; Wed, 20 Feb 2019 16:33:58 -0500 Received: from colin.muc.de ([193.149.48.1]:48198 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gwZV5-0005JV-Uh for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 16:33:57 -0500 Received: (qmail 42745 invoked by uid 3782); 20 Feb 2019 21:33:54 -0000 Received: from acm.muc.de (p4FE15C3F.dip0.t-ipconnect.de [79.225.92.63]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 20 Feb 2019 22:33:53 +0100 Received: (qmail 11138 invoked by uid 1000); 20 Feb 2019 21:30:03 -0000 Date: Wed, 20 Feb 2019 21:30:03 +0000 Message-ID: <20190220213003.GC9655@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83lg2agt0j.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Wed, Feb 20, 2019 at 21:27:24 +0200, Eli Zaretskii wrote: > > Date: Wed, 20 Feb 2019 18:58:50 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > It would seem there is more to it than redisplay. > Maybe look at this from a different angle: what do we have in C++ mode > that isn't present in C mode, and could potentially affect this use > case? Well, the most obvious thing is the category text property whose value is the symbol c-<-as-paren-syntax. This symbol's plist is (risky-local-variable t syntax-table (4 . 62)) . I can't think of anything else at the moment. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 21 Feb 2019 03:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15507204745267 (code B ref 34525); Thu, 21 Feb 2019 03:42:01 +0000 Received: (at 34525) by debbugs.gnu.org; 21 Feb 2019 03:41:14 +0000 Received: from localhost ([127.0.0.1]:58882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwfEX-0001Ms-II for submit@debbugs.gnu.org; Wed, 20 Feb 2019 22:41:13 -0500 Received: from eggs.gnu.org ([209.51.188.92]:50189) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gwfET-0001Md-MU for 34525@debbugs.gnu.org; Wed, 20 Feb 2019 22:41:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gwfEA-0002uV-Vp; Wed, 20 Feb 2019 22:40:53 -0500 Received: from [176.228.60.248] (port=1205 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gwfE9-0002KN-3F; Wed, 20 Feb 2019 22:40:50 -0500 Date: Thu, 21 Feb 2019 05:40:47 +0200 Message-Id: <83bm35hkqo.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190220213003.GC9655@ACM> (message from Alan Mackenzie on Wed, 20 Feb 2019 21:30:03 +0000) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Wed, 20 Feb 2019 21:30:03 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > From: Alan Mackenzie > > > Maybe look at this from a different angle: what do we have in C++ mode > > that isn't present in C mode, and could potentially affect this use > > case? > > Well, the most obvious thing is the category text property whose value > is the symbol c-<-as-paren-syntax. This symbol's plist is > > (risky-local-variable t syntax-table (4 . 62)) > > . I can't think of anything else at the moment. If you remove that, does the problem go away? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 22 Feb 2019 16:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Daniel Lopez Cc: Eli Zaretskii , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15508530141961 (code B ref 34525); Fri, 22 Feb 2019 16:31:01 +0000 Received: (at 34525) by debbugs.gnu.org; 22 Feb 2019 16:30:14 +0000 Received: from localhost ([127.0.0.1]:48532 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxDiI-0000VZ-2t for submit@debbugs.gnu.org; Fri, 22 Feb 2019 11:30:14 -0500 Received: from colin.muc.de ([193.149.48.1]:60919 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gxDiG-0000VO-1y for 34525@debbugs.gnu.org; Fri, 22 Feb 2019 11:30:12 -0500 Received: (qmail 36837 invoked by uid 3782); 22 Feb 2019 16:30:08 -0000 Received: from acm.muc.de (p4FE15C05.dip0.t-ipconnect.de [79.225.92.5]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 22 Feb 2019 17:30:07 +0100 Received: (qmail 5435 invoked by uid 1000); 22 Feb 2019 16:26:03 -0000 Date: Fri, 22 Feb 2019 16:26:03 +0000 Message-ID: <20190222162603.GA5411@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <0e2f5e3a-4a1c-a118-5970-9053215ac7f0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e2f5e3a-4a1c-a118-5970-9053215ac7f0@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Daniel. On Wed, Feb 20, 2019 at 21:25:27 +0000, Daniel Lopez wrote: > Hi Eli and Alan, > Thanks for investigating. > Don't know if this is of much help, but here's a simpler test file > (BitmapFontFace4.h). Thanks for this. I will have a look at it later. > If I delete all the "YBitmapZ" lines so that only the full-word > occurrences of "Bitmap" are left in the file, then C-u M-% replaces > everything but replace-regexp doesn't still. What I have established so far is that it is the < template delimiter interacting in some unknown way with Bitmap, which is causing the bug. For example, when I replace "Bitmap<" with "Bitmap <", the bug doesn't happen. The bug doesn't happen either if these Daniel -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 24 Feb 2019 17:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, Stefan Monnier , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155103014220269 (code B ref 34525); Sun, 24 Feb 2019 17:43:02 +0000 Received: (at 34525) by debbugs.gnu.org; 24 Feb 2019 17:42:22 +0000 Received: from localhost ([127.0.0.1]:50406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxxnB-0005Gp-IZ for submit@debbugs.gnu.org; Sun, 24 Feb 2019 12:42:21 -0500 Received: from colin.muc.de ([193.149.48.1]:25849 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gxxn5-0005Gb-FU for 34525@debbugs.gnu.org; Sun, 24 Feb 2019 12:42:16 -0500 Received: (qmail 86828 invoked by uid 3782); 24 Feb 2019 17:42:10 -0000 Received: from acm.muc.de (p2E5D538C.dip0.t-ipconnect.de [46.93.83.140]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 24 Feb 2019 18:42:09 +0100 Received: (qmail 21852 invoked by uid 1000); 24 Feb 2019 17:37:46 -0000 Date: Sun, 24 Feb 2019 17:37:46 +0000 Message-ID: <20190224173746.GA21808@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83bm35hkqo.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, everybody. On Thu, Feb 21, 2019 at 05:40:47 +0200, Eli Zaretskii wrote: > > Date: Wed, 20 Feb 2019 21:30:03 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > > Maybe look at this from a different angle: what do we have in C++ mode > > > that isn't present in C mode, and could potentially affect this use > > > case? > > Well, the most obvious thing is the category text property whose value > > is the symbol c-<-as-paren-syntax. This symbol's plist is > > (risky-local-variable t syntax-table (4 . 62)) > > . I can't think of anything else at the moment. > If you remove that, does the problem go away? I'm afraid I didn't get around to trying that. But I've been busy with GDB. The query-replace word ends up calling re-search-forward. Fre_search_forward ends up calling re_search_2 (which is called rpl_re_search_2 in gdb. :-( ). This calls re_match_2_internal, which scans through the compiled regexp, "\". Up till now, we have said yes to replace the first Bitmap with SharedBitmap in query-replace. Emacs is now seeking out the second occurrence of Bitmap, which is on L69 of the OP's test file, and looks like "Bitmap<", where the < has a syntax-table text property of (4 . 62), an opening paren which matches ">". re_natch_2_internal finds its way to case wordbeg: to handle the "\<" of the regexp. It invokes UPDATE_SYNTAX_TABLE (charpos) to get the syntax for the "B" it has already found. Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for the current contents of position 1948, but the contents of 1948 before the change at the top of the buffer (Bitmap -> SharedBitmap) was made. So it picks up the syntax for the "<" rather than the "B". Since this syntax, (4 . 62) is not the start of a word, re_match_2_internal returns a failure result. I think the glitch is in the text property interval handling code. It is as though after the replacement of Bitmap by SharedBitmap, the interval starting positions have not been adjusted for the extra six characters. I tested this theory by putting a space between the Bitmap and <, and attempting a query-replace of Bitmap with 1234567Bitmap. The error still occurred. In this buffer, the original replacement then appears to work. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 24 Feb 2019 17:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155103097521481 (code B ref 34525); Sun, 24 Feb 2019 17:57:01 +0000 Received: (at 34525) by debbugs.gnu.org; 24 Feb 2019 17:56:15 +0000 Received: from localhost ([127.0.0.1]:50426 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxy0c-0005aP-M3 for submit@debbugs.gnu.org; Sun, 24 Feb 2019 12:56:14 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40900) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gxy0b-0005aC-1I for 34525@debbugs.gnu.org; Sun, 24 Feb 2019 12:56:13 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gxy0U-0000Q5-3g; Sun, 24 Feb 2019 12:56:06 -0500 Received: from [176.228.60.248] (port=2939 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gxy0T-0006cn-Nw; Sun, 24 Feb 2019 12:56:06 -0500 Date: Sun, 24 Feb 2019 19:56:13 +0200 Message-Id: <83mumlnk8y.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190224173746.GA21808@ACM> (message from Alan Mackenzie on Sun, 24 Feb 2019 17:37:46 +0000) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Sun, 24 Feb 2019 17:37:46 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, > Stefan Monnier > From: Alan Mackenzie > > The query-replace word ends up calling re-search-forward. > Fre_search_forward ends up calling re_search_2 (which is called > rpl_re_search_2 in gdb. :-( ). > > This calls re_match_2_internal, which scans through the compiled regexp, > "\". > > Up till now, we have said yes to replace the first Bitmap with > SharedBitmap in query-replace. Emacs is now seeking out the second > occurrence of Bitmap, which is on L69 of the OP's test file, and looks > like "Bitmap<", where the < has a syntax-table text property of (4 . 62), > an opening paren which matches ">". > > re_natch_2_internal finds its way to case wordbeg: to handle the "\<" of > the regexp. It invokes UPDATE_SYNTAX_TABLE (charpos) to get the syntax > for the "B" it has already found. > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > the current contents of position 1948, but the contents of 1948 before > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > So it picks up the syntax for the "<" rather than the "B". Are you saying that we've modified buffer text, but re_match_2_internal still holds to a C pointer to buffer text before the change? If so, it's a simple manner of recomputing the C pointer using the buffer position after the change, right? We do such things in a few places, like coding.c, by recording the offset of the text before the change and reapplying it after the change. > I think the glitch is in the text property interval handling code. It is > as though after the replacement of Bitmap by SharedBitmap, the interval > starting positions have not been adjusted for the extra six characters. If the code has variables that record C pointers to buffer text, those need to be updated after every change, of else they will become invalid. But I'm surprised we have such blatant bugs in such veteran code, so I'm probably missing something. Can you describe the above again, this time showing the relevant code fragments and variables involved in this? Thanks. From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Sun, 24 Feb 2019 21:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15510423297337 (code B ref 34525); Sun, 24 Feb 2019 21:06:02 +0000 Received: (at 34525) by debbugs.gnu.org; 24 Feb 2019 21:05:29 +0000 Received: from localhost ([127.0.0.1]:50568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gy0xl-0001uH-CI for submit@debbugs.gnu.org; Sun, 24 Feb 2019 16:05:29 -0500 Received: from colin.muc.de ([193.149.48.1]:27015 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gy0xi-0001u7-99 for 34525@debbugs.gnu.org; Sun, 24 Feb 2019 16:05:27 -0500 Received: (qmail 97914 invoked by uid 3782); 24 Feb 2019 21:05:23 -0000 Received: from acm.muc.de (p2E5D538C.dip0.t-ipconnect.de [46.93.83.140]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 24 Feb 2019 22:05:21 +0100 Received: (qmail 21566 invoked by uid 1000); 24 Feb 2019 21:00:58 -0000 Date: Sun, 24 Feb 2019 21:00:58 +0000 Message-ID: <20190224210058.GB21808@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83mumlnk8y.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Sun, Feb 24, 2019 at 19:56:13 +0200, Eli Zaretskii wrote: > > Date: Sun, 24 Feb 2019 17:37:46 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, > > Stefan Monnier > > From: Alan Mackenzie > > The query-replace word ends up calling re-search-forward. > > Fre_search_forward ends up calling re_search_2 (which is called > > rpl_re_search_2 in gdb. :-( ). > > This calls re_match_2_internal, which scans through the compiled regexp, > > "\". > > Up till now, we have said yes to replace the first Bitmap with > > SharedBitmap in query-replace. Emacs is now seeking out the second > > occurrence of Bitmap, which is on L69 of the OP's test file, and looks > > like "Bitmap<", where the < has a syntax-table text property of (4 . 62), > > an opening paren which matches ">". > > re_natch_2_internal finds its way to case wordbeg: to handle the "\<" of > > the regexp. It invokes UPDATE_SYNTAX_TABLE (charpos) to get the syntax > > for the "B" it has already found. > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > > the current contents of position 1948, but the contents of 1948 before > > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > > So it picks up the syntax for the "<" rather than the "B". > Are you saying that we've modified buffer text, but > re_match_2_internal still holds to a C pointer to buffer text before > the change? I don't think that's the case. The relevant buffer pointers/sizes are calculated (in search_buffer_re) as p1 = BEGV_ADDR; s1 = GPT_BYTE - BEGV_BYTE; p2 = GAP_END_ADDR; s2 = ZV_BYTE - GPT_BYTE; each time before a search. > If so, it's a simple manner of recomputing the C pointer using the > buffer position after the change, right? We do such things in a few > places, like coding.c, by recording the offset of the text before the > change and reapplying it after the change. > > I think the glitch is in the text property interval handling code. > > It is as though after the replacement of Bitmap by SharedBitmap, the > > interval starting positions have not been adjusted for the extra six > > characters. > If the code has variables that record C pointers to buffer text, those > need to be updated after every change, of else they will become > invalid. > But I'm surprised we have such blatant bugs in such veteran code, .... The bug was introduced sometime between 25.3 and 26.1. I tried to bisect the commits between 25.2 and 26.1, but couldn't, because autogen.sh was broken in lots of the pertinent commits, so I couldn't build these Emacs versions. > .... so I'm probably missing something. Can you describe the above > again, this time showing the relevant code fragments and variables > involved in this? I'm afraid my gdb session is too long and chaotic to extract anything meaningful out of. I'll have to recreate it more purposefully, to get these results. Not tonight! We'll get this sorted out. > Thanks. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 25 Feb 2019 20:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155112553012991 (code B ref 34525); Mon, 25 Feb 2019 20:13:02 +0000 Received: (at 34525) by debbugs.gnu.org; 25 Feb 2019 20:12:10 +0000 Received: from localhost ([127.0.0.1]:51763 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyMbi-0003NS-5n for submit@debbugs.gnu.org; Mon, 25 Feb 2019 15:12:10 -0500 Received: from eggs.gnu.org ([209.51.188.92]:36783) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyMbf-0003N5-FK for 34525@debbugs.gnu.org; Mon, 25 Feb 2019 15:12:08 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44758) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyMbM-0004Qm-9W; Mon, 25 Feb 2019 15:11:52 -0500 Received: from [176.228.60.248] (port=4499 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyMbL-0007gI-0i; Mon, 25 Feb 2019 15:11:48 -0500 Date: Mon, 25 Feb 2019 22:11:57 +0200 Message-Id: <83mumjmxv6.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190224210058.GB21808@ACM> (message from Alan Mackenzie on Sun, 24 Feb 2019 21:00:58 +0000) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Sun, 24 Feb 2019 21:00:58 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, monnier@iro.umontreal.ca > From: Alan Mackenzie > > > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > > > the current contents of position 1948, but the contents of 1948 before > > > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > > > So it picks up the syntax for the "<" rather than the "B". > > > Are you saying that we've modified buffer text, but > > re_match_2_internal still holds to a C pointer to buffer text before > > the change? > > I don't think that's the case. The relevant buffer pointers/sizes are > calculated (in search_buffer_re) as > > p1 = BEGV_ADDR; > s1 = GPT_BYTE - BEGV_BYTE; > p2 = GAP_END_ADDR; > s2 = ZV_BYTE - GPT_BYTE; > > each time before a search. So you are saying that gl_state uses a stale offset, which should have been updated due to the previous replacements? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Mon, 25 Feb 2019 20:54:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155112801616607 (code B ref 34525); Mon, 25 Feb 2019 20:54:01 +0000 Received: (at 34525) by debbugs.gnu.org; 25 Feb 2019 20:53:36 +0000 Received: from localhost ([127.0.0.1]:51783 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyNFo-0004Jn-ES for submit@debbugs.gnu.org; Mon, 25 Feb 2019 15:53:36 -0500 Received: from colin.muc.de ([193.149.48.1]:47891 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gyNFm-0004Je-2Z for 34525@debbugs.gnu.org; Mon, 25 Feb 2019 15:53:35 -0500 Received: (qmail 14555 invoked by uid 3782); 25 Feb 2019 20:53:30 -0000 Received: from acm.muc.de (p4FE15D69.dip0.t-ipconnect.de [79.225.93.105]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 25 Feb 2019 21:53:29 +0100 Received: (qmail 5580 invoked by uid 1000); 25 Feb 2019 20:48:58 -0000 Date: Mon, 25 Feb 2019 20:48:58 +0000 Message-ID: <20190225204858.GB3605@ACM> References: <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83mumjmxv6.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Mon, Feb 25, 2019 at 22:11:57 +0200, Eli Zaretskii wrote: > > Date: Sun, 24 Feb 2019 21:00:58 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, monnier@iro.umontreal.ca > > From: Alan Mackenzie > > > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > > > > the current contents of position 1948, but the contents of 1948 before > > > > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > > > > So it picks up the syntax for the "<" rather than the "B". > > > Are you saying that we've modified buffer text, but > > > re_match_2_internal still holds to a C pointer to buffer text before > > > the change? > > I don't think that's the case. The relevant buffer pointers/sizes are > > calculated (in search_buffer_re) as > > p1 = BEGV_ADDR; > > s1 = GPT_BYTE - BEGV_BYTE; > > p2 = GAP_END_ADDR; > > s2 = ZV_BYTE - GPT_BYTE; > > each time before a search. > So you are saying that gl_state uses a stale offset, which should have > been updated due to the previous replacements? That's what I think is happening, yes. I need to gather more evidence, though. I've spent a lot of today fighting git and 2-year-old Emacs's build systems trying to bisect the repository to find what introduced the bug. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 13:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15511893398442 (code B ref 34525); Tue, 26 Feb 2019 13:56:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 13:55:39 +0000 Received: from localhost ([127.0.0.1]:52358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gydCs-0002C5-JL for submit@debbugs.gnu.org; Tue, 26 Feb 2019 08:55:38 -0500 Received: from colin.muc.de ([193.149.48.1]:46468 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gydCm-0002Bp-94 for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 08:55:33 -0500 Received: (qmail 92711 invoked by uid 3782); 26 Feb 2019 13:55:28 -0000 Received: from acm.muc.de (p4FE15DD0.dip0.t-ipconnect.de [79.225.93.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Feb 2019 14:55:27 +0100 Received: (qmail 19731 invoked by uid 1000); 26 Feb 2019 13:50:48 -0000 Date: Tue, 26 Feb 2019 13:50:48 +0000 Message-ID: <20190226135048.GA19653@ACM> References: <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83mumjmxv6.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Mon, Feb 25, 2019 at 22:11:57 +0200, Eli Zaretskii wrote: > > Date: Sun, 24 Feb 2019 21:00:58 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, monnier@iro.umontreal.ca > > From: Alan Mackenzie > > > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > > > > the current contents of position 1948, but the contents of 1948 before > > > > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > > > > So it picks up the syntax for the "<" rather than the "B". > > > Are you saying that we've modified buffer text, but > > > re_match_2_internal still holds to a C pointer to buffer text before > > > the change? > > I don't think that's the case. The relevant buffer pointers/sizes are > > calculated (in search_buffer_re) as > > p1 = BEGV_ADDR; > > s1 = GPT_BYTE - BEGV_BYTE; > > p2 = GAP_END_ADDR; > > s2 = ZV_BYTE - GPT_BYTE; > > each time before a search. > So you are saying that gl_state uses a stale offset, which should have > been updated due to the previous replacements? More precisely, I think that the interval containing "Bitmap<" has not been adjusted after the replacement of "Bitmap.h" by "SharedBitmap.h" early in the .h file. After this buffer change, adjust_intervals_for_insertion gets called. This adds 6 onto the ->position field of each interval "adjusting all of its ancestors by adding LENGTH to them", according to the comment at the head of adjust_intervals_for_insertion. Note this only adjusts the ancestors of that interval early in the .h file, not all intervals in the tree. gl_state contains a cached interval, gl_state->backward_i, and there is no guarantee that its ->position will have been updated by adjust_intervals_for_insertion. In the current bug, I believe it hasn't been adjusted. The function update_syntax_table uses gl_state->backward_i to manoevre its way to the current interval using update_interval. If gl_state->backward_i->position hasn't already been adjusted for the insertion, the interval update_interval returns won't have been adjusted either. I'm reasonably sure this is what's happening: adjust_intervals_for_insertion is failing to adjust the cached intervals in gl_state. It's a nasty cache invalidation problem. I don't know how best to fix this. Maybe a_i_f_insertion/deletion could set a global flag which would signal to update_syntax_table that its intervals are not reliable. But that's horribly ugly. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 15:06:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155119351523306 (code B ref 34525); Tue, 26 Feb 2019 15:06:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 15:05:15 +0000 Received: from localhost ([127.0.0.1]:53174 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyeIF-00063q-8o for submit@debbugs.gnu.org; Tue, 26 Feb 2019 10:05:15 -0500 Received: from colin.muc.de ([193.149.48.1]:12048 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gyeIC-00063e-MC for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 10:05:13 -0500 Received: (qmail 19119 invoked by uid 3782); 26 Feb 2019 15:05:09 -0000 Received: from acm.muc.de (p4FE15DD0.dip0.t-ipconnect.de [79.225.93.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Feb 2019 16:05:07 +0100 Received: (qmail 20158 invoked by uid 1000); 26 Feb 2019 15:00:28 -0000 Date: Tue, 26 Feb 2019 15:00:28 +0000 Message-ID: <20190226150028.GB19653@ACM> References: <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190226135048.GA19653@ACM> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, again, Eli. On Tue, Feb 26, 2019 at 13:50:48 +0000, Alan Mackenzie wrote: > On Mon, Feb 25, 2019 at 22:11:57 +0200, Eli Zaretskii wrote: > > > Date: Sun, 24 Feb 2019 21:00:58 +0000 > > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, monnier@iro.umontreal.ca > > > From: Alan Mackenzie > > > > > Sadly, UPDATE_SYNTAX_TABLE sets its internal structure gl_state not for > > > > > the current contents of position 1948, but the contents of 1948 before > > > > > the change at the top of the buffer (Bitmap -> SharedBitmap) was made. > > > > > So it picks up the syntax for the "<" rather than the "B". > > > > Are you saying that we've modified buffer text, but > > > > re_match_2_internal still holds to a C pointer to buffer text before > > > > the change? > > > I don't think that's the case. The relevant buffer pointers/sizes are > > > calculated (in search_buffer_re) as > > > p1 = BEGV_ADDR; > > > s1 = GPT_BYTE - BEGV_BYTE; > > > p2 = GAP_END_ADDR; > > > s2 = ZV_BYTE - GPT_BYTE; > > > each time before a search. > > So you are saying that gl_state uses a stale offset, which should have > > been updated due to the previous replacements? > More precisely, I think that the interval containing "Bitmap<" has not > been adjusted after the replacement of "Bitmap.h" by "SharedBitmap.h" > early in the .h file. > After this buffer change, adjust_intervals_for_insertion gets called. > This adds 6 onto the ->position field of each interval "adjusting all of > its ancestors by adding LENGTH to them", according to the comment at the > head of adjust_intervals_for_insertion. > Note this only adjusts the ancestors of that interval early in the .h > file, not all intervals in the tree. > gl_state contains a cached interval, gl_state->backward_i, and there is > no guarantee that its ->position will have been updated by > adjust_intervals_for_insertion. In the current bug, I believe it hasn't > been adjusted. > The function update_syntax_table uses gl_state->backward_i to manoevre > its way to the current interval using update_interval. If > gl_state->backward_i->position hasn't already been adjusted for the > insertion, the interval update_interval returns won't have been adjusted > either. > I'm reasonably sure this is what's happening: > adjust_intervals_for_insertion is failing to adjust the cached intervals > in gl_state. It's a nasty cache invalidation problem. > I don't know how best to fix this. Maybe a_i_f_insertion/deletion could > set a global flag which would signal to update_syntax_table that its > intervals are not reliable. But that's horribly ugly. How about the following idea: (i) We introduce a new boolean flag `adjusted' into struct interval. (ii) When we adjust ->position in an interval in adjust_intervals_for_insertion/deletion, we set `adjusted' there. (iii) At the end of a_i_f_insertion/deletion, we adjust gl_state's intervals, going to the parent as long as `adjusted' is not yet true. (iv) We clear all the set `adjusted' flags. A simpler, but slower, alternative would be to set gl_state's intervals to NULL on any buffer change earlier in the buffer. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 15:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155119539926210 (code B ref 34525); Tue, 26 Feb 2019 15:37:02 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 15:36:39 +0000 Received: from localhost ([127.0.0.1]:53205 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyemd-0006of-AL for submit@debbugs.gnu.org; Tue, 26 Feb 2019 10:36:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59070) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyema-0006oR-2Y for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 10:36:37 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyemM-0002Vs-Ra; Tue, 26 Feb 2019 10:36:24 -0500 Received: from [176.228.60.248] (port=4486 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyemK-00038L-Ax; Tue, 26 Feb 2019 10:36:22 -0500 Date: Tue, 26 Feb 2019 17:36:33 +0200 Message-Id: <835zt6muim.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190226135048.GA19653@ACM> (message from Alan Mackenzie on Tue, 26 Feb 2019 13:50:48 +0000) References: <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Tue, 26 Feb 2019 13:50:48 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org, monnier@iro.umontreal.ca > From: Alan Mackenzie > > > So you are saying that gl_state uses a stale offset, which should have > > been updated due to the previous replacements? > > More precisely, I think that the interval containing "Bitmap<" has not > been adjusted after the replacement of "Bitmap.h" by "SharedBitmap.h" > early in the .h file. In general, I don't believe this can happen, because otherwise we would see the faces in the wrong places. The interval tree does get updated after each buffer change. However, if some interval data is cached, as you seem to imply: > gl_state contains a cached interval, gl_state->backward_i, and there is > no guarantee that its ->position will have been updated by > adjust_intervals_for_insertion. In the current bug, I believe it hasn't > been adjusted. then yes, that cached interval data might not be updated. But I wonder why you say "there is no guarantee" -- don't you actually see stale data there in this scenario? > The function update_syntax_table uses gl_state->backward_i to manoevre > its way to the current interval using update_interval. If > gl_state->backward_i->position hasn't already been adjusted for the > insertion, the interval update_interval returns won't have been adjusted > either. > > I'm reasonably sure this is what's happening: > adjust_intervals_for_insertion is failing to adjust the cached intervals > in gl_state. It's a nasty cache invalidation problem. Do we really have to guess here? Isn't there anyone who knows how this works? Stefan? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 15:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155119558626535 (code B ref 34525); Tue, 26 Feb 2019 15:40:02 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 15:39:46 +0000 Received: from localhost ([127.0.0.1]:53217 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyepd-0006tv-K7 for submit@debbugs.gnu.org; Tue, 26 Feb 2019 10:39:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:59832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyepc-0006ti-9H for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 10:39:44 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:34689) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyepQ-0003xM-03; Tue, 26 Feb 2019 10:39:35 -0500 Received: from [176.228.60.248] (port=4680 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyepP-0000fW-1v; Tue, 26 Feb 2019 10:39:31 -0500 Date: Tue, 26 Feb 2019 17:39:44 +0200 Message-Id: <834l8qmudb.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190226150028.GB19653@ACM> (message from Alan Mackenzie on Tue, 26 Feb 2019 15:00:28 +0000) References: <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226150028.GB19653@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Tue, 26 Feb 2019 15:00:28 +0000 > Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org > From: Alan Mackenzie > > A simpler, but slower, alternative would be to set gl_state's intervals > to NULL on any buffer change earlier in the buffer. If you implement this simpler method as an experiment, does the problem go away? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 16:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155119777629977 (code B ref 34525); Tue, 26 Feb 2019 16:17:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 16:16:16 +0000 Received: from localhost ([127.0.0.1]:53242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyfOy-0007nR-4E for submit@debbugs.gnu.org; Tue, 26 Feb 2019 11:16:16 -0500 Received: from colin.muc.de ([193.149.48.1]:12859 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gyfOt-0007nG-Jy for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 11:16:14 -0500 Received: (qmail 65399 invoked by uid 3782); 26 Feb 2019 16:16:09 -0000 Received: from acm.muc.de (p4FE15DD0.dip0.t-ipconnect.de [79.225.93.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Feb 2019 17:16:08 +0100 Received: (qmail 21068 invoked by uid 1000); 26 Feb 2019 16:11:29 -0000 Date: Tue, 26 Feb 2019 16:11:29 +0000 Message-ID: <20190226161129.GC19653@ACM> References: <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226150028.GB19653@ACM> <834l8qmudb.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <834l8qmudb.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Tue, Feb 26, 2019 at 17:39:44 +0200, Eli Zaretskii wrote: > > Date: Tue, 26 Feb 2019 15:00:28 +0000 > > Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > A simpler, but slower, alternative would be to set gl_state's intervals > > to NULL on any buffer change earlier in the buffer. > If you implement this simpler method as an experiment, does the > problem go away? Yes! :-) What I actually did was at the start of update_syntax_table, always load the interval `i' from scratch, overwriting any stored interval cache in gl_state. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 16:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155119935632242 (code B ref 34525); Tue, 26 Feb 2019 16:43:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 16:42:36 +0000 Received: from localhost ([127.0.0.1]:53247 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyfoS-0008Ny-DJ for submit@debbugs.gnu.org; Tue, 26 Feb 2019 11:42:36 -0500 Received: from eggs.gnu.org ([209.51.188.92]:44569) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyfoQ-0008Nl-5L for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 11:42:34 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:35669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gyfoH-0002Wb-Od; Tue, 26 Feb 2019 11:42:25 -0500 Received: from [176.228.60.248] (port=1130 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gyfoG-0005io-Bn; Tue, 26 Feb 2019 11:42:25 -0500 Date: Tue, 26 Feb 2019 18:42:36 +0200 Message-Id: <83va16lcw3.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190226161129.GC19653@ACM> (message from Alan Mackenzie on Tue, 26 Feb 2019 16:11:29 +0000) References: <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226150028.GB19653@ACM> <834l8qmudb.fsf@gnu.org> <20190226161129.GC19653@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Tue, 26 Feb 2019 16:11:29 +0000 > Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org > From: Alan Mackenzie > > > If you implement this simpler method as an experiment, does the > > problem go away? > > Yes! :-) > > What I actually did was at the start of update_syntax_table, always load > the interval `i' from scratch, overwriting any stored interval cache in > gl_state. Can you show the patch you used for that? From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 17:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15512003901448 (code B ref 34525); Tue, 26 Feb 2019 17:00:02 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 16:59:50 +0000 Received: from localhost ([127.0.0.1]:53267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyg58-0000NH-1U for submit@debbugs.gnu.org; Tue, 26 Feb 2019 11:59:50 -0500 Received: from colin.muc.de ([193.149.48.1]:13372 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gyg55-0000N8-GY for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 11:59:48 -0500 Received: (qmail 5447 invoked by uid 3782); 26 Feb 2019 16:59:45 -0000 Received: from acm.muc.de (p4FE15DD0.dip0.t-ipconnect.de [79.225.93.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Feb 2019 17:59:44 +0100 Received: (qmail 21745 invoked by uid 1000); 26 Feb 2019 16:55:05 -0000 Date: Tue, 26 Feb 2019 16:55:05 +0000 Message-ID: <20190226165505.GD19653@ACM> References: <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226150028.GB19653@ACM> <834l8qmudb.fsf@gnu.org> <20190226161129.GC19653@ACM> <83va16lcw3.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83va16lcw3.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Tue, Feb 26, 2019 at 18:42:36 +0200, Eli Zaretskii wrote: > > Date: Tue, 26 Feb 2019 16:11:29 +0000 > > Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > > If you implement this simpler method as an experiment, does the > > > problem go away? > > Yes! :-) > > What I actually did was at the start of update_syntax_table, always load > > the interval `i' from scratch, overwriting any stored interval cache in > > gl_state. > Can you show the patch you used for that? Sorry, I should have enclosed the patch last time round. diff --git a/src/syntax.c b/src/syntax.c index 4616ae296f..e280d6b63a 100644 --- a/src/syntax.c +++ b/src/syntax.c @@ -330,6 +330,10 @@ update_syntax_table (ptrdiff_t charpos, EMACS_INT count, bool init, bool invalidate = true; INTERVAL i; + /* TEMPORARY STUFF, 2019-02-26 */ + i = interval_of (charpos, object); + gl_state.backward_i = gl_state.forward_i = i; + /* END OF TEMPORARY STUFF */ if (init) { gl_state.old_prop = Qnil; -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 17:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15512016073316 (code B ref 34525); Tue, 26 Feb 2019 17:21:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 17:20:07 +0000 Received: from localhost ([127.0.0.1]:53277 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gygOk-0000rQ-K1 for submit@debbugs.gnu.org; Tue, 26 Feb 2019 12:20:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55462) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gygOh-0000qo-61 for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 12:20:05 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36460) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gygOY-0004PK-J4; Tue, 26 Feb 2019 12:19:56 -0500 Received: from [176.228.60.248] (port=3433 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gygOV-0004s6-5Z; Tue, 26 Feb 2019 12:19:52 -0500 Date: Tue, 26 Feb 2019 19:20:03 +0200 Message-Id: <83sgwalb5o.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190226165505.GD19653@ACM> (message from Alan Mackenzie on Tue, 26 Feb 2019 16:55:05 +0000) References: <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226150028.GB19653@ACM> <834l8qmudb.fsf@gnu.org> <20190226161129.GC19653@ACM> <83va16lcw3.fsf@gnu.org> <20190226165505.GD19653@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Tue, 26 Feb 2019 16:55:05 +0000 > Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org > From: Alan Mackenzie > > --- a/src/syntax.c > +++ b/src/syntax.c > @@ -330,6 +330,10 @@ update_syntax_table (ptrdiff_t charpos, EMACS_INT count, bool init, > bool invalidate = true; > INTERVAL i; > > + /* TEMPORARY STUFF, 2019-02-26 */ > + i = interval_of (charpos, object); > + gl_state.backward_i = gl_state.forward_i = i; > + /* END OF TEMPORARY STUFF */ > if (init) > { > gl_state.old_prop = Qnil; Does that slow down the search in any significant way? In any case, this could be doe only if the buffer has been changed since the last time the interval was cached, right? We could even get fancy and check whether the changes were before or after the cached interval. From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 17:29:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15512021214075 (code B ref 34525); Tue, 26 Feb 2019 17:29:02 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 17:28:41 +0000 Received: from localhost ([127.0.0.1]:53285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gygX2-00013e-Pb for submit@debbugs.gnu.org; Tue, 26 Feb 2019 12:28:40 -0500 Received: from colin.muc.de ([193.149.48.1]:51213 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gygX1-00013V-43 for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 12:28:40 -0500 Received: (qmail 29037 invoked by uid 3782); 26 Feb 2019 17:28:35 -0000 Received: from acm.muc.de (p4FE15DD0.dip0.t-ipconnect.de [79.225.93.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Feb 2019 18:28:34 +0100 Received: (qmail 21983 invoked by uid 1000); 26 Feb 2019 17:23:55 -0000 Date: Tue, 26 Feb 2019 17:23:55 +0000 Message-ID: <20190226172355.GE19653@ACM> References: <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226150028.GB19653@ACM> <834l8qmudb.fsf@gnu.org> <20190226161129.GC19653@ACM> <83va16lcw3.fsf@gnu.org> <20190226165505.GD19653@ACM> <83sgwalb5o.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83sgwalb5o.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli On Tue, Feb 26, 2019 at 19:20:03 +0200, Eli Zaretskii wrote: > > Date: Tue, 26 Feb 2019 16:55:05 +0000 > > Cc: daniel.lopez999@gmail.com, monnier@iro.umontreal.ca, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > --- a/src/syntax.c > > +++ b/src/syntax.c > > @@ -330,6 +330,10 @@ update_syntax_table (ptrdiff_t charpos, EMACS_INT count, bool init, > > bool invalidate = true; > > INTERVAL i; > > + /* TEMPORARY STUFF, 2019-02-26 */ > > + i = interval_of (charpos, object); > > + gl_state.backward_i = gl_state.forward_i = i; > > + /* END OF TEMPORARY STUFF */ > > if (init) > > { > > gl_state.old_prop = Qnil; > Does that slow down the search in any significant way? I think it does. Hitting the space bar between the occurrences of Bitmap in C-u M-% feels somewhat sluggish. But I'm also running on an unoptimised build, which I'm not used to. > In any case, this could be done only if the buffer has been changed > since the last time the interval was cached, right? I just tried that, and the bug symptoms reappeared again. It appears to be a bit more subtle than I thought. But I think that should be doable. > We could even get fancy and check whether the changes were before or > after the cached interval. Indeed. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 20:10:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155121180018263 (code B ref 34525); Tue, 26 Feb 2019 20:10:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 20:10:00 +0000 Received: from localhost ([127.0.0.1]:53307 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyj39-0004kV-O2 for submit@debbugs.gnu.org; Tue, 26 Feb 2019 15:10:00 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:47523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gyj36-0004kM-Qw for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 15:09:58 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1QK9s6R010922; Tue, 26 Feb 2019 15:09:54 -0500 Received: by pastel.home (Postfix, from userid 20848) id 311F669F65; Tue, 26 Feb 2019 15:09:54 -0500 (EST) From: Stefan Monnier Message-ID: References: <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> Date: Tue, 26 Feb 2019 15:09:54 -0500 In-Reply-To: <20190226135048.GA19653@ACM> (Alan Mackenzie's message of "Tue, 26 Feb 2019 13:50:48 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6491=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6491> : inlines <7024> : streams <1814185> : uri <2802718> 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 (---) > gl_state contains a cached interval, gl_state->backward_i, and there > is no guarantee that its ->position will have been updated by > adjust_intervals_for_insertion. In the current bug, I believe it > hasn't been adjusted. Hmm... gl_state is not supposed to be kept "live" across buffer modifications. It's supposed to be used only *within* read-only primitives which set it from scratch at the beginning (by calling SETUP_SYNTAX_TABLE, SETUP_BUFFER_SYNTAX_TABLE, or SETUP_SYNTAX_TABLE_FOR_OBJECT). The backward_i and forward_i fields are actually reset in the first call to update_syntax_table, by passing it a true value for the `init` arg. So the problem you describe might be due to some place where we fail to reset gl_state before using it, or maybe it's a bug in SETUP_*_SYNTAX_TABLE* Stefan From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 21:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155121779627701 (code B ref 34525); Tue, 26 Feb 2019 21:50:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 21:49:56 +0000 Received: from localhost ([127.0.0.1]:53345 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gykbs-0007Cj-0B for submit@debbugs.gnu.org; Tue, 26 Feb 2019 16:49:56 -0500 Received: from colin.muc.de ([193.149.48.1]:40321 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gykbp-0007CZ-0s for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 16:49:53 -0500 Received: (qmail 60903 invoked by uid 3782); 26 Feb 2019 21:49:49 -0000 Received: from acm.muc.de (p4FE15DD0.dip0.t-ipconnect.de [79.225.93.208]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 26 Feb 2019 22:49:48 +0100 Received: (qmail 21410 invoked by uid 1000); 26 Feb 2019 21:45:09 -0000 Date: Tue, 26 Feb 2019 21:45:09 +0000 Message-ID: <20190226214509.GF19653@ACM> References: <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Stefan. On Tue, Feb 26, 2019 at 15:09:54 -0500, Stefan Monnier wrote: > > gl_state contains a cached interval, gl_state->backward_i, and there > > is no guarantee that its ->position will have been updated by > > adjust_intervals_for_insertion. In the current bug, I believe it > > hasn't been adjusted. > Hmm... gl_state is not supposed to be kept "live" across buffer > modifications. It's supposed to be used only *within* read-only > primitives which set it from scratch at the beginning (by calling > SETUP_SYNTAX_TABLE, SETUP_BUFFER_SYNTAX_TABLE, or > SETUP_SYNTAX_TABLE_FOR_OBJECT). The backward_i and forward_i fields are > actually reset in the first call to update_syntax_table, by passing it > a true value for the `init` arg. > So the problem you describe might be due to some place where we fail to > reset gl_state before using it, or maybe it's a bug in > SETUP_*_SYNTAX_TABLE* re_search_2 calls SETUP_SYNTAX_TABLE_FOR_OBJECT unconditionally near its start. S_S_T_F_O calls update_syntax_table with a non-zero `init' conditioned only on parse_sexp_lookup_properties. This initialises gl_state.backward_i and gl_state.forward_i. So, I agree with you, what I am seeing is impossible. I'm seeing it, though. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 22:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155121900529484 (code B ref 34525); Tue, 26 Feb 2019 22:11:01 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 22:10:05 +0000 Received: from localhost ([127.0.0.1]:53354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gykvM-0007fU-OA for submit@debbugs.gnu.org; Tue, 26 Feb 2019 17:10:04 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:38935) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gykvJ-0007ez-BM for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 17:10:03 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1QM9xEk002115; Tue, 26 Feb 2019 17:09:59 -0500 Received: by pastel.home (Postfix, from userid 20848) id 15FAE69F65; Tue, 26 Feb 2019 17:09:59 -0500 (EST) From: Stefan Monnier Message-ID: References: <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190226214509.GF19653@ACM> Date: Tue, 26 Feb 2019 17:09:59 -0500 In-Reply-To: <20190226214509.GF19653@ACM> (Alan Mackenzie's message of "Tue, 26 Feb 2019 21:45:09 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6491=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6491> : inlines <7024> : streams <1814193> : uri <2802766> 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 (---) >> > gl_state contains a cached interval, gl_state->backward_i, and there >> > is no guarantee that its ->position will have been updated by >> > adjust_intervals_for_insertion. In the current bug, I believe it >> > hasn't been adjusted. > >> Hmm... gl_state is not supposed to be kept "live" across buffer >> modifications. It's supposed to be used only *within* read-only >> primitives which set it from scratch at the beginning (by calling >> SETUP_SYNTAX_TABLE, SETUP_BUFFER_SYNTAX_TABLE, or >> SETUP_SYNTAX_TABLE_FOR_OBJECT). The backward_i and forward_i fields are >> actually reset in the first call to update_syntax_table, by passing it >> a true value for the `init` arg. > >> So the problem you describe might be due to some place where we fail to >> reset gl_state before using it, or maybe it's a bug in >> SETUP_*_SYNTAX_TABLE* > > re_search_2 calls SETUP_SYNTAX_TABLE_FOR_OBJECT unconditionally near its > start. S_S_T_F_O calls update_syntax_table with a non-zero `init' > conditioned only on parse_sexp_lookup_properties. This initialises > gl_state.backward_i and gl_state.forward_i. > > So, I agree with you, what I am seeing is impossible. I'm seeing it, > though. Any chance the buffer is modified from within the regexp operation? Or maybe some async thread? This said, the more common problem is that UPDATE_SYNTAX_TABLE was not called, or not for the right position, or UPDATE_SYNTAX_TABLE_FORWARD was called when we actually moved (ever so slightly) backward or vice-versa. Stefan From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Tue, 26 Feb 2019 23:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15512220642020 (code B ref 34525); Tue, 26 Feb 2019 23:02:02 +0000 Received: (at 34525) by debbugs.gnu.org; 26 Feb 2019 23:01:04 +0000 Received: from localhost ([127.0.0.1]:53378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gylii-0000WV-DR for submit@debbugs.gnu.org; Tue, 26 Feb 2019 18:01:04 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:53952) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gylif-0000Vs-G1 for 34525@debbugs.gnu.org; Tue, 26 Feb 2019 18:01:03 -0500 Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1QN0xTa019866; Tue, 26 Feb 2019 18:01:00 -0500 Received: by pastel.home (Postfix, from userid 20848) id 90ED069F65; Tue, 26 Feb 2019 18:00:59 -0500 (EST) From: Stefan Monnier Message-ID: References: <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> Date: Tue, 26 Feb 2019 18:00:59 -0500 In-Reply-To: <20190226135048.GA19653@ACM> (Alan Mackenzie's message of "Tue, 26 Feb 2019 13:50:48 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6491=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6491> : inlines <7024> : streams <1814196> : uri <2802783> 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 (---) > After this buffer change, adjust_intervals_for_insertion gets called. > This adds 6 onto the ->position field of each interval "adjusting all of > its ancestors by adding LENGTH to them", according to the comment at the > head of adjust_intervals_for_insertion. > > Note this only adjusts the ancestors of that interval early in the .h > file, not all intervals in the tree. Maybe the problem comes from here. The lazy adjustment of ->position may be too lazy here. This is a fairly delicate/brittle part of intervals.c > I'm reasonably sure this is what's happening: > adjust_intervals_for_insertion is failing to adjust the cached intervals > in gl_state. It's a nasty cache invalidation problem. As mentioned earlier, I think gl_state should be sufficiently transient that this scenario can't happen. Elsewhere you send a sample patch and Eli asks "Does that slow down the search in any significant way?". The answer should be "yes!" because this patch pretty much defeats the purpose of the gl_state cache, recomputing the current interval (O(logN)) every time we move from one character to the next. Maybe another way to catch the problem is: at the end of upate_syntax_table, call `interval_of (charpos, object)` and verify that the returned interval is the same as the one we had selected, plus verify that the call to `interval_of` has not modified the value of ->position. Stefan From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 14:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155127766429171 (code B ref 34525); Wed, 27 Feb 2019 14:28:01 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 14:27:44 +0000 Received: from localhost ([127.0.0.1]:53612 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz0BU-0007aR-0X for submit@debbugs.gnu.org; Wed, 27 Feb 2019 09:27:44 -0500 Received: from colin.muc.de ([193.149.48.1]:46655 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gz0BR-0007aH-FA for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 09:27:42 -0500 Received: (qmail 86993 invoked by uid 3782); 27 Feb 2019 14:27:39 -0000 Received: from acm.muc.de (p4FE15D59.dip0.t-ipconnect.de [79.225.93.89]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 27 Feb 2019 15:27:37 +0100 Received: (qmail 4958 invoked by uid 1000); 27 Feb 2019 14:22:51 -0000 Date: Wed, 27 Feb 2019 14:22:51 +0000 Message-ID: <20190227142251.GB4772@ACM> References: <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Stefan. On Tue, Feb 26, 2019 at 15:09:54 -0500, Stefan Monnier wrote: > > gl_state contains a cached interval, gl_state->backward_i, and there > > is no guarantee that its ->position will have been updated by > > adjust_intervals_for_insertion. In the current bug, I believe it > > hasn't been adjusted. > Hmm... gl_state is not supposed to be kept "live" across buffer > modifications. It's supposed to be used only *within* read-only > primitives which set it from scratch at the beginning (by calling > SETUP_SYNTAX_TABLE, SETUP_BUFFER_SYNTAX_TABLE, or > SETUP_SYNTAX_TABLE_FOR_OBJECT). The backward_i and forward_i fields are > actually reset in the first call to update_syntax_table, by passing it > a true value for the `init` arg. > So the problem you describe might be due to some place where we fail to > reset gl_state before using it, or maybe it's a bug in > SETUP_*_SYNTAX_TABLE* I see another potential problem, and I'd like your view on it, please. Namely, in next_interval, we have if (! NULL_RIGHT_CHILD (i)) { i = i->right; while (! NULL_LEFT_CHILD (i)) i = i->left; <=============== i->position = next_position; return i; } Here, in seeking the next interval, we go down a chain of `left's. We do not set the ->position field of these intervals, except for the last one, which we return. So the returned interval doesn't satisfy the condition that all its parents have their ->position's set correctly. Thus if we use this interval as an argument to update_interval, we will likely fail. I think this can happen in update_syntax_table. There is an analogous situation in previous_interval. I might try adding code to this to set these ->position's. Trouble is, it might slow things down quite a bit. > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 15:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15512804241282 (code B ref 34525); Wed, 27 Feb 2019 15:14:02 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 15:13:44 +0000 Received: from localhost ([127.0.0.1]:54152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz0u0-0000Kb-Ea for submit@debbugs.gnu.org; Wed, 27 Feb 2019 10:13:44 -0500 Received: from colin.muc.de ([193.149.48.1]:32313 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gz0ty-0000KT-7N for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 10:13:43 -0500 Received: (qmail 1266 invoked by uid 3782); 27 Feb 2019 15:13:37 -0000 Received: from acm.muc.de (p4FE15D59.dip0.t-ipconnect.de [79.225.93.89]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 27 Feb 2019 16:13:35 +0100 Received: (qmail 12367 invoked by uid 1000); 27 Feb 2019 15:08:49 -0000 Date: Wed, 27 Feb 2019 15:08:49 +0000 Message-ID: <20190227150849.GC4772@ACM> References: <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190227142251.GB4772@ACM> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello again, Stefan. On Wed, Feb 27, 2019 at 14:22:51 +0000, Alan Mackenzie wrote: > On Tue, Feb 26, 2019 at 15:09:54 -0500, Stefan Monnier wrote: > > > gl_state contains a cached interval, gl_state->backward_i, and there > > > is no guarantee that its ->position will have been updated by > > > adjust_intervals_for_insertion. In the current bug, I believe it > > > hasn't been adjusted. > > Hmm... gl_state is not supposed to be kept "live" across buffer > > modifications. It's supposed to be used only *within* read-only > > primitives which set it from scratch at the beginning (by calling > > SETUP_SYNTAX_TABLE, SETUP_BUFFER_SYNTAX_TABLE, or > > SETUP_SYNTAX_TABLE_FOR_OBJECT). The backward_i and forward_i fields are > > actually reset in the first call to update_syntax_table, by passing it > > a true value for the `init` arg. > > So the problem you describe might be due to some place where we fail to > > reset gl_state before using it, or maybe it's a bug in > > SETUP_*_SYNTAX_TABLE* > I see another potential problem, and I'd like your view on it, please. > Namely, in next_interval, we have > if (! NULL_RIGHT_CHILD (i)) > { > i = i->right; > while (! NULL_LEFT_CHILD (i)) > i = i->left; <=============== > i->position = next_position; > return i; > } > Here, in seeking the next interval, we go down a chain of `left's. We > do not set the ->position field of these intervals, except for the last > one, which we return. > So the returned interval doesn't satisfy the condition that all its > parents have their ->position's set correctly. Thus if we use this > interval as an argument to update_interval, we will likely fail. I > think this can happen in update_syntax_table. > There is an analogous situation in previous_interval. > I might try adding code to this to set these ->position's. Trouble is, > it might slow things down quite a bit. I've done this, and it appears to have fixed the bug. :-) As for the slowdown, I haven't timed it, yet. Here is the diff of the current state of my changes: diff --git a/src/intervals.c b/src/intervals.c index 524bb944e5..d37ca64bd0 100644 --- a/src/intervals.c +++ b/src/intervals.c @@ -654,7 +654,14 @@ next_interval (register INTERVAL interval) { i = i->right; while (! NULL_LEFT_CHILD (i)) - i = i->left; + /* OLD STOUGH, 2019-02-27 */ + /* i = i->left; */ + /* NEW STOUGH, 2019-02-27 */ + { + i->position = next_position + LEFT_TOTAL_LENGTH (i); + i = i->left; + } + /* END OF NEW STOUGH */ i->position = next_position; return i; @@ -691,7 +698,15 @@ previous_interval (register INTERVAL interval) { i = interval->left; while (! NULL_RIGHT_CHILD (i)) - i = i->right; + /* OLD STOUGH, 2019-02-27 */ + /* i = i->right; */ + /* NEW STOUGH, 2019-02-27 */ + { + i->position = interval->position - TOTAL_LENGTH (i) + + LEFT_TOTAL_LENGTH(i); + i = i->right; + } + /* END OF NEW STOUGH */ i->position = interval->position - LENGTH (i); return i; > > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 15:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15512820244062 (code B ref 34525); Wed, 27 Feb 2019 15:41:02 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 15:40:24 +0000 Received: from localhost ([127.0.0.1]:54162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz1Jn-00013S-L5 for submit@debbugs.gnu.org; Wed, 27 Feb 2019 10:40:23 -0500 Received: from pruche.dit.umontreal.ca ([132.204.246.22]:53691) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz1Jk-00013I-Rc for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 10:40:22 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1RFeJ7M020206; Wed, 27 Feb 2019 10:40:19 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 41BD4AE0E9; Wed, 27 Feb 2019 10:40:19 -0500 (EST) From: Stefan Monnier Message-ID: References: <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <20190227150849.GC4772@ACM> Date: Wed, 27 Feb 2019 10:40:19 -0500 In-Reply-To: <20190227150849.GC4772@ACM> (Alan Mackenzie's message of "Wed, 27 Feb 2019 15:08:49 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6492=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7024> : streams <1814262> : uri <2803133> 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 (---) >> Here, in seeking the next interval, we go down a chain of `left's. We >> do not set the ->position field of these intervals, except for the last >> one, which we return. >> So the returned interval doesn't satisfy the condition that all its >> parents have their ->position's set correctly. [...] > I've done this, and it appears to have fixed the bug. :-) AFAICT the only place where we need the parents to have a valid ->position is in update_interval. So maybe another fix is to change update_interval so it computes the parent's ->position rather than rely on it having the right value. I personally don't have a preference and I'm not sure which option would be better performancewise. If we opt (like your patch does) to have the invariant that the ->position of parents is kept up-to-date, then maybe we should change find_interval to guarantee this (which would basically be a matter of moving the corresponding code from update_syntax_table where we update the parents's ->position after calling find_interval) ? Stefan From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 16:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@IRO.UMontreal.CA, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155128556817421 (code B ref 34525); Wed, 27 Feb 2019 16:40:01 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 16:39:28 +0000 Received: from localhost ([127.0.0.1]:54235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz2Ev-0004Ws-8h for submit@debbugs.gnu.org; Wed, 27 Feb 2019 11:39:27 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55201) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz2Es-0004Wg-IS for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 11:39:23 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:52054) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gz2Em-0005zL-GF; Wed, 27 Feb 2019 11:39:16 -0500 Received: from [176.228.60.248] (port=2799 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gz2Em-0004ms-3V; Wed, 27 Feb 2019 11:39:16 -0500 Date: Wed, 27 Feb 2019 18:39:31 +0200 Message-Id: <838sy1kwxo.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190227142251.GB4772@ACM> (message from Alan Mackenzie on Wed, 27 Feb 2019 14:22:51 +0000) References: <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Wed, 27 Feb 2019 14:22:51 +0000 > Cc: Eli Zaretskii , daniel.lopez999@gmail.com, > 34525@debbugs.gnu.org > From: Alan Mackenzie > > if (! NULL_RIGHT_CHILD (i)) > { > i = i->right; > while (! NULL_LEFT_CHILD (i)) > i = i->left; <=============== > > i->position = next_position; > return i; > } > > Here, in seeking the next interval, we go down a chain of `left's. We > do not set the ->position field of these intervals, except for the last > one, which we return. The position field is just a cache, isn't it? > So the returned interval doesn't satisfy the condition that all its > parents have their ->position's set correctly. Thus if we use this > interval as an argument to update_interval, we will likely fail. I > think this can happen in update_syntax_table. next_interval and previous_interval are used extensively, so I'm having hard time believing that they have such a blatant bug. From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 17:16:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Stefan Monnier Cc: Eli Zaretskii , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155128773520941 (code B ref 34525); Wed, 27 Feb 2019 17:16:01 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 17:15:35 +0000 Received: from localhost ([127.0.0.1]:54276 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz2nu-0005Rg-Ow for submit@debbugs.gnu.org; Wed, 27 Feb 2019 12:15:35 -0500 Received: from colin.muc.de ([193.149.48.1]:12230 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gz2ns-0005RX-1D for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 12:15:32 -0500 Received: (qmail 53198 invoked by uid 3782); 27 Feb 2019 17:15:25 -0000 Received: from acm.muc.de (p4FE15D59.dip0.t-ipconnect.de [79.225.93.89]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 27 Feb 2019 18:15:22 +0100 Received: (qmail 23546 invoked by uid 1000); 27 Feb 2019 17:10:36 -0000 Date: Wed, 27 Feb 2019 17:10:36 +0000 Message-ID: <20190227171036.GF4772@ACM> References: <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <20190227150849.GC4772@ACM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Stefan. On Wed, Feb 27, 2019 at 10:40:19 -0500, Stefan Monnier wrote: > >> Here, in seeking the next interval, we go down a chain of `left's. We > >> do not set the ->position field of these intervals, except for the last > >> one, which we return. > >> So the returned interval doesn't satisfy the condition that all its > >> parents have their ->position's set correctly. > [...] > > I've done this, and it appears to have fixed the bug. :-) > AFAICT the only place where we need the parents to have > a valid ->position is in update_interval. So maybe another fix is to > change update_interval so it computes the parent's ->position rather > than rely on it having the right value. I'll think about this. > I personally don't have a preference and I'm not sure which option would > be better performancewise. I've done some speed testing with my function M-: (time-scroll), which scrolls through a buffer a screenful at a time, redisplaying each place it stops. On xdisp.c, there was no detectable difference between versions with the bug fix and without. On a largish C++ file with lots of template delimiters, the corrected version was about 4% slower on unoptimised builds. Between comparable optimised builds, the differences were not detectable. > If we opt (like your patch does) to have the invariant that > the ->position of parents is kept up-to-date, then maybe we should > change find_interval to guarantee this (which would basically be > a matter of moving the corresponding code from update_syntax_table where > we update the parents's ->position after calling find_interval) ? This would be an excellent idea, something I was going to suggest myself. :-) > Stefan -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 17:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@IRO.UMontreal.CA, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155128899122875 (code B ref 34525); Wed, 27 Feb 2019 17:37:02 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 17:36:31 +0000 Received: from localhost ([127.0.0.1]:54297 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz38B-0005wt-GS for submit@debbugs.gnu.org; Wed, 27 Feb 2019 12:36:31 -0500 Received: from colin.muc.de ([193.149.48.1]:28584 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gz386-0005wi-KL for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 12:36:27 -0500 Received: (qmail 60862 invoked by uid 3782); 27 Feb 2019 17:36:21 -0000 Received: from acm.muc.de (p4FE15D59.dip0.t-ipconnect.de [79.225.93.89]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 27 Feb 2019 18:36:19 +0100 Received: (qmail 23670 invoked by uid 1000); 27 Feb 2019 17:31:32 -0000 Date: Wed, 27 Feb 2019 17:31:32 +0000 Message-ID: <20190227173132.GG4772@ACM> References: <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <838sy1kwxo.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Wed, Feb 27, 2019 at 18:39:31 +0200, Eli Zaretskii wrote: > > Date: Wed, 27 Feb 2019 14:22:51 +0000 > > Cc: Eli Zaretskii , daniel.lopez999@gmail.com, > > 34525@debbugs.gnu.org > > From: Alan Mackenzie > > if (! NULL_RIGHT_CHILD (i)) > > { > > i = i->right; > > while (! NULL_LEFT_CHILD (i)) > > i = i->left; <=============== > > i->position = next_position; > > return i; > > } > > Here, in seeking the next interval, we go down a chain of `left's. We > > do not set the ->position field of these intervals, except for the last > > one, which we return. > The position field is just a cache, isn't it? It's a cache, yes. But it's used in update_interval, for example. It would appear bad things were happening because it wasn't being kept up to date. > > So the returned interval doesn't satisfy the condition that all its > > parents have their ->position's set correctly. Thus if we use this > > interval as an argument to update_interval, we will likely fail. I > > think this can happen in update_syntax_table. > next_interval and previous_interval are used extensively, so I'm > having hard time believing that they have such a blatant bug. Yes, how come we haven't seen many more consequences? Maybe syntax-table text properties aren't as widely used as all that. Also, the effect would have to be seen within the time between successive calls to SETUP_SYNTAX_TABLE and friends, since each such call reinitialises this cache, in an important sense. And we only saw the effect when the replacement text "SharedBitmap" was exactly twice the length of the original word "Bitmap". Anyhow, fixing this item appears to fix the bug (see the tentative patch in my post from 15:08:49 +0000 to Stefan). I'm guessing this fix will be deemed too unsafe to make it into the emacs-26 release branch. ;-( -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Alan Mackenzie , daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155128926923293 (code B ref 34525); Wed, 27 Feb 2019 17:42:02 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 17:41:09 +0000 Received: from localhost ([127.0.0.1]:54301 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz3Cf-00063b-6f for submit@debbugs.gnu.org; Wed, 27 Feb 2019 12:41:09 -0500 Received: from chene.dit.umontreal.ca ([132.204.246.20]:49163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz3Cd-00063T-5I for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 12:41:08 -0500 Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x1RHf5ip009282; Wed, 27 Feb 2019 12:41:05 -0500 Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id D4E1EAE0E9; Wed, 27 Feb 2019 12:41:04 -0500 (EST) From: Stefan Monnier Message-ID: References: <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> Date: Wed, 27 Feb 2019 12:41:04 -0500 In-Reply-To: <838sy1kwxo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 27 Feb 2019 18:39:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6492=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6492> : inlines <7025> : streams <1814271> : uri <2803186> 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 (---) > next_interval and previous_interval are used extensively, so I'm > having hard time believing that they have such a blatant bug. I'm also wondering why this hasn't bitten us long ago, but the behavior in the original bug-report is definitely weird. E.g. I reproduced the bug using the lower-level (while (re-search-forward RE) (replace-match)), and then added (how-many RE) calls before re-search-forward and before replace-match: these should always differ by 1 (since one occurrence of RE was skipped by re-search-forward), but they often didn't (even though there was no buffer modifications between the two how-many calls). AFAICT the only place where the missing updates can bite us is when we call update_interval, since it seems to be the only function that relies on all parents having the ->position field correctly set. update_interval is only called from update_syntax_table. I'm actually wondering whether we should keep update_interval at all: AFAICT update_syntax_table is almost always called "sequentially". I.e. the new `charpos` is right next to the old one. So a while loop with next_interval/previous_interval should be just as efficient in practice: a loop of next_interval/previous_interval has basically a complexity O(n) where `n` is the distance we move, whereas update_interval has complexity O(log n), so if `n` is almost always 1 the difference doesn't matter. Stefan From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 18:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@IRO.UMontreal.CA, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155129086525756 (code B ref 34525); Wed, 27 Feb 2019 18:08:01 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 18:07:45 +0000 Received: from localhost ([127.0.0.1]:54315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz3cO-0006hM-Ql for submit@debbugs.gnu.org; Wed, 27 Feb 2019 13:07:45 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49304) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz3cM-0006h2-DO for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 13:07:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gz3cG-0006g6-RV; Wed, 27 Feb 2019 13:07:36 -0500 Received: from [176.228.60.248] (port=4321 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gz3cE-0001L5-My; Wed, 27 Feb 2019 13:07:36 -0500 Date: Wed, 27 Feb 2019 20:07:50 +0200 Message-Id: <83zhqhjea1.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190227173132.GG4772@ACM> (message from Alan Mackenzie on Wed, 27 Feb 2019 17:31:32 +0000) References: <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> <20190227173132.GG4772@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Wed, 27 Feb 2019 17:31:32 +0000 > Cc: monnier@IRO.UMontreal.CA, daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > From: Alan Mackenzie > > > next_interval and previous_interval are used extensively, so I'm > > having hard time believing that they have such a blatant bug. > > Yes, how come we haven't seen many more consequences? > > Maybe syntax-table text properties aren't as widely used as all that. I actually had the text properties in mind. They are used all over the place. Faces are a feature that would make any such bugs immediately visible. > I'm guessing this fix will be deemed too unsafe to make it into the > emacs-26 release branch. ;-( That goes without saying. From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 18:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Stefan Monnier Cc: acm@muc.de, daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155129329829539 (code B ref 34525); Wed, 27 Feb 2019 18:49:02 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 18:48:18 +0000 Received: from localhost ([127.0.0.1]:54338 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz4Fe-0007gN-CP for submit@debbugs.gnu.org; Wed, 27 Feb 2019 13:48:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz4Fb-0007g8-TB for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 13:48:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53713) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gz4FU-0005YA-QV; Wed, 27 Feb 2019 13:48:08 -0500 Received: from [176.228.60.248] (port=2920 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gz4FU-0000wt-BV; Wed, 27 Feb 2019 13:48:08 -0500 Date: Wed, 27 Feb 2019 20:48:05 +0200 Message-Id: <83tvgpjcey.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Stefan Monnier on Wed, 27 Feb 2019 12:41:04 -0500) References: <20190220185850.GB9655@ACM> <83lg2agt0j.fsf@gnu.org> <20190220213003.GC9655@ACM> <83bm35hkqo.fsf@gnu.org> <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > From: Stefan Monnier > Cc: Alan Mackenzie , daniel.lopez999@gmail.com, > 34525@debbugs.gnu.org > Date: Wed, 27 Feb 2019 12:41:04 -0500 > > AFAICT the only place where the missing updates can bite us is when we > call update_interval, since it seems to be the only function that relies > on all parents having the ->position field correctly set. > > update_interval is only called from update_syntax_table. That I could understand. But then the fix should be in that one function (if we keep it). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Wed, 27 Feb 2019 20:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, Stefan Monnier , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155130049717355 (code B ref 34525); Wed, 27 Feb 2019 20:49:02 +0000 Received: (at 34525) by debbugs.gnu.org; 27 Feb 2019 20:48:17 +0000 Received: from localhost ([127.0.0.1]:54407 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gz67k-0004Vr-Sn for submit@debbugs.gnu.org; Wed, 27 Feb 2019 15:48:17 -0500 Received: from colin.muc.de ([193.149.48.1]:34558 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gz67i-0004Vh-RV for 34525@debbugs.gnu.org; Wed, 27 Feb 2019 15:48:15 -0500 Received: (qmail 86182 invoked by uid 3782); 27 Feb 2019 20:48:09 -0000 Received: from acm.muc.de (p4FE15D59.dip0.t-ipconnect.de [79.225.93.89]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 27 Feb 2019 21:48:08 +0100 Received: (qmail 24632 invoked by uid 1000); 27 Feb 2019 20:43:21 -0000 Date: Wed, 27 Feb 2019 20:43:21 +0000 Message-ID: <20190227204321.GH4772@ACM> References: <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> <83tvgpjcey.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83tvgpjcey.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Wed, Feb 27, 2019 at 20:48:05 +0200, Eli Zaretskii wrote: > > From: Stefan Monnier > > Cc: Alan Mackenzie , daniel.lopez999@gmail.com, > > 34525@debbugs.gnu.org > > Date: Wed, 27 Feb 2019 12:41:04 -0500 > > AFAICT the only place where the missing updates can bite us is when we > > call update_interval, since it seems to be the only function that relies > > on all parents having the ->position field correctly set. > > update_interval is only called from update_syntax_table. > That I could understand. But then the fix should be in that one > function (if we keep it). It would be easy enough to set the ->position of a node when moving to it from a child in update_literal. This would be an alternative to the changes I've suggested in next_interval and previous_interval. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 28 Feb 2019 10:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii , Stefan Monnier Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155135132415882 (code B ref 34525); Thu, 28 Feb 2019 10:56:02 +0000 Received: (at 34525) by debbugs.gnu.org; 28 Feb 2019 10:55:24 +0000 Received: from localhost ([127.0.0.1]:54814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzJLY-000486-Fo for submit@debbugs.gnu.org; Thu, 28 Feb 2019 05:55:24 -0500 Received: from colin.muc.de ([193.149.48.1]:20914 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gzJLW-00047w-3H for 34525@debbugs.gnu.org; Thu, 28 Feb 2019 05:55:22 -0500 Received: (qmail 36102 invoked by uid 3782); 28 Feb 2019 10:55:20 -0000 Received: from acm.muc.de (p4FE15DA7.dip0.t-ipconnect.de [79.225.93.167]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 28 Feb 2019 11:55:18 +0100 Received: (qmail 9664 invoked by uid 1000); 28 Feb 2019 10:50:25 -0000 Date: Thu, 28 Feb 2019 10:50:25 +0000 Message-ID: <20190228105025.GB4686@ACM> References: <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> <20190227173132.GG4772@ACM> <83zhqhjea1.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83zhqhjea1.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli and Stefan. On Wed, Feb 27, 2019 at 20:07:50 +0200, Eli Zaretskii wrote: > > Date: Wed, 27 Feb 2019 17:31:32 +0000 > > Cc: monnier@IRO.UMontreal.CA, daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > > next_interval and previous_interval are used extensively, so I'm > > > having hard time believing that they have such a blatant bug. > > Yes, how come we haven't seen many more consequences? > > Maybe syntax-table text properties aren't as widely used as all that. > I actually had the text properties in mind. They are used all over > the place. Faces are a feature that would make any such bugs > immediately visible. I think the mechanism with update_interval is only used in syntax.c, and only for the syntax-table property. > > I'm guessing this fix will be deemed too unsafe to make it into the > > emacs-26 release branch. ;-( > That goes without saying. OK. Progress on the bug seems to have stalled somewhat. Now that we understand the cause, one of us needs to decide how to fix it. I think we've discussed the following alternatives: (i) Calculate ->position's in previous_interval and next_interval, as my tentative patch already does. (ii) Calculate the ->position's in update_interval, on moving to parents. (iii) Do away with update_interval, replacing it in syntax.c with previous/next_interval in while loops. At the moment, only (i) has been tried. Speed-wise, it seems not to make any difference in an optimised GNU build, though it did appear to be significantly (~4%) slower on an unoptimised build which scrolls through a C++ file with lots of templates. I don't think it's worth the effort to make a systematic speed comparison between the alternatives. (iv) Additionally, there is a cleanup wanted, where setting ->position in the chain of parents should be moved from update_syntax_table to find_interval. In (i), the convention for ->position would be that it is valid for the target interval together with all its parents. In (ii) and (iii), it would only be valid in the final target intervals found by navigation. I think this should be explicitly stated in a comment in struct interval. So, where do we go from here? If it were up to me, I would probably chose (i), simply because it's already been done, but I've no strong feelings over it. I'm also willing to implement (ii), or even (iii), if that is wanted. In any case, I would ask one of you for a careful code review of my changes - this stuff is easy to get wrong. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 28 Feb 2019 17:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: daniel.lopez999@gmail.com, monnier@IRO.UMontreal.CA, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15513757136447 (code B ref 34525); Thu, 28 Feb 2019 17:42:02 +0000 Received: (at 34525) by debbugs.gnu.org; 28 Feb 2019 17:41:53 +0000 Received: from localhost ([127.0.0.1]:55448 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzPgv-0001fu-4d for submit@debbugs.gnu.org; Thu, 28 Feb 2019 12:41:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzPgs-0001fi-LE for 34525@debbugs.gnu.org; Thu, 28 Feb 2019 12:41:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43358) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gzPgl-0007gH-KN; Thu, 28 Feb 2019 12:41:43 -0500 Received: from [176.228.60.248] (port=3697 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gzPgk-0007Xu-IF; Thu, 28 Feb 2019 12:41:43 -0500 Date: Thu, 28 Feb 2019 19:41:12 +0200 Message-Id: <83k1hjkdzb.fsf@gnu.org> From: Eli Zaretskii In-reply-to: <20190228105025.GB4686@ACM> (message from Alan Mackenzie on Thu, 28 Feb 2019 10:50:25 +0000) References: <20190224173746.GA21808@ACM> <83mumlnk8y.fsf@gnu.org> <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> <20190227173132.GG4772@ACM> <83zhqhjea1.fsf@gnu.org> <20190228105025.GB4686@ACM> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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 (-) > Date: Thu, 28 Feb 2019 10:50:25 +0000 > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > From: Alan Mackenzie > > (i) Calculate ->position's in previous_interval and next_interval, as my > tentative patch already does. > (ii) Calculate the ->position's in update_interval, on moving to > parents. > (iii) Do away with update_interval, replacing it in syntax.c with > previous/next_interval in while loops. > > At the moment, only (i) has been tried. > > Speed-wise, it seems not to make any difference in an optimised GNU > build, though it did appear to be significantly (~4%) slower on an > unoptimised build which scrolls through a C++ file with lots of > templates. I don't think it's worth the effort to make a systematic > speed comparison between the alternatives. > > (iv) Additionally, there is a cleanup wanted, where setting ->position > in the chain of parents should be moved from update_syntax_table to > find_interval. > > In (i), the convention for ->position would be that it is valid for the > target interval together with all its parents. In (ii) and (iii), it > would only be valid in the final target intervals found by navigation. > I think this should be explicitly stated in a comment in struct > interval. > > So, where do we go from here? If it were up to me, I would probably > chose (i), simply because it's already been done, but I've no strong > feelings over it. I prefer not to do (i) because it has much wider implications than needed. Either (ii) or (iii) are okay with me. The former seems to be simpler, so I tend to favor it slightly. From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Thu, 28 Feb 2019 22:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Eli Zaretskii Cc: daniel.lopez999@gmail.com, monnier@IRO.UMontreal.CA, 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15513911576515 (code B ref 34525); Thu, 28 Feb 2019 22:00:02 +0000 Received: (at 34525) by debbugs.gnu.org; 28 Feb 2019 21:59:17 +0000 Received: from localhost ([127.0.0.1]:55605 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzTi1-0001h1-6E for submit@debbugs.gnu.org; Thu, 28 Feb 2019 16:59:17 -0500 Received: from colin.muc.de ([193.149.48.1]:61836 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gzThy-0001gr-K6 for 34525@debbugs.gnu.org; Thu, 28 Feb 2019 16:59:15 -0500 Received: (qmail 4624 invoked by uid 3782); 28 Feb 2019 21:59:11 -0000 Received: from acm.muc.de (p4FE15DA7.dip0.t-ipconnect.de [79.225.93.167]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 28 Feb 2019 22:59:09 +0100 Received: (qmail 32670 invoked by uid 1000); 28 Feb 2019 21:54:14 -0000 Date: Thu, 28 Feb 2019 21:54:14 +0000 Message-ID: <20190228215414.GE4686@ACM> References: <20190224210058.GB21808@ACM> <83mumjmxv6.fsf@gnu.org> <20190226135048.GA19653@ACM> <20190227142251.GB4772@ACM> <838sy1kwxo.fsf@gnu.org> <20190227173132.GG4772@ACM> <83zhqhjea1.fsf@gnu.org> <20190228105025.GB4686@ACM> <83k1hjkdzb.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83k1hjkdzb.fsf@gnu.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Eli. On Thu, Feb 28, 2019 at 19:41:12 +0200, Eli Zaretskii wrote: > > Date: Thu, 28 Feb 2019 10:50:25 +0000 > > Cc: daniel.lopez999@gmail.com, 34525@debbugs.gnu.org > > From: Alan Mackenzie > > (i) Calculate ->position's in previous_interval and next_interval, as my > > tentative patch already does. > > (ii) Calculate the ->position's in update_interval, on moving to > > parents. > > (iii) Do away with update_interval, replacing it in syntax.c with > > previous/next_interval in while loops. > > In (i), the convention for ->position would be that it is valid for the > > target interval together with all its parents. In (ii) and (iii), it > > would only be valid in the final target intervals found by navigation. > > I think this should be explicitly stated in a comment in struct > > interval. Done. > > So, where do we go from here? If it were up to me, I would probably > > chose (i), simply because it's already been done, but I've no strong > > feelings over it. > I prefer not to do (i) because it has much wider implications than > needed. Either (ii) or (iii) are okay with me. The former seems to > be simpler, so I tend to favor it slightly. OK, I enclose a patch which codes up (ii). As a matter of interest, it seems to run a little faster on my benchmark of scrolling through xdisp.c than the version without the fix. And it fixes the OP's bug. :-) diff --git a/src/intervals.c b/src/intervals.c index 524bb944e5..2ed913d5fb 100644 --- a/src/intervals.c +++ b/src/intervals.c @@ -713,11 +713,21 @@ previous_interval (register INTERVAL interval) return NULL; } -/* Find the interval containing POS given some non-NULL INTERVAL - in the same tree. Note that we need to update interval->position - if we go down the tree. - To speed up the process, we assume that the ->position of - I and all its parents is already uptodate. */ +/* Set the ->position field of I's parent, based on I->position. */ +#define SET_PARENT_POSITION(i) \ + if (AM_LEFT_CHILD (i)) \ + INTERVAL_PARENT (i)->position = \ + i->position + TOTAL_LENGTH (i) - LEFT_TOTAL_LENGTH (i); \ + else \ + INTERVAL_PARENT (i)->position = \ + i->position - LEFT_TOTAL_LENGTH (i) \ + - LENGTH (INTERVAL_PARENT (i)) + +/* Find the interval containing POS given some non-NULL INTERVAL in + the same tree. Note that we update interval->position in each + interval we traverse, assuming it is already correctly set for the + argument I. We don't assume that any other interval already has a + correctly set ->position. */ INTERVAL update_interval (register INTERVAL i, ptrdiff_t pos) { @@ -738,7 +748,10 @@ update_interval (register INTERVAL i, ptrdiff_t pos) else if (NULL_PARENT (i)) error ("Point before start of properties"); else - i = INTERVAL_PARENT (i); + { + SET_PARENT_POSITION (i); + i = INTERVAL_PARENT (i); + } continue; } else if (pos >= INTERVAL_LAST_POS (i)) @@ -753,7 +766,10 @@ update_interval (register INTERVAL i, ptrdiff_t pos) else if (NULL_PARENT (i)) error ("Point %"pD"d after end of properties", pos); else - i = INTERVAL_PARENT (i); + { + SET_PARENT_POSITION (i); + i = INTERVAL_PARENT (i); + } continue; } else diff --git a/src/intervals.h b/src/intervals.h index 9c5adf33a1..7608800116 100644 --- a/src/intervals.h +++ b/src/intervals.h @@ -31,11 +31,15 @@ struct interval /* The first group of entries deal with the tree structure. */ ptrdiff_t total_length; /* Length of myself and both children. */ ptrdiff_t position; /* Cache of interval's character position. */ - /* This field is usually updated - simultaneously with an interval - traversal, there is no guarantee - that it is valid for a random - interval. */ + /* This field is valid for the final + target interval returned by + find_interval, next_interval, + previous_interval and + update_interval. It cannot be + depended upon for any intermediate + intevals traversed by these + functions, or any other + interval. */ struct interval *left; /* Intervals which precede me. */ struct interval *right; /* Intervals which succeed me. */ diff --git a/src/pdumper.c b/src/pdumper.c index f9638d4357..3aea4ab0d6 100644 --- a/src/pdumper.c +++ b/src/pdumper.c @@ -2065,7 +2065,7 @@ dump_interval_tree (struct dump_context *ctx, INTERVAL tree, dump_off parent_offset) { -#if CHECK_STRUCTS && !defined (HASH_interval_9110163DA0) +#if CHECK_STRUCTS && !defined (HASH_interval_70865541E2) # error "interval changed. See CHECK_STRUCTS comment." #endif // TODO: output tree breadth-first? diff --git a/src/syntax.c b/src/syntax.c index 4616ae296f..faea1432cb 100644 --- a/src/syntax.c +++ b/src/syntax.c @@ -340,20 +340,6 @@ update_syntax_table (ptrdiff_t charpos, EMACS_INT count, bool init, invalidate = false; if (!i) return; - /* interval_of updates only ->position of the return value, so - update the parents manually to speed up update_interval. */ - while (!NULL_PARENT (i)) - { - if (AM_RIGHT_CHILD (i)) - INTERVAL_PARENT (i)->position = i->position - - LEFT_TOTAL_LENGTH (i) + TOTAL_LENGTH (i) /* right end */ - - TOTAL_LENGTH (INTERVAL_PARENT (i)) - + LEFT_TOTAL_LENGTH (INTERVAL_PARENT (i)); - else - INTERVAL_PARENT (i)->position = i->position - LEFT_TOTAL_LENGTH (i) - + TOTAL_LENGTH (i); - i = INTERVAL_PARENT (i); - } i = gl_state.forward_i; gl_state.b_property = i->position - gl_state.offset; gl_state.e_property = INTERVAL_LAST_POS (i) - gl_state.offset; I've just noticed a typo in one of the comments in intervals.h, so the above can't be final. Sorry. -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 01 Mar 2019 14:40:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Daniel Lopez Cc: Eli Zaretskii , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.155145116018918 (code B ref 34525); Fri, 01 Mar 2019 14:40:02 +0000 Received: (at 34525) by debbugs.gnu.org; 1 Mar 2019 14:39:20 +0000 Received: from localhost ([127.0.0.1]:55965 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzjJo-0004v4-CU for submit@debbugs.gnu.org; Fri, 01 Mar 2019 09:39:20 -0500 Received: from colin.muc.de ([193.149.48.1]:19236 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gzjJm-0004uv-J2 for 34525@debbugs.gnu.org; Fri, 01 Mar 2019 09:39:19 -0500 Received: (qmail 88800 invoked by uid 3782); 1 Mar 2019 14:39:17 -0000 Received: from acm.muc.de (p4FE15D75.dip0.t-ipconnect.de [79.225.93.117]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Mar 2019 15:39:16 +0100 Received: (qmail 10851 invoked by uid 1000); 1 Mar 2019 14:34:14 -0000 Date: Fri, 1 Mar 2019 14:34:14 +0000 Message-ID: <20190301143414.GD5674@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <0e2f5e3a-4a1c-a118-5970-9053215ac7f0@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e2f5e3a-4a1c-a118-5970-9053215ac7f0@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de 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 (-) Hello, Daniel. On Wed, Feb 20, 2019 at 21:25:27 +0000, Daniel Lopez wrote: > Hi Eli and Alan, > Thanks for investigating. [ .... ] We now understand what went wrong. There was a problem in the handling of a position cache in the code for "intervals" (which support text properties). There was also a smaller problem with an off-by-1 in the regex handling code. I enclose below a patch to fix the bug, which should apply cleanly to the Emacs 26.1 source tree. The fix will NOT be incorporated into the upcoming 26.2 release, since it is just too risky for the small amount of testing time we have left. However, I think the patch will also apply cleanly to 26.2 when it gets released. Please feel free to try out the patch, and let me know of any undesirable things you see with it. Thanks again for taking the trouble to report this interesting bug. diff --git a/src/intervals.c b/src/intervals.c index e7595b23b3..36bbc122b0 100644 --- a/src/intervals.c +++ b/src/intervals.c @@ -713,11 +713,21 @@ previous_interval (register INTERVAL interval) return NULL; } -/* Find the interval containing POS given some non-NULL INTERVAL - in the same tree. Note that we need to update interval->position - if we go down the tree. - To speed up the process, we assume that the ->position of - I and all its parents is already uptodate. */ +/* Set the ->position field of I's parent, based on I->position. */ +#define SET_PARENT_POSITION(i) \ + if (AM_LEFT_CHILD (i)) \ + INTERVAL_PARENT (i)->position = \ + i->position + TOTAL_LENGTH (i) - LEFT_TOTAL_LENGTH (i); \ + else \ + INTERVAL_PARENT (i)->position = \ + i->position - LEFT_TOTAL_LENGTH (i) \ + - LENGTH (INTERVAL_PARENT (i)) + +/* Find the interval containing POS, given some non-NULL INTERVAL in + the same tree. Note that we update interval->position in each + interval we traverse, assuming it is already correctly set for the + argument I. We don't assume that any other interval already has a + correctly set ->position. */ INTERVAL update_interval (register INTERVAL i, ptrdiff_t pos) { @@ -738,7 +748,10 @@ update_interval (register INTERVAL i, ptrdiff_t pos) else if (NULL_PARENT (i)) error ("Point before start of properties"); else - i = INTERVAL_PARENT (i); + { + SET_PARENT_POSITION (i); + i = INTERVAL_PARENT (i); + } continue; } else if (pos >= INTERVAL_LAST_POS (i)) @@ -753,7 +766,10 @@ update_interval (register INTERVAL i, ptrdiff_t pos) else if (NULL_PARENT (i)) error ("Point %"pD"d after end of properties", pos); else - i = INTERVAL_PARENT (i); + { + SET_PARENT_POSITION (i); + i = INTERVAL_PARENT (i); + } continue; } else diff --git a/src/intervals.h b/src/intervals.h index 311ef79466..873e2748ea 100644 --- a/src/intervals.h +++ b/src/intervals.h @@ -32,11 +32,15 @@ struct interval ptrdiff_t total_length; /* Length of myself and both children. */ ptrdiff_t position; /* Cache of interval's character position. */ - /* This field is usually updated - simultaneously with an interval - traversal, there is no guarantee - that it is valid for a random - interval. */ + /* This field is valid in the final + target interval returned by + find_interval, next_interval, + previous_interval and + update_interval. It cannot be + depended upon in any intermediate + intervals traversed by these + functions, or any other + interval. */ struct interval *left; /* Intervals which precede me. */ struct interval *right; /* Intervals which succeed me. */ diff --git a/src/regex.c b/src/regex.c index 09ed64a6e1..d5d22f7188 100644 --- a/src/regex.c +++ b/src/regex.c @@ -5898,8 +5898,8 @@ re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1, int s1, s2; int dummy; #ifdef emacs - ssize_t offset = PTR_TO_OFFSET (d - 1); - ssize_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset); + ssize_t offset = PTR_TO_OFFSET (d); + ssize_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset) - 1; UPDATE_SYNTAX_TABLE_FAST (charpos); #endif GET_CHAR_BEFORE_2 (c1, d, string1, end1, string2, end2); @@ -5985,8 +5985,8 @@ re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1, int s1, s2; int dummy; #ifdef emacs - ssize_t offset = PTR_TO_OFFSET (d) - 1; - ssize_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset); + ssize_t offset = PTR_TO_OFFSET (d); + ssize_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset) - 1; UPDATE_SYNTAX_TABLE_FAST (charpos); #endif GET_CHAR_BEFORE_2 (c1, d, string1, end1, string2, end2); @@ -6002,7 +6002,7 @@ re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1, PREFETCH_NOLIMIT (); GET_CHAR_AFTER (c2, d, dummy); #ifdef emacs - UPDATE_SYNTAX_TABLE_FORWARD_FAST (charpos); + UPDATE_SYNTAX_TABLE_FORWARD_FAST (charpos + 1); #endif s2 = SYNTAX (c2); @@ -6072,8 +6072,8 @@ re_match_2_internal (struct re_pattern_buffer *bufp, const_re_char *string1, re_wchar_t c1, c2; int s1, s2; #ifdef emacs - ssize_t offset = PTR_TO_OFFSET (d) - 1; - ssize_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset); + ssize_t offset = PTR_TO_OFFSET (d); + ssize_t charpos = SYNTAX_TABLE_BYTE_TO_CHAR (offset) - 1; UPDATE_SYNTAX_TABLE_FAST (charpos); #endif GET_CHAR_BEFORE_2 (c1, d, string1, end1, string2, end2); diff --git a/src/syntax.c b/src/syntax.c index 3cc32094a8..ca9e2bbca9 100644 --- a/src/syntax.c +++ b/src/syntax.c @@ -339,20 +339,6 @@ update_syntax_table (ptrdiff_t charpos, EMACS_INT count, bool init, invalidate = false; if (!i) return; - /* interval_of updates only ->position of the return value, so - update the parents manually to speed up update_interval. */ - while (!NULL_PARENT (i)) - { - if (AM_RIGHT_CHILD (i)) - INTERVAL_PARENT (i)->position = i->position - - LEFT_TOTAL_LENGTH (i) + TOTAL_LENGTH (i) /* right end */ - - TOTAL_LENGTH (INTERVAL_PARENT (i)) - + LEFT_TOTAL_LENGTH (INTERVAL_PARENT (i)); - else - INTERVAL_PARENT (i)->position = i->position - LEFT_TOTAL_LENGTH (i) - + TOTAL_LENGTH (i); - i = INTERVAL_PARENT (i); - } i = gl_state.forward_i; gl_state.b_property = i->position - gl_state.offset; gl_state.e_property = INTERVAL_LAST_POS (i) - gl_state.offset; > Daniel -- Alan Mackenzie (Nuremberg, Germany). From unknown Sun Jun 22 22:44:32 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Daniel Lopez Subject: bug#34525: closed (Re: bug#34525: replace-regexp missing some matches) Message-ID: References: <20190301174242.GA10816@ACM> <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> X-Gnu-PR-Message: they-closed 34525 X-Gnu-PR-Package: emacs,cc-mode Reply-To: 34525@debbugs.gnu.org Date: Fri, 01 Mar 2019 17:48:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1551462482-4164-1" This is a multi-part message in MIME format... ------------=_1551462482-4164-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #34525: replace-regexp missing some matches which was filed against the emacs,cc-mode package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 34525@debbugs.gnu.org. --=20 34525: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D34525 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1551462482-4164-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 34525-done) by debbugs.gnu.org; 1 Mar 2019 17:47:50 +0000 Received: from localhost ([127.0.0.1]:56770 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzmGE-00014m-BZ for submit@debbugs.gnu.org; Fri, 01 Mar 2019 12:47:50 -0500 Received: from colin.muc.de ([193.149.48.1]:64454 helo=mail.muc.de) by debbugs.gnu.org with smtp (Exim 4.84_2) (envelope-from ) id 1gzmGB-00014b-Ub for 34525-done@debbugs.gnu.org; Fri, 01 Mar 2019 12:47:48 -0500 Received: (qmail 99699 invoked by uid 3782); 1 Mar 2019 17:47:45 -0000 Received: from acm.muc.de (p4FE15D75.dip0.t-ipconnect.de [79.225.93.117]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Mar 2019 18:47:44 +0100 Received: (qmail 8877 invoked by uid 1000); 1 Mar 2019 17:42:42 -0000 Date: Fri, 1 Mar 2019 17:42:42 +0000 To: 34525-done@debbugs.gnu.org Subject: Re: bug#34525: replace-regexp missing some matches Message-ID: <20190301174242.GA10816@ACM> References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Delivery-Agent: TMDA/1.1.12 (Macallan) From: Alan Mackenzie X-Primary-Address: acm@muc.de X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34525-done Cc: Daniel Lopez 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 (-) Bug fixed in master. Closing. -- Alan Mackenzie (Nuremberg, Germany). ------------=_1551462482-4164-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 18 Feb 2019 08:30:52 +0000 Received: from localhost ([127.0.0.1]:52053 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gveKB-00017T-9F for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:30:51 -0500 Received: from eggs.gnu.org ([209.51.188.92]:34411) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gveK9-00017H-Od for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:30:50 -0500 Received: from lists.gnu.org ([209.51.188.17]:55452) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gveK4-0004xr-Fg for submit@debbugs.gnu.org; Mon, 18 Feb 2019 03:30:44 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gveK2-0007Lz-KJ for bug-gnu-emacs@gnu.org; Mon, 18 Feb 2019 03:30:44 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,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 1gveJw-0004uX-0z for bug-gnu-emacs@gnu.org; Mon, 18 Feb 2019 03:30:42 -0500 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:44424) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gveJs-0004rm-PX for bug-gnu-emacs@gnu.org; Mon, 18 Feb 2019 03:30:34 -0500 Received: by mail-wr1-x42b.google.com with SMTP id w2so2680904wrt.11 for ; Mon, 18 Feb 2019 00:30:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=QKexhx5J5hqVApGXKje0qyOnN7FcAuu0zvPDSybMG5U=; b=iHT3Z9TrT7gxCqOYmatZ2DlHaDJY9bt5dvgwqxJReEznpU2io0snIZD6xdUM2p79IC BpPYxkYECHSkUDaFNjM4QB2LTdtyafkgyTv/dtsPxLhdAzRi+i/r5OnAS5YQQqvILHvD u+LMVvEY+pzf5645rcJKD8ZoNUKGYPEQmm+IwD9zjXobKqMLvq2YK9nUitkMCw8JqJJb he7qw9cbG1qbFP5ENo3U1ZmNZ2kzGQGG3nxXNsezL+Shcr0NOSLXk9+86YDBZTqqNgec 3K2hLpqmplhCYp6f5kKNHnyGaL70I04kH9xRLO2eWPyV3nCARax9LxfqFRrEYTH6X0za rZHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=QKexhx5J5hqVApGXKje0qyOnN7FcAuu0zvPDSybMG5U=; b=b67VdONad98vjKpFZzOu19avISuywmntVZUisrXARu1RfS3fNFU+6WDumfhLlcsEkx Mtc2xJ2ORh6usmYRKdcb4OC09yJ5nlBIU23U+pzZ/SUOcBkKYn9FdTmn0P87hO9qart0 tal+H2QBS8E7Xq0sWdk1WsVVlLq3bdn6FwTiTjacufAp1nWiT8eEYrtM7hneeMdn++Av F850k5EDcqxxn3+0YMOQuSRbUBoZICNcmSS2Ap3vkkrrW8nyS2Y3l1ROJS0dDRkqjw0W n2VaHFVnWav0D+12xDHhzZIMHfftnKvPDX6CWKqFJIh2MjNeljssnkz4HUnO/IrI8SKp RScw== X-Gm-Message-State: AHQUAuaWzXzEtwaPvvcafvKL6ey99FCrgLK50ZzEDDVsYknCD9O4LSXZ shTd0ylpEfaqKqoC+GdcJopqqlSH X-Google-Smtp-Source: AHgI3IZoZ7LCIUtegEOD+hXjXLacewaNGl7OLsqYV1BrOzoRK7GLmBuschRftXjyCAf6eAsuqpgT4A== X-Received: by 2002:a5d:5042:: with SMTP id h2mr15716070wrt.12.1550478627281; Mon, 18 Feb 2019 00:30:27 -0800 (PST) Received: from [192.168.2.2] (w-79.cust-5765.ip.static.uno.uk.net. [95.172.231.79]) by smtp.googlemail.com with ESMTPSA id u6sm7828452wmj.28.2019.02.18.00.30.25 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 18 Feb 2019 00:30:26 -0800 (PST) To: bug-gnu-emacs@gnu.org From: Daniel Lopez Subject: replace-regexp missing some matches Message-ID: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> Date: Mon, 18 Feb 2019 08:28:35 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------4A0208EF172FFB4FBC0E5D25" Content-Language: en-US-large X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42b X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 1.2 (+) 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: Reproduce: - Start "emacs -Q" and open the file BitmapFontFace.h - Evaluate the expression (replace-regexp "\\" "SharedBitmap") - The text "Replaced 8 occurrences" appears in the echo area. Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (daniel.lopez999[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (daniel.lopez999[at]gmail.com) 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 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.2 (/) This is a multi-part message in MIME format. --------------4A0208EF172FFB4FBC0E5D25 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Reproduce: - Start "emacs -Q" and open the file BitmapFontFace.h - Evaluate the expression (replace-regexp "\\" "SharedBitmap") - The text "Replaced 8 occurrences" appears in the echo area. Problem: There were actually 12 occurrences (ie. of the word "Bitmap" surrounded by word boundaries) in the file that should have been replaced. If I now move point back to the start of the buffer and evaluate the expression again, it says "Replaced 4 occurrences". The exact number of incorrect replacements perhaps varies over time. That is, I can test it five times in a row and get 8 initial replacments each time, but after trying some other search terms, messing with the file, restarting Emacs etc, I try my initial test again and then maybe it consistently replaces 10 the first time, for a while. So your exact numbers may vary. I debugged the Lisp as far as I could and it appears to be wrong answers coming out of the re-search-forward C call that is in isearch-search-fun-default. The bug filters up to a number of string replacement user actions - I first noticed it when trying to do this replacement interactively with query-replace on word boundaries (C-u M-%), entering "Bitmap" as search string, then "SharedBitmap" as replacement string. Trying now, as I press space repeatedly about once a second to confirm each one, I see the pink highlight skip valid matches to ask me about one that is further down even while I see the skipped one highlighted in blue a few lines above, and in the end it may have replaced only 6-8 of the occurrences. Though, if I press 'n' instead of space to skip without making any replacements, it does visit all of the occurrences. I see from the Lisp that plain (non-regexp) query-replace on word boundaries gets preprocessed into the equivalent regexp search as in my initial example. I don't think there are any problems with plain string search and replacement. Some more experimental observations: - The replacement text can be any string instead of "SharedBitmap", eg. "qwertyasdfgh", "qwer", etc, and the bug still happens. The number of matches seems to be related to the length of the replacement string. Currently 12 character replacement strings are causing replace-regexp to make 8 replacements on the first call for me, while 4 character strings cause 7 replacements. 6 character replacement strings - ie. same length as "Bitmap" - always work, replacing all 12 occurrences. - The bug doesn't happen in fundamental-mode, nor c-mode, js-mode, text-mode or any other major modes I tried. - I've seen this happen in other of my C++ files where I was making the same replacement, so the problem's not precisely unique to this one. I've been trying to simplify this one but haven't found anything much more revealing so far. For example if I delete all the comments and blank lines, then the first replacement finds 9 occurrences out of 10. If I cut the file in half by deleting line 140 onwards, the first replacement finds 3 occurrences out of 6. But if I do something very simple like just pasting "Bitmap" on 100 consecutive lines, it's not fooled and it replaces them all. I've tried this in GNU Emacs 26.1 on Arch Linux and 25.2.1 on Windows 7 and am seeing the same behaviour in both. Thanks, Daniel --------------4A0208EF172FFB4FBC0E5D25 Content-Type: text/x-chdr; name="BitmapFontFace.h" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="BitmapFontFace.h" // BitmapFontFace: A class to store a font in which the glyphs are stored in bitmaps. #pragma once // This namespace #include "FontFaceMetrics.h" // Dan std #include #include #include #include using dan::Error; // Boost #include using boost::scoped_array; #include // C++ std #include #include namespace dan { struct BitmapFontGlyph // Where to find the graphic for a single character // // (This is only used by BitmapFontFace but isn't declared within it as it doesn't need to // use BitmapFontFace's template parameters) { unsigned int bitmapNo; // Which bitmap of the BitmapFontFace contains the glyph of this character dan::math::Rect2I rect; // The position and size on the bitmap of the character's glyph dan::math::Vector2I bearing; // Distance from the drawing pen position to where the top-left of the glyph should be dan::math::Vector2I advance; // The number of pixels that the drawing pen position should be moved // after printing this character, to be ready for the next one BitmapFontGlyph(unsigned int i_bitmapNo, const dan::math::Rect2I & i_rect, const dan::math::Vector2I & i_bearing, const dan::math::Vector2I & i_advance) : bitmapNo(i_bitmapNo), rect(i_rect), bearing(i_bearing), advance(i_advance) {} }; typedef std::map BitmapFontCharmap; // Represents a character map, // ie. a full alphabet of mappings from character code numbers to glyphs. // This collection of mappings is also known as a character encoding. // // (This is only used by BitmapFontFace but isn't declared within it as it doesn't need to // use BitmapFontFace's template parameters) template class BitmapFontFace { // + Shared part {{{ protected: struct Shared { std::vector< Bitmap > m_bitmaps; std::vector m_charmaps; float m_emHeight; FontFaceMetrics m_metrics; unsigned int m_replacementForMissingCharCode = 0; // + Construction {{{ Shared(float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with no bitmaps or charmaps {} Shared(const std::vector< Bitmap > & i_bitmaps, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with multiple bitmaps and multiple charmaps { m_bitmaps.assign(i_bitmaps.begin(), i_bitmaps.end()); m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } Shared(const Bitmap & i_bitmap, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with single bitmap and multiple charmaps // (bitmap specified in Bitmap object) { m_bitmaps.push_back(i_bitmap); m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } Shared(PixelType * i_srcBitmap_pixels, unsigned int i_srcBitmap_width, unsigned int i_srcBitmap_height, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct with single bitmap and multiple charmaps // (bitmap specified as buffer, width and height) { m_bitmaps.push_back(Bitmap(i_srcBitmap_pixels, i_srcBitmap_width, i_srcBitmap_height)); m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } Shared(const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_emHeight(i_emHeight) , m_metrics(i_metrics) // Construct without any bitmaps stored (class stores font metadata only) { m_charmaps.assign(i_charmaps.begin(), i_charmaps.end()); } // + }}} }; boost::shared_ptr m_shared; // + }}} // + Construction {{{ public: BitmapFontFace(float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_emHeight, i_metrics)) // Construct with no bitmaps or charmaps {} BitmapFontFace(const std::vector< Bitmap > & i_bitmaps, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_bitmaps, i_charmaps, i_emHeight, i_metrics)) // Construct with multiple bitmaps and multiple charmaps {} BitmapFontFace(const Bitmap & i_bitmap, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_bitmap, i_charmaps, i_emHeight, i_metrics)) // Construct with single bitmap and multiple charmaps // (bitmap specified in Bitmap object) {} BitmapFontFace(PixelType * i_srcBitmap_pixels, unsigned int i_srcBitmap_width, unsigned int i_srcBitmap_height, const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_srcBitmap_pixels, i_srcBitmap_width, i_srcBitmap_height, i_charmaps, i_emHeight, i_metrics)) // Construct with single bitmap and multiple charmaps // (bitmap specified as buffer, width and height) {} BitmapFontFace(const std::vector & i_charmaps, float i_emHeight = 1, const FontFaceMetrics & i_metrics = FontFaceMetrics()) : m_shared(new Shared(i_charmaps, i_emHeight, i_metrics)) // Construct without any bitmaps stored (class stores font metadata only) {} // + }}} // + Bitmaps {{{ const std::vector< Bitmap > & bitmaps() const { return m_shared->m_bitmaps; } std::vector< Bitmap > & bitmaps() { return m_shared->m_bitmaps; } //void releaseBitmaps() //{ // m_bitmaps.clear(); //} // + }}} // + Charmaps {{{ const std::vector & charmaps() const { return m_shared->m_charmaps; } unsigned int charmap_count() const { return m_shared->m_charmaps.size(); } unsigned int charmap_charCount() const { return m_shared->m_charmaps.front().size(); } // + }}} // + Metrics {{{ unsigned int emHeight() const { return m_shared->m_emHeight; } FontFaceMetrics & metrics() const { return m_shared->m_metrics; } // + }}} // + Get details of a single char {{{ unsigned int replacementForMissingCharCode() const { return m_shared->m_replacementForMissingCharCode; } void replacementForMissingCharCode(unsigned int i_charCode) const { m_shared->m_replacementForMissingCharCode = i_charCode; } const BitmapFontGlyph & getGlyph(unsigned int i_charmapNo, unsigned int i_charCode) const { if (i_charmapNo >= m_shared->m_charmaps.size()) throw( Error(0, "in BitmapFontFace::getGlyph, i_charmapNo out of range") ); BitmapFontCharmap & charmap = m_shared->m_charmaps[i_charmapNo]; BitmapFontCharmap::const_iterator glyphItr = charmap.find(i_charCode); if (glyphItr == charmap.end()) { if (m_shared->m_replacementForMissingCharCode == 0) throw( Error(0, "in BitmapFontFace::getGlyph, no glyph in charmap for i_charCode") ); glyphItr = charmap.find(m_shared->m_replacementForMissingCharCode); if (glyphItr == charmap.end()) throw( Error(0, "in BitmapFontFace::getGlyph, no glyph in charmap for i_charCode or its replacement code") ); } return glyphItr->second; } const Bitmap & getGlyphBitmap(unsigned int i_charmapNo, unsigned int i_charCode) const { return m_shared->m_bitmaps[getGlyph(i_charmapNo, i_charCode).bitmapNo]; } const dan::math::Rect2I & getGlyphRect(unsigned int i_charmapNo, unsigned int i_charCode) const { return getGlyph(i_charmapNo, i_charCode).rect; } // + }}} dan::math::Vector2I charAdvanceMax() const { dan::math::Vector2I maxValue = 0; for (unsigned int charmapNo = 0; charmapNo < m_shared->m_charmaps.size(); ++charmapNo) { const BitmapFontCharmap & charmap = m_shared->m_charmaps[charmapNo]; for (BitmapFontCharmap::const_iterator glyphItr = charmap.begin(); glyphItr != charmap.end(); ++glyphItr) { if (glyphItr->second.advance[0] > maxValue[0]) maxValue[0] = glyphItr->second.advance[0]; if (glyphItr->second.advance[1] > maxValue[1]) maxValue[1] = glyphItr->second.advance[1]; } } return maxValue; } dan::math::Vector2I charRectSizeMax() const { dan::math::Vector2I maxValue = 0; for (unsigned int charmapNo = 0; charmapNo < m_shared->m_charmaps.size(); ++charmapNo) { const BitmapFontCharmap & charmap = m_shared->m_charmaps[charmapNo]; for (BitmapFontCharmap::const_iterator glyphItr = charmap.begin(); glyphItr != charmap.end(); ++glyphItr) { if (glyphItr->second.rect.width() > maxValue[0]) maxValue[0] = glyphItr->second.rect.width(); if (glyphItr->second.rect.height() > maxValue[1]) maxValue[1] = glyphItr->second.rect.height(); } } return maxValue; } }; } --------------4A0208EF172FFB4FBC0E5D25-- ------------=_1551462482-4164-1-- From unknown Sun Jun 22 22:44:32 2025 X-Loop: help-debbugs@gnu.org Subject: bug#34525: replace-regexp missing some matches Resent-From: Daniel Lopez Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org, bug-cc-mode@gnu.org Resent-Date: Fri, 01 Mar 2019 18:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 34525 X-GNU-PR-Package: emacs,cc-mode X-GNU-PR-Keywords: To: Alan Mackenzie Cc: Eli Zaretskii , 34525@debbugs.gnu.org Received: via spool by 34525-submit@debbugs.gnu.org id=B34525.15514632335311 (code B ref 34525); Fri, 01 Mar 2019 18:01:02 +0000 Received: (at 34525) by debbugs.gnu.org; 1 Mar 2019 18:00:33 +0000 Received: from localhost ([127.0.0.1]:56777 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzmST-0001NX-KS for submit@debbugs.gnu.org; Fri, 01 Mar 2019 13:00:31 -0500 Received: from mail-wr1-f45.google.com ([209.85.221.45]:45094) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gzmSO-0001NH-W8 for 34525@debbugs.gnu.org; Fri, 01 Mar 2019 13:00:25 -0500 Received: by mail-wr1-f45.google.com with SMTP id w17so26803804wrn.12 for <34525@debbugs.gnu.org>; Fri, 01 Mar 2019 10:00:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Umq11mT+Qp/kjJx3SNT9/M/4NSpHiFWakossYC1Q6RE=; b=PWpi175EIzZiHaSGvQ9+BoUqzD1UQzpJGcczD5I6vjpV1JknoSpdQHcYhUB0+so2Ax IgLsm2V5kUwcVqky0iy/Aoyt6677Klh/Q2log7dg2T1VxiXqgktGBX7VuxEqHwN3EhrM Y7+Oo3Olqyur/P6qhidPdSOkq9taaz5k1NUJZO2eGFxJsg1DwllgYnf153xOH27P+8wV SkqptHnvQt5VbwFxnnrcChvBvnK4+w/GVX5iatiL+Anw3gq2g/8vc07UBsfUvbbGDEVx 8/MI2m4sKnIeKYjS3IxKpfdLty/5f9LlXbbix0F1UEnBOfcifqD0Slm1TUdqxamcddcN 3a8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Umq11mT+Qp/kjJx3SNT9/M/4NSpHiFWakossYC1Q6RE=; b=pWngbLRZOwZuGwEYSCUCPM+3kVptyhnL+hxWFlsdG+2yAARqaeTGuW76MSrO2G8WGG 56UU8eC7MpCjSN3mL7xknFCy6SZUV4H952z6t47nkt026McPW3G6+MYSGOkBqOJlPpWx zyk4RRwhgvbUbsB5UoIct3GsVhiMr/pFM+Hc0fdINYsz9kuYp7Bib/aM7lUQHrrPX/Kx WWczGETTPP/6LaUEprd4JuyGQqwQo1HjlVdkHXhtlOBJwzzU3MmZC21XI9Iz8jBHeGVl ZRhVD5dD1cOk/URmsNV/i3Evjp46Xgq7VOc7wiaFAzpqMmKRI4yUW0gbpb4msXigVptz ZojQ== X-Gm-Message-State: APjAAAUNcP/7Fh0b+FqR99kt6Ly0NwDT/F74w5UISQwJWx42hv3OHE0X K9KgI/PK26ZIRcSFjltS9VsO8UWG X-Google-Smtp-Source: APXvYqwNNJjq2n+k8BCnaccS/JVBqnuRNxbYrHrPLk+KblN8N9d8ktWVw8h+DfOXvLcl3uD3bcGqkQ== X-Received: by 2002:a5d:428b:: with SMTP id k11mr4551494wrq.17.1551463218714; Fri, 01 Mar 2019 10:00:18 -0800 (PST) Received: from [192.168.2.2] (w-79.cust-5765.ip.static.uno.uk.net. [95.172.231.79]) by smtp.googlemail.com with ESMTPSA id h137sm10267918wmg.41.2019.03.01.10.00.17 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 10:00:17 -0800 (PST) References: <5a74a337-804e-2590-bffd-43a851f90240@gmail.com> <83zhqtjdtz.fsf@gnu.org> <20190220170722.GA9655@ACM> <83sgwigwxm.fsf@gnu.org> <20190220185850.GB9655@ACM> <0e2f5e3a-4a1c-a118-5970-9053215ac7f0@gmail.com> <20190301143414.GD5674@ACM> From: Daniel Lopez Message-ID: <54febc5c-a3e8-650e-3c22-44ca3a46ec1c@gmail.com> Date: Fri, 1 Mar 2019 17:58:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190301143414.GD5674@ACM> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US-large Content-Transfer-Encoding: 7bit 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 (/) Thanks very much Alan (and Eli and Stefan), I've just installed this locally. It looks good, and I'll let you know if anything seems to go awry subsequently, which I don't expect :) Daniel