all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* ediff merge wrapper
@ 2020-11-02 20:01 Eliza Velasquez
  2020-11-03  9:23 ` Daniel Martín
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Eliza Velasquez @ 2020-11-02 20:01 UTC (permalink / raw)
  To: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ediff merge wrapper
  2020-11-02 20:01 ediff merge wrapper Eliza Velasquez
@ 2020-11-03  9:23 ` Daniel Martín
  2020-11-03 16:42 ` chad
  2020-11-03 16:47 ` Eli Zaretskii
  2 siblings, 0 replies; 6+ messages in thread
From: Daniel Martín @ 2020-11-03  9:23 UTC (permalink / raw)
  To: Eliza Velasquez; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ediff merge wrapper
  2020-11-02 20:01 ediff merge wrapper Eliza Velasquez
  2020-11-03  9:23 ` Daniel Martín
@ 2020-11-03 16:42 ` chad
  2020-11-03 16:47 ` Eli Zaretskii
  2 siblings, 0 replies; 6+ messages in thread
From: chad @ 2020-11-03 16:42 UTC (permalink / raw)
  To: Eliza Velasquez; +Cc: emacs-devel

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ediff merge wrapper
  2020-11-02 20:01 ediff merge wrapper Eliza Velasquez
  2020-11-03  9:23 ` Daniel Martín
  2020-11-03 16:42 ` chad
@ 2020-11-03 16:47 ` Eli Zaretskii
  2020-11-03 18:44   ` Eliza Velasquez
  2 siblings, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2020-11-03 16:47 UTC (permalink / raw)
  To: Eliza Velasquez; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ediff merge wrapper
  2020-11-03 16:47 ` Eli Zaretskii
@ 2020-11-03 18:44   ` Eliza Velasquez
  2020-11-05  2:18     ` Eliza Velasquez
  0 siblings, 1 reply; 6+ messages in thread
From: Eliza Velasquez @ 2020-11-03 18:44 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: ediff merge wrapper
  2020-11-03 18:44   ` Eliza Velasquez
@ 2020-11-05  2:18     ` Eliza Velasquez
  0 siblings, 0 replies; 6+ messages in thread
From: Eliza Velasquez @ 2020-11-05  2:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-11-05  2:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-11-02 20:01 ediff merge wrapper Eliza Velasquez
2020-11-03  9:23 ` Daniel Martín
2020-11-03 16:42 ` chad
2020-11-03 16:47 ` Eli Zaretskii
2020-11-03 18:44   ` Eliza Velasquez
2020-11-05  2:18     ` Eliza Velasquez

Code repositories for project(s) associated with this external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.