bug#46876: [PATCH] Find conflict markers in opened buffers as well

[Konstantin Kharlamov <hi-angel@yandex.ru>]

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.