__color__,__group__,ticket,summary,component,version,milestone,type,owner,status,created,_changetime,_description,_reporter
3,Active Tickets,118,Haskeline install fails on Windows 7,None,,,defect,,new,2012-01-22T01:16:29Z+0000,2012-01-22T01:16:29Z+0000,"'''Log attached'''

Configuring haskeline-0.6.4.6...
Preprocessing library haskeline-0.6.4.6...
System\Console\Haskeline\Directory.hsc:22:20: fatal error: Shlobj.h: No such file or directory
compilation terminated.
compiling dist\build\System\Console\Haskeline\Directory_hsc_make.c failed (exit code 1)
command was: G:\windows\2011.4.0.0\mingw\bin\gcc.exe -c dist\build\System\Console\Haskeline\Directory_hsc_make.c -o dist\build\System\Console\Haskeline\Directory_hsc_make.o -fno-stack-protector -D__GLASGOW_HASKELL__=700 -Dmingw32_BUILD_OS -Dmingw32_HOST_OS -Di386_BUILD_ARCH -Di386_HOST_ARCH -Iincludes -DMINGW -IG:\windows\2011.4.0.0\lib\directory-1.1.0.0\include -IG:\windows\2011.4.0.0\lib\old-time-1.0.0.6\include -IG:\windows\2011.4.0.0\lib\Win32-2.2.0.1\include -IG:\windows\2011.4.0.0\lib\bytestring-0.9.1.10\include -IG:\windows\2011.4.0.0\lib\base-4.3.1.0\include -IG:\windows\2011.4.0.0\lib/include -IG:\windows\2011.4.0.0\lib/include -IG:/windows/2011.4.0.0/lib/include/
Resolving dependencies...
cabal: Error: some packages failed to install:
haskeline-0.6.4.6 failed during the building phase. The exception was:
ExitFailure 1
",guest
3,Active Tickets,123,poor interaction with programs that fork or exec,None,,,defect,,new,2013-01-06T05:39:27Z+0000,2013-04-08T17:53:16Z+0100,"Haskeline under either `defaultBehavior` or `preferTerm` opens `/dev/tty`. If the program then either forks or execs, this file is left open in the new process (for fork), or for the replacing executable (for exec).

Management of open files is a common issue for programs that fork and/or exec. For those files that the program doesn't want to survive past the fork/exec, the usual method is to a) close such files in the child right after forking, and b) set the `FD_CLOEXEC` flag on the file descriptors so they are closed on exec (see '''System.Posix.IO''')

Haskeline doesn't give programs enough leverage to do either of these for the `/dev/tty` file that it opens (and perhaps the history file as well, if that is left open). In forks that aren't expected to interact with the user, `/dev/tty` is left open. This may leave a connection to a particular terminal open well after the terminal is released by by the original process. In execs the situation can lead to a security breach: The program may have arranged for stdin/stdout/stderr to refer to a new terminal or other files before execing. Haskeline's surviving open of `/dev/tty` gives the exec'd program access to the original terminal.

I can see two approaches to fixing this:
 * Offer a way to create a terminal based `Behavior` but on a supplied terminal `Handle` or `Fd`.
 * Expose a way  access the terminal `Handle`s Haskeline is using.

In either case, it is almost certainly wrong for such files to survive an exec, and so Haskeline should ensure that all opened files have had
{{{
    setCloseOnExec :: Fd -> IO ()
    setCloseOnExec fd = setFdOption fd CloseOnExec True
}}}
called on their underlying file descriptors.
",MtnViewMark
3,Active Tickets,124,utf8 test filenames stored in wrong encoding in the git repository,None,,,defect,,new,2013-01-13T13:55:28Z+0000,2013-01-13T14:50:22Z+0000,"The directory and file names used for `tests/Unit.hs:tabcompletion` are stored incorrectly in the haskelline [http://darcs.haskell.org/packages/haskeline.git repo].

Examining the output of
{{{
$ git show ce9035804b88daf29695c1f6c538d91918a4bed5
}}}
shows ''''μασ'''' stored as the sequence ''''C3 8E C2 BC C3 8E C2 B1 C3 8F C2 83'''', whereas the proper UTF-8 sequence is ''''CE BC CE B1 CF 83''''.
Similarly,
{{{
$ git show 3548e16d149a0c35f28238ff36c15f8e905b6163
}}}
has ''''ςερτ'''' stored as ''''C3 8F C2 82 C3 8E C2 B5 C3 8F C2 81 C3 8F C2 84'''' and the correct sequence is ''''CF 82 CE B5 CF 81 CF 84''''.
",nus
3,Active Tickets,99,Define key bindings in terms of commands rather than other keys,None,,,enhancement,judah,assigned,2009-09-15T18:12:54Z+0100,2009-09-15T18:40:42Z+0100,"Right now, haskeline defines key bindings in terms of other keys; this is quite confusing compared to other key binding system which define bindings in terms of particular commands.

For instance, if a user wanted `meta-j` to go back one character, haskeline expects you to define it in terms of `ctrl-b` rather than a command like `backward-char`.  Furthermore, the current system actually changes the meaning of your bindings depending on which binding style you are using; `ctrl-r` may suddenly change meaning from ""search backwards"" to ""redo"" if you switch from emacs to vi style.

It would be much easier to define a non-trivial `~/.haskeline` file like so:
{{{
bind: ctrl-r backward-char
bind: ctrl-s forward-char
bind: ctrl-b backward-search
bind: ctrl-f forward-search
}}}
...than the current case:
{{{
bind: ctrl-r ctrl-b
bind: ctrl-s ctrl-f
bind: ctrl-b ctrl-r
bind: ctrl-f ctrl-s
}}}
It is immediately clear what the former is doing, and not at all clear what the latter is.  I certainly wouldn't want to puzzle out a `~/.haskeline` file with several dozen bindings as the system currently stands.",korpios
4,Active Tickets,9,Finish bell implementation,None,,,defect,,new,2008-06-26T21:33:54Z+0100,2009-01-04T19:14:05Z+0000,"Finish the bell implementation:
 - Get visual/audio bells working on Windows
 - Get visual bell working on some POSIX terminal with the `flash` capability",judah
4,Active Tickets,57,function keys,None,,,defect,,new,2008-12-17T00:58:03Z+0000,2008-12-17T00:58:03Z+0000,The POSIX and Windows backends should be able to recognize function keys.,judah
4,Active Tickets,60,Experiment with Windows PowerShell,None,,,defect,,new,2009-01-04T19:24:07Z+0000,2009-01-04T19:24:07Z+0000,Check out the new Windows `PowerShell`.  Do commands still work as expected?  Is it easier/harder to get CJK and other foreign languages working?,judah
4,Active Tickets,65,Unicode input in cygwin shell,None,,,defect,,new,2009-01-04T21:48:31Z+0000,2011-09-30T06:39:55Z+0100,Unicode input in the Cygwin shell probably won't work because we're encoding in a Windows code page.,judah
4,Active Tickets,96,Meta not recognized,None,,,defect,,new,2009-07-06T17:55:08Z+0100,2009-07-06T23:28:07Z+0100,"When running in an xterm, haskeline does not seem to recognize my Meta key.  It does recognize it when running in an ordinary text-mode console.
",viritrilbia
4,Active Tickets,114,does not play well with minTTY on windows,None,,,defect,,new,2011-09-29T17:02:11Z+0100,2011-09-30T06:37:52Z+0100,"Haskeline, at least when baked into a Windows-native build of ghc, appears not to work well with the minTTY terminal emulator.  Neither the arrow keys, nor vi key bindings do anything useful - they simply corrupt the buffer being passed to the underlying program by adding odd non-printable characters.

I think the cause is similar to the reason that Windows-native Python does not work interactively in minTTY without special options.  To quote http://code.google.com/p/mintty/issues/detail?id=56

""This is due to MinTTY being based on Cygwin pty's, which do not play well with Windows console apps. [...] basically it's because the pty emulation is based on pipes, which means that a Win32 application running in MinTTY sees a pipe rather than a console as its input, so it behaves differently.""

For instance, the _isatty() call will return False when run inside minTTY.  The webpage goes into some more details, but I think the main problem is that Windows-native (rather than Cygwin) programs have no API available to them to manipulate a ""pseudo terminal"".

I'm not certain the issue is fixable in Haskeline, but thought it worth noting, even if only for googleability.",malcolmw
4,Active Tickets,122,Semicolon to repeat 'f' search in Vi-mode,None,,,defect,,new,2012-10-25T01:39:33Z+0100,2012-10-25T01:39:33Z+0100,"In readline vi-mode, semicolon repeats the last 'f' or 'F' search for a character within a line.  Seems to be missing from haskeline.",guest
4,Active Tickets,45,System-level user preferences,None,,,enhancement,,new,2008-11-10T23:29:14Z+0000,2008-12-08T17:16:18Z+0000,"Have a standard location where a global preferences file for all users may be located.  (For example, readline uses /etc/inputrc along with the INPUTRC environmental variable.)

This will become more useful when #10 (custom key bindings) is implemented.",judah
4,Active Tickets,68,don't require nl_langinfo(CODESET),None,,,enhancement,,new,2009-01-05T18:37:18Z+0000,2009-01-05T22:23:54Z+0000,"To get the locale encoding on POSIX we currently use {{{nl_langinfo(CODESET)}}}.  There may be some systems on which this is not available.  

This is low-priority unless anyone complains, since I'm not aware of a specific OS on which ghc runs that has this issue. ",judah
4,Active Tickets,112,Multi-line prompt,None,,,enhancement,,new,2010-10-15T16:22:32Z+0100,2012-07-13T21:32:18Z+0100,"For ghci, it would be useful to have a mode which lets the user edit multiple lines at once.  See:

http://hackage.haskell.org/trac/ghc/ticket/3984

http://hackage.haskell.org/trac/ghc/ticket/4316",judah
4,Active Tickets,120,Expose Prefs programmatically,None,,,enhancement,,new,2012-07-13T21:01:35Z+0100,2012-07-19T02:15:53Z+0100,"Currently, the constructors for the Prefs record are opaque. Therefore, if a client application wishes to programmatically set non-default preferences, the only safe way is to write out a temp file in the .haskeline format, then read it back in. 

It would be much simpler to either expose the constructors, or provide an API for changing the settings directly. I notice that older versions exposed this module, so perhaps there is a reason for keeping the actual constructors hidden while exposing enough to client code.",acfoltzer
4,Active Tickets,64,Write a testing program for encodings,None,,,task,,new,2009-01-04T21:47:20Z+0000,2009-01-04T21:47:20Z+0000,"Write an example, test program to test out console encodings.  May be useful for debugging user issues.",judah
4,Active Tickets,63,Multiword UTF-16 code points aren't handled correctly on Windows,None,,0.6.*,defect,,new,2009-01-04T20:57:45Z+0000,2009-01-04T21:44:44Z+0000,"Multiword UTF-16 code points aren't handled correctly:
 - The custom marshalling code in Win32.hs probably doesn't do it correctly
 - CWStringLen bug (ghc trac [http://hackage.haskell.org/trac/ghc/ticket/2903 #2903])
 - ReadConsoleInputA may only be accepting one word.

This is hard for me to test, and I'm not sure how many multiword inputs can be obtained from the console anyway.",judah
4,Active Tickets,59,username completion function,None,,0.6.*,enhancement,,new,2008-12-17T05:32:21Z+0000,2009-01-04T19:13:14Z+0000,"Provide a username completion function which is platform-independent.

On POSIX, we can use `System.Posix.User.getAllUserEntries`.  I'm not sure what the right thing is to do on Windows.

This can also probably be used to enhance the filename completion (so that e.g. `~judah/` is completed correctly).",judah
4,Active Tickets,67,Clean up Posix monad transformers.,None,,0.6.*,task,,new,2009-01-04T22:02:07Z+0000,2009-01-11T07:14:20Z+0000,"Clean up the code around `PosixT`.

While I'm at it, remove this warning:
{{{
System/Console/Haskeline/Backend/Posix.hsc:255:0:
    Warning: Definition but no type signature for `runPosixT'
             Inferred type: runPosixT :: forall r (m :: * -> *) r1 a.
                                         (Monad m) =>
                                         r1 -> r -> ReaderT r1 (ReaderT r m) a -> m a
}}}",judah
4,Active Tickets,69,Check the correct behavior for win32 code pages,None,,0.6.*,task,,new,2009-01-11T06:45:09Z+0000,2009-01-11T06:46:15Z+0000,"Should the Win32 code page be initialized once per `RunTerm`, or should it be queried each time a conversion is about to be made? ",judah
4,Active Tickets,12,Better internal documentation,None,0.1,,defect,,new,2008-06-26T22:05:25Z+0100,2008-06-26T22:05:25Z+0100,The internal modules could definitely be documented better than they are now.,judah
4,Active Tickets,2,Allow fallbacks for getting the terminal size on POSIX,None,0.1,,enhancement,,new,2008-06-26T19:53:55Z+0100,2009-01-05T22:24:21Z+0000,"Currently, the POSIX backend requires TIOCGWINSZ for ioctl to get the terminal size.  On systems which don't have that, we should fall back to either:
 - Use the terminfo capabilities {{{termlines/termColumns}}}
 - Use the environmental variables {{{LINES/COLUMNS}}}
 - Default to 80x24 if the above aren't defined, or if they're bad values (negative or too small)

This will require some configure-time hacks, though, so before I implement this I'll need to see a machine that actually doesn't provide TIOCGWINSZ (preferably one that I can test on).",judah
4,Active Tickets,4,Improve dumb terminal interface,None,0.1,,enhancement,,new,2008-06-26T19:59:47Z+0100,2008-06-26T19:59:47Z+0100,"The dumb terminal interface works, but is not that pretty.  In particular, we only scroll the line if the cursor is about to move off of the screen.  Readline has a margin of about 1/3 the width which causes a scroll when the cursor enters it; we could do something similar.",judah
4,Active Tickets,6,Add testsuite,None,0.1,,enhancement,,new,2008-06-26T20:21:49Z+0100,2008-12-17T05:49:43Z+0000,"Use some tools to automate the testing:
 - Like XMonad, we could use !QuickCheck to test the pure core
 - Automate running commands on the test program and making sure that it outputs correctly to the terminal.",judah
4,Active Tickets,7,Optimize the terminfo control sequences,None,0.1,,enhancement,,new,2008-06-26T20:32:27Z+0100,2008-06-26T20:32:27Z+0100,"It might be worth looking at the control sequences that are being outputted by the terminfo and dumb backends, and checking whether any optimizations could be made.  For example, we could use `carriageReturn` instead of `moveLeft` or multiple {{{`\b`}}}s.

",judah
4,Active Tickets,17,Generate window resize events on Win32,None,0.1,,enhancement,,new,2008-06-26T22:54:39Z+0100,2008-12-10T21:05:29Z+0000,"The Win32 backend should handle window resize events.

The blocker for this is that I can't get the Win32 console to produce an `INPUT_RECORD` whose `EventType` is `WINDOW_BUFFER_SIZE_EVENT`, so I haven't been able to test my changes.",judah
4,Active Tickets,1,Support Cygwin,None,0.1,,task,,new,2008-06-26T19:41:07Z+0100,2010-08-24T01:30:55Z+0100,"Currently the Windows/POSIX choice is an either/or choice at configure time.  That doesn't make sense for systems with Cygwin.  

The best would be to choose a `RunTerm` at runtime based on whether the program is being run under a POSIX terminal or the Win32 console.  I'm not sure whether that's feasible.",judah
4,Active Tickets,38,More complicated languages,None,0.3,,enhancement,,new,2008-09-18T07:25:25Z+0100,2008-09-18T07:25:25Z+0100,"Although we do support the display of arbitrary Unicode characters, I'm pretty sure that the user interaction in languages like Hebrew or Japanese aren't going to work completely right without some explicit effort on their behalf.  

",judah
3,Active Tickets,90,vi mode printable char bindings should not be bound in input mode,None,0.6,,defect,,new,2009-06-11T04:03:29Z+0100,2012-08-09T14:15:32Z+0100,"This `~/.haskelline` file:

    editMode: Vi
    bind: k up
    bind: j down

behaves in a rather unfortunate way for vi users. As well as binding `h` and `j` in command mode, it also binds them in input mode, meaning that one can no longer input a `k` or a `j`.

Ideally one would specify, for vi bindings, whether they were for command mode or input mode. However, this requires changing the format of the configuration file, possibly making it rather more complex.

My proposal is that, for the moment anyway, `bind` when used with printable characters should rebind keys for command mode only, not affecting their use in input mode.",cjs
3,Active Tickets,81,haskeline assumes all characters have width = 1,None,0.6,0.6.*,defect,,reopened,2009-05-16T13:36:49Z+0100,2010-12-07T05:01:17Z+0000,"haskeline's input editing assumes all characters have a width of 1. The display and cursor positioning code messes up if that assumption doesn't hold, e.g. for double-wide (width = 2) or combining characters (width = 0).",guest
3,Active Tickets,74,Haskeline can't link against MacPorts' libiconv,None,0.6,0.7,defect,,new,2009-02-01T19:06:25Z+0000,2009-02-06T20:22:46Z+0000,"On OS X, the following fails (where Test.hs is from the examples folder):
{{{
$ ghc --make Test.hs -L/opt/local/lib -I/opt/local/include -fforce-recomp
[1 of 1] Compiling Main             ( test.hs, test.o )
Linking test ...
Undefined symbols:
  ""_iconv_open"", referenced from:
      _s2e5_info in libHShaskeline-0.6.0.1.a(IConv.o)
  ""_iconv_close"", referenced from:
      _iconv_close$non_lazy_ptr in libHShaskeline-0.6.0.1.a(IConv.o)
  ""_iconv"", referenced from:
      _s2oc_info in libHShaskeline-0.6.0.1.a(IConv.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status

}}}

Reported by Antoine Latter.  

The problem is that !MacPorts' iconv typedefs the iconv functions rather than defining them directly.  This will affect any program linking against a library in !MacPorts, even if it intends to use the OS X system libiconv.",judah
4,Active Tickets,79,Emacs and haskeline (or GHCi) do not interact very well,None,0.6,,defect,judah,new,2009-05-13T22:13:31Z+0100,2012-11-19T10:01:01Z+0000,"Start Emacs, run M-x shell, start GHCi 6.10.3 (which uses haskeline),
and paste the output of {{{replicate 252 'x'}}} into the GHCi prompt. I
get the following result:
{{{
<interactive>:1:254: lexical error at character '\EOT'
}}}

The problem seems to be that Emacs does not send all of the input at
once:
  If STRING is more than 500 characters long, it is sent in several
  bunches. This may happen even for shorter strings.
(From the documentation of process-send-string in GNU Emacs 23.0.93.1.) See also the following message: http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15591/focus=15632.

I do not know whether this is a problem in Emacs, GHCi or Haskeline,
but it breaks the Agda Emacs mode (which communicates with a Haskell
backend via GHCi). Even if this problem is fixed right away I expect
to have to wait for a while before the next version of GHCi is
released. Is there a known (simple) workaround for the problem?
",nad
4,Active Tickets,89,Use Unicode-compliant case conversion,None,0.6,,defect,,new,2009-06-08T16:48:13Z+0100,2009-06-08T16:48:13Z+0100,"See for example http://www.serpentine.com/blog/2009/06/07/case-conversion-and-text-03/ .  

Probably this can wait until ghc-6.12 when we will (hopefully) depend on a Unicode-compliant library like `text`.",judah
4,Active Tickets,82,Custom key actions written in Haskell,None,0.6,,enhancement,,new,2009-05-16T13:51:04Z+0100,2009-05-16T16:53:34Z+0100,"My ~/.inputrc maps <up> and <down> to history-search-backward and history-search-forward in programs that use readline. This functionality is simply not available in haskeline. If it was, I couldn't bind it to <up>/<down> because as far as I can see haskeline only offers vi-style key remapping, not binding to input editing functions. There also doesn't seem to be a way to add actions from Haskell; getInputLine is a black box without hooks.

So what I want right now is history-search-backward/forward but I also think there should be a comprehensive set of bindable line editing functions and a way to define new functions in Haskell.",guest
4,Active Tickets,93,Add case-insensitive completion option,None,0.6,,enhancement,,new,2009-06-23T04:46:08Z+0100,2009-06-23T04:46:08Z+0100,"Add a `completionCaseInsensitive` option for `~/.haskeline` that defaults to `False`. If set instead to `True`, asking to complete ""fo"" would match both ""foo"" and ""Foo"".",cjs
4,Active Tickets,91,figure out how readline intercepts ctrl-y,None,0.6,,task,,new,2009-06-12T17:30:03Z+0100,2009-06-12T17:30:03Z+0100,"On my machine, by default {{{dsusp=^Y}}} which causes the emacs yank command not to work.  However, for some reason it does work in readline.

Figure out why that is, and decide whether it's something Haskeline should try to emulate.",judah
4,Active Tickets,77,keypad keys,None,0.6,0.6.2,enhancement,,new,2009-02-27T07:49:02Z+0000,2009-06-01T21:39:59Z+0100,"Recognize the keypad keys.

The issue is that we send a ""keypad on"" control sequence which makes the keypad emit strange control sequences; I guess they're standard on VT100-like terminals but not recorded in the xterm-* terminfo entries.",judah