ediff merge wrapper

ediff merge wrapper

[Eliza Velasquez]

Hello,

Internally at Google, we have a wrapper performing an ediff merge with
emacs/emacsclient which blocks until the merge operation has
completed. It automatically handles edge cases such as creating a new
frame over ssh in tty mode or being invoked as an emacs subprocess. I
think it would be really useful to upstream a tool like this, given
that using emacs as a merge tool that can be invoked by software such
as mercurial or perforce can be very fiddly or have unexpected
behavior.

The biggest caveat is that the internal tool is written in golang, and
I imagine that you will want it to be rewritten to C. So before I go
and do that, I would like to gauge interest in distributing such a
wrapper alongside emacsclient and the like. What do you think?

Best,
Eliza

Re: ediff merge wrapper

[Daniel Martín]

Eliza Velasquez <exv@google.com> writes:

> Hello,
>
> Internally at Google, we have a wrapper performing an ediff merge with
> emacs/emacsclient which blocks until the merge operation has
> completed. It automatically handles edge cases such as creating a new
> frame over ssh in tty mode or being invoked as an emacs subprocess. I
> think it would be really useful to upstream a tool like this, given
> that using emacs as a merge tool that can be invoked by software such
> as mercurial or perforce can be very fiddly or have unexpected
> behavior.
>
> The biggest caveat is that the internal tool is written in golang, and
> I imagine that you will want it to be rewritten to C. So before I go
> and do that, I would like to gauge interest in distributing such a
> wrapper alongside emacsclient and the like. What do you think?

I think it's an interesting wrapper, yes.  I assume the main use case is
a very big repository where merge sets can be very large, right?

We could discuss if it has enough applicability to be in the Emacs core
distribution, but it's something I'd definitely like to see, at least as
part of the Emacs/VCS free software community.  Thanks.

Re: ediff merge wrapper

[chad]

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

On Mon, Nov 2, 2020 at 12:05 PM Eliza Velasquez <exv@google.com> wrote:

> Hello,
>
> Internally at Google, we have a wrapper performing an ediff merge with
> emacs/emacsclient which blocks until the merge operation has
> completed. [...]
>
> The biggest caveat is that the internal tool is written in golang, and
> I imagine that you will want it to be rewritten to C. So before I go
> and do that, I would like to gauge interest in distributing such a
> wrapper alongside emacsclient and the like. What do you think?
>

This certainly sounds interesting. If you start by sharing the golang
version, we can probably get enough eyeballs on it to generate some
opinions before you go through the trouble of rewriting it.

Thanks,
~Chad

[-- Attachment #2: Type: text/html, Size: 1120 bytes --]

Re: ediff merge wrapper

[Eli Zaretskii]

> From: Eliza Velasquez <exv@google.com>
> Date: Mon, 2 Nov 2020 12:01:33 -0800
> 
> Internally at Google, we have a wrapper performing an ediff merge with
> emacs/emacsclient which blocks until the merge operation has
> completed. It automatically handles edge cases such as creating a new
> frame over ssh in tty mode or being invoked as an emacs subprocess. I
> think it would be really useful to upstream a tool like this, given
> that using emacs as a merge tool that can be invoked by software such
> as mercurial or perforce can be very fiddly or have unexpected
> behavior.

Can you describe the use of this tool in more detail, and what
enhancements it implements beyond what emacsclient provides?  I don't
think I understand that from your short description.

Thanks.

Re: ediff merge wrapper

[Eliza Velasquez]

I replied with more details about how it works, but it seems I
accidentally sent them in a private email to Stefan. Sorry about that,
I'm not quite used to mailing lists. I'll copy what I wrote here.

Google's ediff_merge tool is invoked like:

ediff_merge /path/to/base_file /path/to/ancestor /path/to/file-a
/path/to/file-b /path/to/output-file

This command blocks until the merge operation is complete, i.e. when
the user quits ediff.

Upon further investigation of its source code, it seems that the need
for this tool may be obsoleted if this bug were to be fixed instead:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25547. Most of the
purpose of this tool seems to be a workaround for this behavior, and
it could probably be replaced with a call to `emacsclient -c -e
'(ediff-merge-with-ancestor "$a" "$b" "$ancestor" nil "$output")'` if
it were fixed.

Stefan and I had some additional discussion on the bug thread.

On Tue, Nov 3, 2020 at 8:47 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Eliza Velasquez <exv@google.com>
> > Date: Mon, 2 Nov 2020 12:01:33 -0800
> >
> > Internally at Google, we have a wrapper performing an ediff merge with
> > emacs/emacsclient which blocks until the merge operation has
> > completed. It automatically handles edge cases such as creating a new
> > frame over ssh in tty mode or being invoked as an emacs subprocess. I
> > think it would be really useful to upstream a tool like this, given
> > that using emacs as a merge tool that can be invoked by software such
> > as mercurial or perforce can be very fiddly or have unexpected
> > behavior.
>
> Can you describe the use of this tool in more detail, and what
> enhancements it implements beyond what emacsclient provides?  I don't
> think I understand that from your short description.
>
> Thanks.

Re: ediff merge wrapper

[Eliza Velasquez]

Okay, as I mentioned in the bug thread, I have a fix working which
requires some polish before I submit a patch for it. Unfortunately,
the emacsclient command to replace the wrapper script would still be
pretty long and unwieldy:

emacsclient -ucF "((delete-frame-on-ediff-quit . t))" \
  -e "(ediff-merge-with-ancestor \"${local}\" \"${other}\" \"${base}\"
nil \"${output}\")" \
  -e "(add-hook 'ediff-quit-hook (lambda () (when (frame-parameter nil
'delete-frame-on-ediff-quit) (delete-frame))))"

I think a more robust version of this command (that could correctly
handle cases where the server is not running) could be included as
both a bash script and a Windows batch script, which could then easily
be used as an HGMERGE or P4MERGE tool.

On Tue, Nov 3, 2020 at 10:44 AM Eliza Velasquez <exv@google.com> wrote:
>
> I replied with more details about how it works, but it seems I
> accidentally sent them in a private email to Stefan. Sorry about that,
> I'm not quite used to mailing lists. I'll copy what I wrote here.
>
> Google's ediff_merge tool is invoked like:
>
> ediff_merge /path/to/base_file /path/to/ancestor /path/to/file-a
> /path/to/file-b /path/to/output-file
>
> This command blocks until the merge operation is complete, i.e. when
> the user quits ediff.
>
> Upon further investigation of its source code, it seems that the need
> for this tool may be obsoleted if this bug were to be fixed instead:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25547. Most of the
> purpose of this tool seems to be a workaround for this behavior, and
> it could probably be replaced with a call to `emacsclient -c -e
> '(ediff-merge-with-ancestor "$a" "$b" "$ancestor" nil "$output")'` if
> it were fixed.
>
> Stefan and I had some additional discussion on the bug thread.
>
> On Tue, Nov 3, 2020 at 8:47 AM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Eliza Velasquez <exv@google.com>
> > > Date: Mon, 2 Nov 2020 12:01:33 -0800
> > >
> > > Internally at Google, we have a wrapper performing an ediff merge with
> > > emacs/emacsclient which blocks until the merge operation has
> > > completed. It automatically handles edge cases such as creating a new
> > > frame over ssh in tty mode or being invoked as an emacs subprocess. I
> > > think it would be really useful to upstream a tool like this, given
> > > that using emacs as a merge tool that can be invoked by software such
> > > as mercurial or perforce can be very fiddly or have unexpected
> > > behavior.
> >
> > Can you describe the use of this tool in more detail, and what
> > enhancements it implements beyond what emacsclient provides?  I don't
> > think I understand that from your short description.
> >
> > Thanks.