The current behaviour of darcs record --edit and darcs send --edit on
Windows is suboptimal.  Paraphrasing an (old) post to darcs-users from
Max Battcher:

Darcs starts an external editor process using a standard shell-style
invocation.  This is fine for a tty editor like vi or edit, but a GUI
editor will typically do one of two things:

  1. show a pop-up dialog: "this is a Win32 application" and exit.

  2. fork a new editor process in the background, then exit.

To know when the user is done editing, Darcs waits for the process it
launched to exit.  In case (2) this happens immediately, so Darcs
doesn't "see" the real editor process.

There are Win32 APIs for executing GUI apps and waiting for them.
Someone should investigate if an existing Haskell package provides a
suitable wrapper for them, and if it is worth using them in Darcs.

There is also a wrapper command for these APIs called "start", similar
to open(1) on OS X.  Perhaps the documentation should mention

  If setting %DARCS_EDITOR% to "foo" doesn't work, try setting it to
  "start /wait foo".

If Darcs created temporary files with the appropriate extension
(e.g. .txt), the "foo" part could be ommitted, and this approach could
be the default on Windows.  That would mean that users would get their
preferred editor (as defined by the .txt association in Explorer) out of
the box.

Would it be simpler just to tell everybody to use such wrappers and be done with it?

Also: darcs puts an explicit 'press Enter to continue' in darcs diff and also
when calling the external resolver.  It sounds like we could do away with those
if we do things right, no?

On Thu, Aug 06, 2009 at 01:59:57PM +0000, Eric Kow wrote:
> Also: darcs puts an explicit 'press Enter to continue' in darcs diff
> and also when calling the external resolver.  It sounds like we
> could do away with those if we do things right, no?

The external merge workflow definitely needs analysis, but that has
separate tickets.  Looking only at open tickets I created:

  issue1201 dir-wide external merge utility
  issue1219 External merge with deletion
  issue1228 optionally disable 'Hit return to move on' in --diff-command and --external-merge

Hi Esa, could I just check if your Win32 package could be used here?
Thanks! 

For the interested, http://hackage.haskell.org/package/Win32

[I'm "assigning" this to you for tracking purposes only; it lets us know
who to chase up on the next time we look at this bug]

Hmmm.  I don't know about such a package.  And I am not sure you'll get
much better behaviour with any solution.  Waiting for GUI apps won't
work for most "mature" or "programmer" editors - they are single
instance.  Except with right commandline options.  That's the 2. in
first post.  I guess 1. would be caused sometimes by old applications or
applications that use different entry point (two programs in one file
really) for console and gui.

For executing gui app, you'll might want as a workaround option (most
gui apps should run just normally from commandline) the
dont-inherit-console flag for CreateProcess.  If you don't need pipes,
CreateProcess isn't all that bad to use.  But YMMV, I am not even sure I
understand what all this issue is for.

On Tue, Apr 13, 2010 at 7:31 AM, Esa Ilari Vuokko <bugs@darcs.net> wrote:
>
> Esa Ilari Vuokko <ei@vuokko.info> added the comment:
>
> Hmmm.  I don't know about such a package.  And I am not sure you'll get
> much better behaviour with any solution.  Waiting for GUI apps won't
> work for most "mature" or "programmer" editors - they are single
> instance.  Except with right commandline options.  That's the 2. in
> first post.  I guess 1. would be caused sometimes by old applications or
> applications that use different entry point (two programs in one file
> really) for console and gui.

I think that we should solve it at "documentation" level, as it
provides maximum flexibility with minimum effort.

Actually on Windows not all editors behave the same way, e.g.
Notepad++ automatically waits, and you have to use "start" to make it
run in background. In some other cases it's the opposite.

As far as I know, there's no native "editor" API on Windows, just
filename associations.

My (controversial) suggestion: make write.exe the default editor on
Windows, and document the "start" behavior in the manual. Notepad.exe
is not a good choice, as it doesn't interpret correctly unix end of
lines.

Maybe we should discuss it on the mailing list.

Salvatore Insalaco wrote:
> My (controversial) suggestion: make write.exe the default editor on
> Windows, and document the "start" behavior in the
> manual. Notepad.exe is not a good choice, as it doesn't interpret
> correctly unix end of lines.

When I'm on Windows I use WORDPAD instead of NOTEPAD for that reason.
As we only support NT5.0 (Windows 2000) onwards, that should be available.

On Tue, Apr 13, 2010 at 8:46 AM, Trent W. Buck <bugs@darcs.net> wrote:
> Salvatore Insalaco wrote:
>> My (controversial) suggestion: make write.exe the default editor on
>> Windows, and document the "start" behavior in the
>> manual. Notepad.exe is not a good choice, as it doesn't interpret
>> correctly unix end of lines.
>
> When I'm on Windows I use WORDPAD instead of NOTEPAD for that reason.
> As we only support NT5.0 (Windows 2000) onwards, that should be available.

Just to clarify: write.exe is WordPad on NT5 onwards.

2010/4/13 Trent W. Buck <bugs@darcs.net>:
> Trent W. Buck <trentbuck@gmail.com> added the comment:
> Salvatore Insalaco wrote:
>> My (controversial) suggestion: make write.exe the default editor on
>> Windows, and document the "start" behavior in the
>> manual. Notepad.exe is not a good choice, as it doesn't interpret
>> correctly unix end of lines.
>
> When I'm on Windows I use WORDPAD instead of NOTEPAD for that reason.
> As we only support NT5.0 (Windows 2000) onwards, that should be available.

write.exe = WordPad. I recall that in Windows 3.1, it was also called
"Write" in the menus, but they changed it to WordPad in Windows 95
without changing the executable name.

Reinier

Following does make sense to me (repeating what was said). Functionality
to (via options): 
 1. Wait for editor process,.
 2. or wait for user to tell they've stopped editing.
 3. Run (editor) programs with or with-out inherited console.

And setting defaults to:
 4. Use write.exe out of the box.
 5. Document the behavior and options, as well as short rationale.

As for editor API, I am not sure what you mean.  $EDITOR?  There
certainly is API/Guidelines how to run programs based on mime or file
associations using the extension.  DDE might be usable, but I don't know
if there's convention for it.  As an idea, I'd also suggest following
(as an option): Put the stuff on clipboard.  Watch for clipboard and
when it changes, print it or start of it and ask user if that's the
message he or she would like.

Pending outcome of discussion at
http://lists.osuosl.org/pipermail/darcs-users/2010-April/023648.html

Ganesh, is this still a problem in Windows?

Yes, from a quick experiment it's still a problem.

Personally I always use a tty-style editor.