unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Konstantin Kharlamov <hi-angel@yandex.ru>, 46876-done@debbugs.gnu.org
Subject: bug#46876: [PATCH] Find conflict markers in opened buffers as well
Date: Tue, 9 Mar 2021 16:15:02 +0200	[thread overview]
Message-ID: <d644cb70-5c00-c3ed-7d30-7422941878cc@yandex.ru> (raw)
In-Reply-To: <969164031c7e35971eaa4dedefd4e5acb2827613.camel@yandex.ru>

On 09.03.2021 08:32, Konstantin Kharlamov wrote:

>> 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.

I don't use Evil, but set-mark should work.

In any case, when the user is calling vc-find-conflicted-file, they 
probably want to either always go to the conflict markers (whether the 
file has been visited or not), or never. And "always" probably makes 
more sense.

It's not urgent, though, especially with neither command having a 
default binding.





      reply	other threads:[~2021-03-09 14:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02 16:23 bug#46876: [PATCH] Find conflict markers in opened buffers as well Konstantin Kharlamov
2021-03-02 19:37 ` Konstantin Kharlamov
2021-03-02 19:52   ` Konstantin Kharlamov
2021-03-09  2:31     ` Dmitry Gutov
2021-03-02 19:40 ` Konstantin Kharlamov
2021-03-09  2:51   ` Dmitry Gutov
2021-03-09  6:32     ` Konstantin Kharlamov
2021-03-09 14:15       ` Dmitry Gutov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d644cb70-5c00-c3ed-7d30-7422941878cc@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=46876-done@debbugs.gnu.org \
    --cc=hi-angel@yandex.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).