When "apply interactive" is in ~/.darcs/defaults, patches cannot be
read from standard input.  This breaks workflows in e.g. mutt.

It might seem counterintuitive to have "two" input streams, but
clearly something like this can be implemented, because less(1) does
it.  For example, "dmesg | less" will let you scroll up and down,
which presumably is reading the arrow keypresses from stdin.

Hi Judah,

If I understand our email thread correctly, we came to the conclusion that this
would be a neat thing to be able to do with Haskeline (read from /dev/tty if
stdin is not a terminal).  So I'd like to assign this to you as a darcs UI bug
to fix (using potentially a new Haskeline feature :-D).

Thanks!

Email thread is here:
http://lists.osuosl.org/pipermail/darcs-users/2009-October/021861.html

Just noting that we revisited this during the 2010-03 sprint in Zurich.

Our conclusion was that before we need to research the problem more, and
determine if there was a portable way to reliably detect if we were on a
terminal or not.  Windows may be an issue here.

If there is one, we can re-open the discussion about how apply -i should
behave.

Judah: any chance you'd be able to look into this?

Eric Kow wrote:
> Our conclusion was that before we need to research the problem more,
> and determine if there was a portable way to reliably detect if we
> were on a terminal or not.  Windows may be an issue here.

Is it allowed to improve behavour on Unix and not Windows, as long as
it doesn't make behaviour on Windows *worse* than it currently is?

On Mon, Mar 22, 2010 at 13:14:20 +0000, Trent W. Buck wrote:
> Is it allowed to improve behavour on Unix and not Windows, as long as
> it doesn't make behaviour on Windows *worse* than it currently is?

My 0.20 CHF: only if it does not lead to great divergence in the UI
(which this may not).

Example divergence: in Windows, users have to hit enter after
interactive selection...

I'd like things to be as consistent/predictable across platforms as
possible

-- 
Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow>
PGP Key ID: 08AC04F9

On Mon, Mar 22, 2010 at 5:45 AM, Eric Kow <bugs@darcs.net> wrote:
>
> Our conclusion was that before we need to research the problem more, and
> determine if there was a portable way to reliably detect if we were on a
> terminal or not.  Windows may be an issue here.
>
> If there is one, we can re-open the discussion about how apply -i should
> behave.
>
> Judah: any chance you'd be able to look into this?

Sure.  There's a Windows equivalent to /dev/tty ("CONIN$" and
"CONOUT$"); Haskeline already uses the latter but not yet the former.
I did some tests, and trying to open CONIN looks like a reliable way
to check whether we're in a console session.*

So I believe there's no technical barriers to a robust
terminal-checking in the backend of Haskeline.  The best approach
seems to me to add a function to Haskeline's API.  For example:

runInputTInTerm :: Settings m -> InputT m a -> m (Maybe a)

which tries to run the given action(s) using the terminal, even if
it's not stdin; and returns Nothing if it couldn't connect to
[/dev/tty,CONIN$].  This should give Darcs some flexibility in
deciding the exact semantics of apply -i.


*The one caveat: in a Cygwin X shell, we can't connect to CONIN.  But
Haskeline doesn't provide any interactive editing in that setting
anyway, so this seems OK to me.  (There's little I can do about that
unless GHC improves its Cygwin support.)

Thanks! It looks like the right thing to do for this bug is to wait for
a new version of Haskeline to come out with terminal detection.

Haskeline 0.6.3 has been released to Hackage and should have the necessary 
functionality:
http://hackage.haskell.org/packages/archive/haskeline/0.6.3/doc/html/System-
Console-Haskeline.html

Specifically, "runInputTBehavior preferTerm" will attempt to connect to the 
user's terminal for input instead of using stdin.  (The action "haveTerminalUI" 
can be used to check whether that was successful.)  

Hopefully the haddock docs are helpful enough for someone to implement this 
ticket, but let me know if there's any questions.

There's a patch in development for this: patch567

The patch to fix this was rejected because it makes apply behave 
specially. I think it is not worth to pursue this.