From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.bugs Subject: bug#46876: [PATCH] Find conflict markers in opened buffers as well Date: Tue, 09 Mar 2021 09:32:23 +0300 Message-ID: <969164031c7e35971eaa4dedefd4e5acb2827613.camel@yandex.ru> References: <20210302162349.709999-1-Hi-Angel@yandex.ru> <20210302194019.714751-1-Hi-Angel@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26395"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.38.4 To: Dmitry Gutov , 46876-done@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Mar 09 07:33:12 2021 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 1lJVvb-0006nE-Vd for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Mar 2021 07:33:11 +0100 Original-Received: from localhost ([::1]:55356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lJVva-0004DU-Ua for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 09 Mar 2021 01:33:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53602) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lJVvT-0004DJ-F3 for bug-gnu-emacs@gnu.org; Tue, 09 Mar 2021 01:33:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33911) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lJVvS-0007E4-KM for bug-gnu-emacs@gnu.org; Tue, 09 Mar 2021 01:33:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lJVvS-0006bV-Hl for bug-gnu-emacs@gnu.org; Tue, 09 Mar 2021 01:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Konstantin Kharlamov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 09 Mar 2021 06:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46876 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 46876-done@debbugs.gnu.org id=D46876.161527155425327 (code D ref 46876); Tue, 09 Mar 2021 06:33:02 +0000 Original-Received: (at 46876-done) by debbugs.gnu.org; 9 Mar 2021 06:32:34 +0000 Original-Received: from localhost ([127.0.0.1]:45457 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJVv0-0006aQ-6l for submit@debbugs.gnu.org; Tue, 09 Mar 2021 01:32:34 -0500 Original-Received: from forward102p.mail.yandex.net ([77.88.28.102]:44153) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lJVux-0006Vr-Rw for 46876-done@debbugs.gnu.org; Tue, 09 Mar 2021 01:32:33 -0500 Original-Received: from forward101q.mail.yandex.net (forward101q.mail.yandex.net [IPv6:2a02:6b8:c0e:4b:0:640:4012:bb98]) by forward102p.mail.yandex.net (Yandex) with ESMTP id AA56E1D4010B for <46876-done@debbugs.gnu.org>; Tue, 9 Mar 2021 09:32:24 +0300 (MSK) Original-Received: from vla1-85d2a0988c40.qloud-c.yandex.net (vla1-85d2a0988c40.qloud-c.yandex.net [IPv6:2a02:6b8:c0d:511a:0:640:85d2:a098]) by forward101q.mail.yandex.net (Yandex) with ESMTP id A661CCF40021 for <46876-done@debbugs.gnu.org>; Tue, 9 Mar 2021 09:32:24 +0300 (MSK) Original-Received: from vla1-1bc5b51c612f.qloud-c.yandex.net (vla1-1bc5b51c612f.qloud-c.yandex.net [2a02:6b8:c0d:89c:0:640:1bc5:b51c]) by vla1-85d2a0988c40.qloud-c.yandex.net (mxback/Yandex) with ESMTP id qzTJUysiIe-WOHKt3nh; Tue, 09 Mar 2021 09:32:24 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1615271544; bh=crapl74lNQQzCTsEcuxdnzNnHYmzIaqBGugJNUp5YoU=; h=In-Reply-To:References:Date:To:From:Subject:Message-ID; b=UTcMpCiSI/KIn3e7eNLpJQNUB7yU3eVz/k8nsTZh+kLP+snpiCZAA28Hfgc9YiuHg mAx55cX4suzRhMsagMEKrz342kZgQdIbBVPr26Oj7itYlwt98sSEv7Mtvrw6/3URDq aK2nKnbIiKzTnB++bQN/HWQ6MpwG9KllfTGNPYIw= Authentication-Results: vla1-85d2a0988c40.qloud-c.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by vla1-1bc5b51c612f.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id q3yH7hS23O-WNJO8BpI; Tue, 09 Mar 2021 09:32:24 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: 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:201898 Archived-At: On Tue, 2021-03-09 at 04:51 +0200, Dmitry Gutov wrote: > On 02.03.2021 21:40, Konstantin Kharlamov wrote: > > Call to (vc-find-conflicted-file) will only result in jump to a conflict > > marker when file is a newly opened one. When a file is already open in > > Emacs, (vc-find-conflicted-file) only switches to that buffer, so we > > need to explicitly jump to a conflict marker. > > > > * lisp/vc/smerge-mode.el (smerge-vc-next-conflict): Search for a > > conflict marker if call to (vc-find-conflicted-file) haven't resulted in > > a jump to one. And remove `buffer` variable that becomes unused. > > Thank you, this makes sense. Applied and pushed to master. Thank you! > This part is suboptimal: > >  > When a file is already open in >  > Emacs, (vc-find-conflicted-file) only switches to that buffer > > ...and I had to spend some time figuring out why that happens (hint: > vc-git-find-file-hook), and that kind of unpredictable behavior is Not > Good(tm). Back when I stumbled upon this behaviour, I didn't research into it because I thought it could be deliberate. The reasoning might have been: if you didn't have a file opened, it doesn't really matter where your point would be once it is. So it shouldn't hurt to just jump to a conflict marker, and so it does. On the other hand, if you did have the file opened, you might not want to lose position of your point (for example, you could have a selection, which you don't want to lose for some reason), IOW initial point position in this case might matter. I'm just speculating though, I do not know if it's true, neither I remember having a usecase as the one I imagine it's trying to cover. FWIW, usually when I want to save positions in a buffer, I use (evil-set-marker) from Evil package.