From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#43715: 28.0.50; Duplicate results in project-find-regexp Date: Thu, 1 Oct 2020 23:38:01 +0300 Message-ID: References: <87lfgr5psh.fsf@gnus.org> <3644ac8e-4a82-78a2-24d7-001f491f6a0e@yandex.ru> <87lfgqwxtf.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30267"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: Pankaj Jangid , 43715@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Oct 01 22:39:12 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kO5M7-0007mO-SE for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 22:39:11 +0200 Original-Received: from localhost ([::1]:44374 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kO5M6-0000LC-RB for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 01 Oct 2020 16:39:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45474) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kO5Ly-0000J7-TL for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 16:39:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55230) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kO5Ly-0002wB-I2 for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 16:39:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kO5Ly-0000ae-Em for bug-gnu-emacs@gnu.org; Thu, 01 Oct 2020 16:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 01 Oct 2020 20:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 43715 X-GNU-PR-Package: emacs Original-Received: via spool by 43715-submit@debbugs.gnu.org id=B43715.16015846992219 (code B ref 43715); Thu, 01 Oct 2020 20:39:02 +0000 Original-Received: (at 43715) by debbugs.gnu.org; 1 Oct 2020 20:38:19 +0000 Original-Received: from localhost ([127.0.0.1]:38543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kO5LD-0000Zf-Se for submit@debbugs.gnu.org; Thu, 01 Oct 2020 16:38:19 -0400 Original-Received: from mail-ed1-f45.google.com ([209.85.208.45]:45000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kO5L9-0000ZP-0K for 43715@debbugs.gnu.org; Thu, 01 Oct 2020 16:38:14 -0400 Original-Received: by mail-ed1-f45.google.com with SMTP id b12so7025148edz.11 for <43715@debbugs.gnu.org>; Thu, 01 Oct 2020 13:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n/sf0joidc4+qmQ3l9VqC5/rFDGLCYmGTJrzpICmUcU=; b=k9W+HAGBFmxKMJkeskUHfC0edH3OcFwIdevis8FLyiizzpZc5dLwOfIWeeAvE7KZQb AyJhr66UPfXS7gFY2zkIU/EqWwv2ZAgGLVVB9skvHEN1AnrIkvwTi/e1RaV97WCIcxmX U6oGFp57pJD0Z9LxH4lVXY8apW8qNK2OJBAW5E3RPWCyzekPI7dNj/UT3qcCKAH6sKkc zYfg6qjzxSpcebp1JgOqZq26ILIXKn9NC15GlkzY8CyB41S9mbyWs3tHYL/RNPwKD32W d25bdeVHwgSJjZ05UqVbU1yWfWUDg+w8FKDi/JP24kUIgULqsNLqHWjls8zzCPkmZDAr Zt+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n/sf0joidc4+qmQ3l9VqC5/rFDGLCYmGTJrzpICmUcU=; b=gzuiy5dX/5Hgih+FTDO4qfM/iPQt0DI/YnwszqhrVP4LjkH8GJI773z6xFX1yZN0sw hZFqc6aQrL8EPBXA2zRMPp3u00hOiGE/1xMVlyEoClNHzdg/a3GwD62RlFukVVZJ1Usr Q3lhMJkoiJIrBLNZGptbPmWxOvw36bgCahcw6RRjL3iTvVN97IQjCylBqtbOOsWvAobF lqiL0UFWCm9E/PC9Isj0cKwJncEqWAO+jSSyd7l//jDCaaHwELb8ZOgWSJgW33o5bXHM 4qm4Wyzw39//EyTC48d9DBKEZKLR4FP/f+rmSKZW5ZZDMAarGs6QVqH/QKmsXxs1JZ6c Zy/Q== X-Gm-Message-State: AOAM533t1YHtK3FkHhkMnnk24YSUuaDfVKNLIXLmYIpzF6YyH2V6p3hE kY+/4IRT2+fPEY3b3guKJySKbQp3ILTzbg== X-Google-Smtp-Source: ABdhPJxIcYqxw7BCWfHUFB6DeF1809GrSFH8fEBwNvhRkkox18vYJf/TzvDZV98lINfJJj3BmGZpUg== X-Received: by 2002:a05:6402:1bc2:: with SMTP id ch2mr9911769edb.60.1601584684769; Thu, 01 Oct 2020 13:38:04 -0700 (PDT) Original-Received: from [192.168.0.4] ([66.205.71.3]) by smtp.googlemail.com with ESMTPSA id a15sm4801638ejy.118.2020.10.01.13.38.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 01 Oct 2020 13:38:03 -0700 (PDT) In-Reply-To: <87lfgqwxtf.fsf@gnus.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:189585 Archived-At: On 01.10.2020 04:15, Lars Ingebrigtsen wrote: > Dmitry Gutov writes: > >> The behavior is less than ideal, but the fix will have to satisfy >> multiple constraints: the xref item creation (taking care of the >> format being backward-compatible), the rendering of them in the >> buffer, and the 'xref-query-replace-in-results' command, the >> implementation of which relies on the one-line-per-match property of >> an xref buffer. > > Right. I know next to nothing about xref internals... but... couldn't > this function just squash the multiple-matches-on-a-single-line into one > line? Preserving the text props from the multiple lines and whatnot? > So a post-processing step? Which function? xref-query-replace-in-results works on an existing xref buffer. And it uses the position of point (at the beginning of line) as both user indicator and to persist the state of the replacement process. Going back to xref buffers, if two matches are rendered on one line, that leads to a question of how 'n' and 'p' should behave (whether they would also jump between the matches on the same line).