[darcs-users] how to launch text editor on Windows?

Eric Kow kowey at darcs.net
Tue Apr 13 08:54:46 UTC 2010

Hi all,

This is the continuation of http://bugs.darcs.net/issue1463

I didn't follow all this, but it looks like there is a consensus to
default to write.exe (aka WordPad) [but not NotePad because it does not
understand Unix line endings].

For background, here is the current runEditor function:

runEditor :: FilePath -> IO ExitCode
runEditor f = do
  ed <- getEditor
  execInteractive ed f
       `ortryrunning` execInteractive "emacs" f
       `ortryrunning` execInteractive "emacs -nw" f
       `ortryrunning` execInteractive "nano" f
#ifdef WIN32
       `ortryrunning` execInteractive "edit" f

For context, here is an extract cherry picking three messages from the

Trent Buck (msg7827) opened the bug with:
| 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.
Salvatore Insalaco later wrote (msg10708):
> 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.

Yep. :-)
Keeps the bug-tracker focused and gives us more chance for input.

Esa Ilari Vuokko <ei at vuokko.info> (msg10712) said:
| 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.

I'd rather avoid flag (or config) proliferation if there is a sensible
way to do so (which there may not be; let's see...)

Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20100413/2b803d52/attachment.pgp>

More information about the darcs-users mailing list