How to navigate to next git conflict?

How to navigate to next git conflict?

[Hi-Angel]

For working with git I noted one of frequent actions I do is resolving
conflicts. I'm comfortable to work with most of that from terminal
(I've got a completion in zsh and what not…) except that conflict
navigation could use a bit of automation.

So far I only managed to find `smerge-next`, but it is limited to the
focused buffer, in there I can as well search for a HEAD or <<<
markers, so not really useful.

Re: How to navigate to next git conflict?

[Stefan Monnier]

> For working with git I noted one of frequent actions I do is resolving
> conflicts. I'm comfortable to work with most of that from terminal
> (I've got a completion in zsh and what not…) except that conflict
> navigation could use a bit of automation.
>
> So far I only managed to find `smerge-next`, but it is limited to the
> focused buffer, in there I can as well search for a HEAD or <<<
> markers, so not really useful.

There's also `vc-find-conflicted-file` to go to the next file with
conflicts when you're done with one.


        Stefan

Re: How to navigate to next git conflict?

[Hi-Angel]

Thanks!

So, for now I wrote the following function, hope this helps someone

(defun smerge-next-safe ()
    "returns t on success, nil otherwise"
  (condition-case err
      (not (smerge-next))
    ('error
     nil)))


(defun next-conflict ()
  (interactive)
  (let ((buffer (current-buffer)))
    (when (not (smerge-next-safe))
      (vc-find-conflicted-file)
      (if (eq buffer (current-buffer))
        (message "No conflicts found"))
        (smerge-next-safe)))
  )

I guess I'll try to contribute a similar functional to Emacs on the weekend.

On Tue, 29 Jan 2019 at 12:43, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> > For working with git I noted one of frequent actions I do is resolving
> > conflicts. I'm comfortable to work with most of that from terminal
> > (I've got a completion in zsh and what not…) except that conflict
> > navigation could use a bit of automation.
> >
> > So far I only managed to find `smerge-next`, but it is limited to the
> > focused buffer, in there I can as well search for a HEAD or <<<
> > markers, so not really useful.
>
> There's also `vc-find-conflicted-file` to go to the next file with
> conflicts when you're done with one.
>
>
>         Stefan
>
>

Re: How to navigate to next git conflict?

[Stefan Monnier]

>   (condition-case err
>       (not (smerge-next))
>     ('error

This catches both the `error` and the `quote` conditions.


        Stefan

Re: How to navigate to next git conflict?

[Hi-Angel]

On Wed, 6 Feb 2019 at 17:11, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >   (condition-case err
> >       (not (smerge-next))
> >     ('error
>
> This catches both the `error` and the `quote` conditions.
>
>
>         Stefan

What is "quote condition"? FWIW, it's very hard to find how to catch
some "error". I managed to find this way of doing that in someone's
blog post.

Re: How to navigate to next git conflict?

[Stefan Monnier]

>> >   (condition-case err
>> >       (not (smerge-next))
>> >     ('error
>> This catches both the `error` and the `quote` conditions.
> What is "quote condition"?

I don't know of any `quote` condition, indeed.  Yet that's what you
wrote in your code by placing a spurious ' in front of `error`.

When you write

    'error
    
it is 100% indistinguishable from writing

    (quote error)

so this is the list of conditions your code catches.  If you only want
to catch `error` then you can write

     (condition-case ...
         ...
       (error ...))
or
     (condition-case ...
         ...
       ((error) ...))

> FWIW, it's very hard to find how to catch some "error".

Have you looked in the Emacs Lisp documentation included in Emacs,
e.g. in the Emacs Lisp Introduction?

> I managed to find this way of doing that in someone's blog post.

Could you warn this blogger about his mistake so it doesn't spread
yet further?


        Stefan

Re: How to navigate to next git conflict?

[Hi-Angel]

On Wed, 6 Feb 2019 at 18:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
> >> >   (condition-case err
> >> >       (not (smerge-next))
> >> >     ('error
> >> This catches both the `error` and the `quote` conditions.
> > What is "quote condition"?
>
> I don't know of any `quote` condition, indeed.  Yet that's what you
> wrote in your code by placing a spurious ' in front of `error`.
>
> When you write
>
>     'error
>
> it is 100% indistinguishable from writing
>
>     (quote error)
>
> so this is the list of conditions your code catches.  If you only want
> to catch `error` then you can write
>
>      (condition-case ...
>          ...
>        (error ...))
> or
>      (condition-case ...
>          ...
>        ((error) ...))
>
> > FWIW, it's very hard to find how to catch some "error".
>
> Have you looked in the Emacs Lisp documentation included in Emacs,
> e.g. in the Emacs Lisp Introduction?

Hmm, yes. Now that I look back at the docs, there is an example of
that, right at beginning. It is on this page
https://www.gnu.org/software/emacs/manual/html_node/elisp/Handling-Errors.html

I guess the problem is that catching an error by writing "error" on
one of condition branches looks like magic, because it the word
"error" supposed to evaluate to something.

So, what happened, is that I read the example, it didn't make any
sense (even more so because I didn't know at that moment about
existence of "error", and thought smerge is using "throw"), and then I
scrolled down (and completely discarded the example from my memory as
useless) through other code examples on this page, found
condition-case use for catching arithmetic error, and figured I need
to use this construction (somewhere then I found that smerge is using
"error" and not "throw"). However the part of docs for the
condition-case don't have examples beside arithmetic error, so I went
googling.

When I found on someone's blog use of "quote error" in condition, it
made sense, because 'error does not evaluate to anything.

In retrospective I guess this "magic error" branch is simply a macro,
that's why it looks so magical.

> > I managed to find this way of doing that in someone's blog post.
>
> Could you warn this blogger about his mistake so it doesn't spread
> yet further?

Sure, I left a comment. FTR the post is here
https://curiousprogrammer.wordpress.com/2009/06/08/error-handling-in-emacs-lisp/

Re: How to navigate to next git conflict?

[tomas]

[-- Attachment #1: Type: text/plain, Size: 389 bytes --]

On Thu, Feb 07, 2019 at 12:22:39AM +0300, Hi-Angel wrote:

[...]

> I guess the problem is that catching an error by writing "error" on
> one of condition branches looks like magic, because it the word
> "error" supposed to evaluate to something.

Ah, but condition case is a special form, so it /is/ magic :)

Special forms don't evaluate their arguments.

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: How to navigate to next git conflict?

[Hi-Angel]

So, to give some update: as I promised I sent patches to Emacs¹,
hopefully this functionality soon will appear out-of-the-box.

1: http://lists.gnu.org/archive/html/bug-gnu-emacs/2019-02/msg00395.html