On osx leopard, I'm getting a blank [y/n] prompt with darcs 2.3, 2.2 but not 
2.1. This broke with the "Make Haskeline a required dependency. " patch in 
february 
(http://joyful.com/darcsweb/darcsweb.cgi?r=darcs-
unstable;a=filediff;h=20090203023400-9f663-
9e79969e0f1ce65fad28587e0182050a9e141c78.gz;f=src/Darcs/Utils.hs). I'll work on 
a fix unless Judah jumps in.

Patch url again: http://tinyurl.com/l2sp7o

The problem is due to running in an emacs shell buffer. haskeline's getInputChar 
misguesses the terminal situation. I'm running gnu emacs 23.1 in the terminal 
app on osx leopard, and echo $TERM reports "dumb". Judah, I think this one is 
for you, let me know if I can tell you any more.

On Thu, Aug 27, 2009 at 02:21:47PM +0000, Simon Michael wrote:
>> On OS X Leopard, I'm getting a blank [y/n] prompt with darcs 2.3
>> [and] 2.2 but not 2.1. This broke with the "Make Haskeline a
>> required dependency. " patch [...]
>
> The problem is due to running in an emacs shell buffer.

Do you mean M-x shell or M-x eshell?

I cannot reproduce this problem in GNU Emacs 23.1.1 on Debian, running
in GNU Screen.  I tried both M-x shell and M-x eshell.

Simon tells me in IRC that it happens specifically in mark-conflicts,
but I cannot work out how to make mark-conflicts prompt me (I don't
have a repo that conflicts handy).

Simon, a transcript of the exact problem would help.

I can look into this; I'll wait until we have a transcript of how to reproduce the 
issue.

Thanks Judah.  Perhaps you could give us that step 1. 2. 3. list, Simon?

Here's the transcript. This was hard to reproduce; it only happens after emacs shell 
buffer gets into a funny input-echoing mode, which it invariably does, for me, after a 
while. I would have taken this to the haskeline tracker, except that I can only 
reproduce it with darcs+haskeline. Judah, I hope this gives some clue.

1. Create conflicting repos and an unrecorded change so mark-conflicts will prompt. I'm 
sure there's an easier way to make darcs prompt.:

/tmp$ darcs init --repo r1; darcs get -q r1 r2 
/tmp$ cd r1; echo 1 >f; darcs add f; darcs record -a -m 'added f'
Finished recording patch 'added f'
/tmp/r1$ cd ../r2; echo 2 >f; darcs add f; darcs record -a -m 'added f'
Finished recording patch 'added f'
/tmp/r2$ darcs pull -a --allow-conflicts ../r1
Pulling from "/private/tmp/r1"...
Backing up ./f(-darcs-backup0)
We have conflicts in the following files:
./f
Finished pulling and applying.
/tmp/r2$ echo >>f
/tmp/r2$ darcs wh -s
M ./f +1

2. Run mark-conflicts in an emacs shell. Normally the prompt works:

/tmp/r2$ darcs mark-conflicts
This will trash any unrecorded changes in the working directory.
Are you sure?  [yn]  C-c C-cwithSignalsHandled: Interrupted!

/tmp$ darcs --version
2.3.0 (release)
/tmp$ emacs --version
GNU Emacs 23.1.1
...
/tmp$ env
TERM_PROGRAM=Apple_Terminal
SHELL=/bin/bash
TERM=dumb
TERM_PROGRAM_VERSION=240.2
EMACSPATH=/Applications/Emacs.app/Contents/MacOS/bin
EMACS=t
TERMCAP=
__CF_USER_TEXT_ENCODING=0x1F5:0:0
PAGER=cat
COLUMNS=89
LANG=en_US.UTF-8
INSIDE_EMACS=23.1.1,comint
...

3. Emacs shell goes into a funny mode after a while; note how each input line is echoed. 
Once this starts, the prompt no longer works, if darcs is built with haskeline:

/tmp/r2$ darcs mark-conflicts
darcs mark-conflicts
 [yn]  C-c C-c                    # <--- no prompt
withSignalsHandled: Interrupted!

/tmp/r2$ darcs2.2 mark-conflicts
darcs2.2 mark-conflicts
 [yn]  C-c C-c
withSignalsHandled: Interrupted!

/tmp/r2$ darcs2.1 mark-conflicts  # pre-haskeline darcs is not affected
darcs2.1 mark-conflicts
This will trash any unrecorded changes in the working directory.
Are you sure?  [yn]  C-c C-cwithSignalsHandled: Interrupted!

4. darcs is using Darcs.Utils.promptCharFancy which uses getInputChar.
But I failed to reproduce the problem with a haskeline test program:

/tmp$ cat test1.hs
cat test1.hs
import System.Console.Haskeline
main = runInputT defaultSettings $ getInputChar "prompt"
  
/tmp$ runhaskell test1.hs
runhaskell test1.hs
prompt  C-c C-c
test1.hs: test1.hs: interrupted

On Sat, Aug 29, 2009 at 02:48:33AM +0000, Simon Michael wrote:
> Here's the transcript. This was hard to reproduce; it only happens
> after emacs shell buffer gets into a funny input-echoing mode

See also comint-process-echoes.  Particularly, ISTR that zsh has that
behaviour by default.

I don't have any ideas about isolating the actual problem, however.

Thanks for the detailed description.  If bash is echoing the input, it's probably 
because the terminal's echoing is set to on.  For bash and haskeline to work 
properly, emacs shell needs to report that echoing is off (which it does by default).

So for a quick fix, when you notice bash acting funny you should run:
stty -echo

Simon, you can also use the stty program to see what the echoing status is.  Can you 
figure out what program is leaving it on?  (If it's darcs, that should be solvable.  
If not, the above workaround may be the best we can do.)

I can reproduce the described behavior after running "stty echo" in emacs shell; I'll 
try to look into why Haskeline is dropping the prompt in this edge case.

Thanks! stty -echo indeed repairs the emacs shell. I'll watch out for what turns 
on echo, in case it's darcs.

And, I confirm the patch you've sent to darcs-users does fix the issue. However 
wouldn't it be better to build that workaround into haskeline ?

The following patch updated the status of issue1578 to be resolved:

* Resolve issue1578: Don't put newlines in the Haskeline prompts. 
Ignore-this: 48a17fb0f45f3aee76aa56361bfd97df

Haskeline doesn't expect to get control characters in its prompt.
The fix is to manually print all but the last line of a prompt message
separately, and then pass the last line as the Haskeline prompt.

So far we've only seen this cause a problem when mark-conflicts is run in
the emacs shell (see the issue for more information).