haskeline: http://trac.haskell.org/haskeline/report/1
Trac Report - en-ushaskelinehttp://trac.haskell.org/haskeline/chrome/common/trac_banner.pnghttp://trac.haskell.org/haskeline/report/1
Trac v0.11.1#1: Support CygwinThu, 26 Jun 2008 18:41:07 GMTTue, 24 Aug 2010 00:30:55 GMT<p>
Currently the Windows/POSIX choice is an either/or choice at configure time. That doesn't make sense for systems with Cygwin.
</p>
<p>
The best would be to choose a <tt>RunTerm</tt> 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.
</p>
http://trac.haskell.org/haskeline/ticket/1
http://trac.haskell.org/haskeline/ticket/1Report#2: Allow fallbacks for getting the terminal size on POSIXThu, 26 Jun 2008 18:53:55 GMTMon, 05 Jan 2009 22:24:21 GMT<p>
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:
</p>
<ul><li>Use the terminfo capabilities <tt>termlines/termColumns</tt>
</li><li>Use the environmental variables <tt>LINES/COLUMNS</tt>
</li><li>Default to 80x24 if the above aren't defined, or if they're bad values (negative or too small)
</li></ul><p>
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).
</p>
http://trac.haskell.org/haskeline/ticket/2
http://trac.haskell.org/haskeline/ticket/2Report#4: Improve dumb terminal interfaceThu, 26 Jun 2008 18:59:47 GMTThu, 26 Jun 2008 18:59:47 GMT<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/4
http://trac.haskell.org/haskeline/ticket/4Report#6: Add testsuiteThu, 26 Jun 2008 19:21:49 GMTWed, 17 Dec 2008 05:49:43 GMT<p>
Use some tools to automate the testing:
</p>
<ul><li>Like XMonad, we could use QuickCheck to test the pure core
</li><li>Automate running commands on the test program and making sure that it outputs correctly to the terminal.
</li></ul>http://trac.haskell.org/haskeline/ticket/6
http://trac.haskell.org/haskeline/ticket/6Report#7: Optimize the terminfo control sequencesThu, 26 Jun 2008 19:32:27 GMTThu, 26 Jun 2008 19:32:27 GMT<p>
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 <tt>carriageReturn</tt> instead of <tt>moveLeft</tt> or multiple <tt>`\b`</tt>s.
</p>
http://trac.haskell.org/haskeline/ticket/7
http://trac.haskell.org/haskeline/ticket/7Report#9: Finish bell implementationThu, 26 Jun 2008 20:33:54 GMTSun, 04 Jan 2009 19:14:05 GMT<p>
Finish the bell implementation:
</p>
<ul><li>Get visual/audio bells working on Windows
</li><li>Get visual bell working on some POSIX terminal with the <tt>flash</tt> capability
</li></ul>http://trac.haskell.org/haskeline/ticket/9
http://trac.haskell.org/haskeline/ticket/9Report#12: Better internal documentationThu, 26 Jun 2008 21:05:25 GMTThu, 26 Jun 2008 21:05:25 GMT<p>
The internal modules could definitely be documented better than they are now.
</p>
http://trac.haskell.org/haskeline/ticket/12
http://trac.haskell.org/haskeline/ticket/12Report#17: Generate window resize events on Win32Thu, 26 Jun 2008 21:54:39 GMTWed, 10 Dec 2008 21:05:29 GMT<p>
The Win32 backend should handle window resize events.
</p>
<p>
The blocker for this is that I can't get the Win32 console to produce an <tt>INPUT_RECORD</tt> whose <tt>EventType</tt> is <tt>WINDOW_BUFFER_SIZE_EVENT</tt>, so I haven't been able to test my changes.
</p>
http://trac.haskell.org/haskeline/ticket/17
http://trac.haskell.org/haskeline/ticket/17Report#38: More complicated languagesThu, 18 Sep 2008 06:25:25 GMTThu, 18 Sep 2008 06:25:25 GMT<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/38
http://trac.haskell.org/haskeline/ticket/38Report#45: System-level user preferencesMon, 10 Nov 2008 23:29:14 GMTMon, 08 Dec 2008 17:16:18 GMT<p>
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.)
</p>
<p>
This will become more useful when <a class="closed ticket" href="http://trac.haskell.org/haskeline/ticket/10" title="enhancement: Custom key bindings (closed: fixed)">#10</a> (custom key bindings) is implemented.
</p>
http://trac.haskell.org/haskeline/ticket/45
http://trac.haskell.org/haskeline/ticket/45Report#57: function keysWed, 17 Dec 2008 00:58:03 GMTWed, 17 Dec 2008 00:58:03 GMT<p>
The POSIX and Windows backends should be able to recognize function keys.
</p>
http://trac.haskell.org/haskeline/ticket/57
http://trac.haskell.org/haskeline/ticket/57Report#59: username completion functionWed, 17 Dec 2008 05:32:21 GMTSun, 04 Jan 2009 19:13:14 GMT<p>
Provide a username completion function which is platform-independent.
</p>
<p>
On POSIX, we can use <tt>System.Posix.User.getAllUserEntries</tt>. I'm not sure what the right thing is to do on Windows.
</p>
<p>
This can also probably be used to enhance the filename completion (so that e.g. <tt>~judah/</tt> is completed correctly).
</p>
http://trac.haskell.org/haskeline/ticket/59
http://trac.haskell.org/haskeline/ticket/59Report#60: Experiment with Windows PowerShellSun, 04 Jan 2009 19:24:07 GMTSun, 04 Jan 2009 19:24:07 GMT<p>
Check out the new Windows <tt>PowerShell</tt>. Do commands still work as expected? Is it easier/harder to get CJK and other foreign languages working?
</p>
http://trac.haskell.org/haskeline/ticket/60
http://trac.haskell.org/haskeline/ticket/60Report#63: Multiword UTF-16 code points aren't handled correctly on WindowsSun, 04 Jan 2009 20:57:45 GMTSun, 04 Jan 2009 21:44:44 GMT<p>
Multiword UTF-16 code points aren't handled correctly:
</p>
<ul><li>The custom marshalling code in Win32.hs probably doesn't do it correctly
</li><li>CWStringLen bug (ghc trac <a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/2903"><span class="icon">#2903</span></a>)
</li><li>ReadConsoleInputA may only be accepting one word.
</li></ul><p>
This is hard for me to test, and I'm not sure how many multiword inputs can be obtained from the console anyway.
</p>
http://trac.haskell.org/haskeline/ticket/63
http://trac.haskell.org/haskeline/ticket/63Report#64: Write a testing program for encodingsSun, 04 Jan 2009 21:47:20 GMTSun, 04 Jan 2009 21:47:20 GMT<p>
Write an example, test program to test out console encodings. May be useful for debugging user issues.
</p>
http://trac.haskell.org/haskeline/ticket/64
http://trac.haskell.org/haskeline/ticket/64Report#65: Unicode input in cygwin shellSun, 04 Jan 2009 21:48:31 GMTFri, 30 Sep 2011 05:39:55 GMT<p>
Unicode input in the Cygwin shell probably won't work because we're encoding in a Windows code page.
</p>
http://trac.haskell.org/haskeline/ticket/65
http://trac.haskell.org/haskeline/ticket/65Report#67: Clean up Posix monad transformers.Sun, 04 Jan 2009 22:02:07 GMTSun, 11 Jan 2009 07:14:20 GMT<p>
Clean up the code around <tt>PosixT</tt>.
</p>
<p>
While I'm at it, remove this warning:
</p>
<pre class="wiki">System/Console/Haskeline/Backend/Posix.hsc:255:0:
Warning: Definition but no type signature for `runPosixT'
Inferred type: runPosixT :: forall r (m :: * -&gt; *) r1 a.
(Monad m) =&gt;
r1 -&gt; r -&gt; ReaderT r1 (ReaderT r m) a -&gt; m a
</pre>http://trac.haskell.org/haskeline/ticket/67
http://trac.haskell.org/haskeline/ticket/67Report#68: don't require nl_langinfo(CODESET)Mon, 05 Jan 2009 18:37:18 GMTMon, 05 Jan 2009 22:23:54 GMT<p>
To get the locale encoding on POSIX we currently use <tt>nl_langinfo(CODESET)</tt>. There may be some systems on which this is not available.
</p>
<p>
This is low-priority unless anyone complains, since I'm not aware of a specific OS on which ghc runs that has this issue.
</p>
http://trac.haskell.org/haskeline/ticket/68
http://trac.haskell.org/haskeline/ticket/68Report#69: Check the correct behavior for win32 code pagesSun, 11 Jan 2009 06:45:09 GMTSun, 11 Jan 2009 06:46:15 GMT<p>
Should the Win32 code page be initialized once per <tt>RunTerm</tt>, or should it be queried each time a conversion is about to be made?
</p>
http://trac.haskell.org/haskeline/ticket/69
http://trac.haskell.org/haskeline/ticket/69Report#74: Haskeline can't link against MacPorts' libiconvSun, 01 Feb 2009 19:06:25 GMTFri, 06 Feb 2009 20:22:46 GMT<p>
On OS X, the following fails (where Test.hs is from the examples folder):
</p>
<pre class="wiki">$ 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
</pre><p>
Reported by Antoine Latter.
</p>
<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/74
http://trac.haskell.org/haskeline/ticket/74Report#77: keypad keysFri, 27 Feb 2009 07:49:02 GMTMon, 01 Jun 2009 20:39:59 GMT<p>
Recognize the keypad keys.
</p>
<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/77
http://trac.haskell.org/haskeline/ticket/77Report#79: Emacs and haskeline (or GHCi) do not interact very wellWed, 13 May 2009 21:13:31 GMTMon, 19 Nov 2012 10:01:01 GMT<p>
Start Emacs, run M-x shell, start GHCi 6.10.3 (which uses haskeline),
and paste the output of <tt>replicate 252 'x'</tt> into the GHCi prompt. I
get the following result:
</p>
<pre class="wiki">&lt;interactive&gt;:1:254: lexical error at character '\EOT'
</pre><p>
The problem seems to be that Emacs does not send all of the input at
once:
</p>
<blockquote>
<p>
If STRING is more than 500 characters long, it is sent in several
bunches. This may happen even for shorter strings.
</p>
</blockquote>
<p>
(From the documentation of process-send-string in GNU Emacs 23.0.93.1.) See also the following message: <a class="ext-link" href="http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15591/focus=15632"><span class="icon">http://thread.gmane.org/gmane.comp.lang.haskell.glasgow.user/15591/focus=15632</span></a>.
</p>
<p>
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?
</p>
http://trac.haskell.org/haskeline/ticket/79
http://trac.haskell.org/haskeline/ticket/79Report#81: haskeline assumes all characters have width = 1Sat, 16 May 2009 12:36:49 GMTTue, 07 Dec 2010 05:01:17 GMT<p>
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).
</p>
http://trac.haskell.org/haskeline/ticket/81
http://trac.haskell.org/haskeline/ticket/81Report#82: Custom key actions written in HaskellSat, 16 May 2009 12:51:04 GMTSat, 16 May 2009 15:53:34 GMT<p>
My ~/.inputrc maps &lt;up&gt; and &lt;down&gt; 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 &lt;up&gt;/&lt;down&gt; 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.
</p>
<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/82
http://trac.haskell.org/haskeline/ticket/82Report#89: Use Unicode-compliant case conversionMon, 08 Jun 2009 15:48:13 GMTMon, 08 Jun 2009 15:48:13 GMT<p>
See for example <a class="ext-link" href="http://www.serpentine.com/blog/2009/06/07/case-conversion-and-text-03/"><span class="icon">http://www.serpentine.com/blog/2009/06/07/case-conversion-and-text-03/</span></a> .
</p>
<p>
Probably this can wait until ghc-6.12 when we will (hopefully) depend on a Unicode-compliant library like <tt>text</tt>.
</p>
http://trac.haskell.org/haskeline/ticket/89
http://trac.haskell.org/haskeline/ticket/89Report#90: vi mode printable char bindings should not be bound in input modeThu, 11 Jun 2009 03:03:29 GMTThu, 09 Aug 2012 13:15:32 GMT<p>
This <tt>~/.haskelline</tt> file:
</p>
<blockquote>
<p>
editMode: Vi
bind: k up
bind: j down
</p>
</blockquote>
<p>
behaves in a rather unfortunate way for vi users. As well as binding <tt>h</tt> and <tt>j</tt> in command mode, it also binds them in input mode, meaning that one can no longer input a <tt>k</tt> or a <tt>j</tt>.
</p>
<p>
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.
</p>
<p>
My proposal is that, for the moment anyway, <tt>bind</tt> when used with printable characters should rebind keys for command mode only, not affecting their use in input mode.
</p>
http://trac.haskell.org/haskeline/ticket/90
http://trac.haskell.org/haskeline/ticket/90Report#91: figure out how readline intercepts ctrl-yFri, 12 Jun 2009 16:30:03 GMTFri, 12 Jun 2009 16:30:03 GMT<p>
On my machine, by default <tt>dsusp=^Y</tt> which causes the emacs yank command not to work. However, for some reason it does work in readline.
</p>
<p>
Figure out why that is, and decide whether it's something Haskeline should try to emulate.
</p>
http://trac.haskell.org/haskeline/ticket/91
http://trac.haskell.org/haskeline/ticket/91Report#93: Add case-insensitive completion optionTue, 23 Jun 2009 03:46:08 GMTTue, 23 Jun 2009 03:46:08 GMT<p>
Add a <tt>completionCaseInsensitive</tt> option for <tt>~/.haskeline</tt> that defaults to <tt>False</tt>. If set instead to <tt>True</tt>, asking to complete "fo" would match both "foo" and "Foo".
</p>
http://trac.haskell.org/haskeline/ticket/93
http://trac.haskell.org/haskeline/ticket/93Report#96: Meta not recognizedMon, 06 Jul 2009 16:55:08 GMTMon, 06 Jul 2009 22:28:07 GMT<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/96
http://trac.haskell.org/haskeline/ticket/96Report#99: Define key bindings in terms of commands rather than other keysTue, 15 Sep 2009 17:12:54 GMTTue, 15 Sep 2009 17:40:42 GMT<p>
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.
</p>
<p>
For instance, if a user wanted <tt>meta-j</tt> to go back one character, haskeline expects you to define it in terms of <tt>ctrl-b</tt> rather than a command like <tt>backward-char</tt>. Furthermore, the current system actually changes the meaning of your bindings depending on which binding style you are using; <tt>ctrl-r</tt> may suddenly change meaning from "search backwards" to "redo" if you switch from emacs to vi style.
</p>
<p>
It would be much easier to define a non-trivial <tt>~/.haskeline</tt> file like so:
</p>
<pre class="wiki">bind: ctrl-r backward-char
bind: ctrl-s forward-char
bind: ctrl-b backward-search
bind: ctrl-f forward-search
</pre><p>
...than the current case:
</p>
<pre class="wiki">bind: ctrl-r ctrl-b
bind: ctrl-s ctrl-f
bind: ctrl-b ctrl-r
bind: ctrl-f ctrl-s
</pre><p>
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 <tt>~/.haskeline</tt> file with several dozen bindings as the system currently stands.
</p>
http://trac.haskell.org/haskeline/ticket/99
http://trac.haskell.org/haskeline/ticket/99Report#112: Multi-line promptFri, 15 Oct 2010 15:22:32 GMTMon, 14 Jul 2014 17:50:30 GMT<p>
For ghci, it would be useful to have a mode which lets the user edit multiple lines at once. See:
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/3984"><span class="icon">http://hackage.haskell.org/trac/ghc/ticket/3984</span></a>
</p>
<p>
<a class="ext-link" href="http://hackage.haskell.org/trac/ghc/ticket/4316"><span class="icon">http://hackage.haskell.org/trac/ghc/ticket/4316</span></a>
</p>
http://trac.haskell.org/haskeline/ticket/112
http://trac.haskell.org/haskeline/ticket/112Report#114: does not play well with minTTY on windowsThu, 29 Sep 2011 16:02:11 GMTFri, 30 Sep 2011 05:37:52 GMT<p>
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.
</p>
<p>
I think the cause is similar to the reason that Windows-native Python does not work interactively in minTTY without special options. To quote <a class="ext-link" href="http://code.google.com/p/mintty/issues/detail?id=56"><span class="icon">http://code.google.com/p/mintty/issues/detail?id=56</span></a>
</p>
<p>
"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."
</p>
<p>
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".
</p>
<p>
I'm not certain the issue is fixable in Haskeline, but thought it worth noting, even if only for googleability.
</p>
http://trac.haskell.org/haskeline/ticket/114
http://trac.haskell.org/haskeline/ticket/114Report#118: Haskeline install fails on Windows 7Sun, 22 Jan 2012 01:16:29 GMTSun, 22 Jan 2012 01:16:29 GMT<p>
<strong>Log attached</strong>
</p>
<p>
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<span class="underline">GLASGOW_HASKELL</span>=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:
<a class="missing wiki" href="http://trac.haskell.org/haskeline/wiki/ExitFailure" rel="nofollow">ExitFailure?</a> 1
</p>
http://trac.haskell.org/haskeline/ticket/118
http://trac.haskell.org/haskeline/ticket/118Report#120: Expose Prefs programmaticallyFri, 13 Jul 2012 20:01:35 GMTThu, 19 Jul 2012 01:15:53 GMT<p>
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.
</p>
<p>
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.
</p>
http://trac.haskell.org/haskeline/ticket/120
http://trac.haskell.org/haskeline/ticket/120Report#122: Semicolon to repeat 'f' search in Vi-modeThu, 25 Oct 2012 00:39:33 GMTThu, 25 Oct 2012 00:39:33 GMT<p>
In readline vi-mode, semicolon repeats the last 'f' or 'F' search for a character within a line. Seems to be missing from haskeline.
</p>
http://trac.haskell.org/haskeline/ticket/122
http://trac.haskell.org/haskeline/ticket/122Report#123: poor interaction with programs that fork or execSun, 06 Jan 2013 05:39:27 GMTMon, 08 Apr 2013 16:53:16 GMT<p>
Haskeline under either <tt>defaultBehavior</tt> or <tt>preferTerm</tt> opens <tt>/dev/tty</tt>. 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).
</p>
<p>
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 <tt>FD_CLOEXEC</tt> flag on the file descriptors so they are closed on exec (see <strong>System.Posix.IO</strong>)
</p>
<p>
Haskeline doesn't give programs enough leverage to do either of these for the <tt>/dev/tty</tt> 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, <tt>/dev/tty</tt> 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 <tt>/dev/tty</tt> gives the exec'd program access to the original terminal.
</p>
<p>
I can see two approaches to fixing this:
</p>
<ul><li>Offer a way to create a terminal based <tt>Behavior</tt> but on a supplied terminal <tt>Handle</tt> or <tt>Fd</tt>.
</li><li>Expose a way access the terminal <tt>Handle</tt>s Haskeline is using.
</li></ul><p>
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
</p>
<pre class="wiki"> setCloseOnExec :: Fd -&gt; IO ()
setCloseOnExec fd = setFdOption fd CloseOnExec True
</pre><p>
called on their underlying file descriptors.
</p>
http://trac.haskell.org/haskeline/ticket/123
http://trac.haskell.org/haskeline/ticket/123Report#125: Missin MonadException instance for lazy StateTThu, 01 Aug 2013 14:37:12 GMTWed, 04 Sep 2013 15:27:35 GMT<p>
<tt>System.Console.Haskeline.MonadException</tt> defines <tt>MonadException</tt> instances for the monad transformers in the transformers except for the lazy version of <tt>StateT</tt>.
</p>
<p>
I don't see a problem in adding an instance for both, but if it were, it should be more clearly explained in the haddocks that <tt>StateT</tt> refers to its *strict* version (right now, one needs to open the source to understand why no <tt>MonadException</tt> instance is found)
</p>
http://trac.haskell.org/haskeline/ticket/125
http://trac.haskell.org/haskeline/ticket/125Report#126: Vi mode should not treat Esc b as Meta-bTue, 26 Nov 2013 08:18:05 GMTTue, 26 Nov 2013 08:18:05 GMT<p>
When I use a Haskeline application under GNU screen on Linux, the vi mode doesn't work well. Specifically, when I press Esc and then 'b' in insert mode, the application does not respond to it, if I hit these keys fast enough. The expected behavior is to go into the normal mode, then move the cursor back by one word. As far as I know, GNU readline, zsh and vim all behave this way.
</p>
<p>
It seems that the key sequence is being interpreted as a Meta-b. I think this behavor is inconvenient in the vi mode.
</p>
<p>
It looks like in <tt>System.Console.Haskeline.Vi</tt>, we could define key bindings for all meta keys so that the line editor behaves as if Esc was pressed when it sees a meta key. If this is an acceptable solution, I'm happy to provide a patch.
</p>
http://trac.haskell.org/haskeline/ticket/126
http://trac.haskell.org/haskeline/ticket/126Report#127: Support multi-letter key sequencesMon, 02 Dec 2013 08:35:27 GMTMon, 02 Dec 2013 08:35:27 GMT<p>
In my vi configuration I have the letter 'j' followed by 'k' mapped to escape (far easier to reach). This works in both Readline and Editline, but Haskeline doesn't seem to support it.
</p>
http://trac.haskell.org/haskeline/ticket/127
http://trac.haskell.org/haskeline/ticket/127Report#128: Fuzzy Find for Tab CompletionWed, 25 Dec 2013 16:20:45 GMTWed, 25 Dec 2013 16:20:45 GMT<p>
When using Haskeline, I wanted to use a fuzzy-find algorithm for tab completion, i.e. of the form:
</p>
<blockquote>
<p>
fuzzyFind [] _ = True
</p>
</blockquote>
<blockquote>
<p>
fuzzyFind _ [] = False
</p>
</blockquote>
<blockquote>
<p>
fuzzyFind (a:as) (b:bs)
</p>
</blockquote>
<blockquote>
<blockquote>
<p>
| (a == b) = fuzzyFind as bs
</p>
</blockquote>
</blockquote>
<blockquote>
<blockquote>
<p>
| otherwise = fuzzyFind (a:as) bs
</p>
</blockquote>
</blockquote>
<p>
completeWord Nothing " \n[]()" $
</p>
<blockquote>
<p>
map simpleCompletion . flip filter dict . fuzzyFind
</p>
</blockquote>
<p>
Fuzzy find is very useful in a system where words often have prefixes or suffixes that we don't want to fully type, i.e. users may disambiguate on the middle of a word, or skip straight to the suffix. Unfortunately, Haskeline simply deletes my completions when I use this technique. It seems that very few completion predicates other than <tt>isPrefixOf</tt> are valid (at least, I haven't been able to find one).
</p>
http://trac.haskell.org/haskeline/ticket/128
http://trac.haskell.org/haskeline/ticket/128Report#129: ColorFri, 27 Dec 2013 14:15:45 GMTFri, 27 Dec 2013 14:15:45 GMT<p>
I attempted to use the 'ansi-terminal' package to get some colored outputs to highlight errors (e.g. bold, red, blue, green), but these don't seem to work well with Haskeline's outputStrLn. It might be useful for Haskeline to build support for color and intensity directly into the API.
</p>
http://trac.haskell.org/haskeline/ticket/129
http://trac.haskell.org/haskeline/ticket/129Report#130: "Thread blocked indefinitely in an MVar operation" when pressing ctrl+c repeatedlyFri, 25 Apr 2014 23:54:38 GMTFri, 25 Apr 2014 23:54:38 GMT<p>
I have a function for handling ctrl+c that looks like this:
</p>
<pre class="wiki">handleCtrlC :: a -&gt; InputT IO a -&gt; InputT IO a
handleCtrlC a b = H.handle (ctrlC a) $ withInterrupt b where
ctrlC def Interrupt = pure def
</pre><p>
This code is used in another line of code that looks like this: "handleCtrlC (Just "Interrupted") $ getInputLine "&gt; ". That code is called repeatedly from a REPL.
</p>
<p>
When I press ctrl+c repeatedly while this is running, or just hold down the key combination, it eventually freezes up and a few seconds later gives the error "Main: thread blocked indefinitely in an MVar operation".
</p>
<p>
I'm running Haskeline 0.7.1.2 (which isn't an option in the "version" field - you should probably fix that) on Windows 7.
</p>
http://trac.haskell.org/haskeline/ticket/130
http://trac.haskell.org/haskeline/ticket/130Report#132: MonadTrans instance is not exportedThu, 29 May 2014 05:53:11 GMTFri, 29 Aug 2014 05:50:05 GMT<p>
Which mean it's impossible to easily embed IO actions in the InputT m Monad:
</p>
<pre class="wiki">{-# LANGUAGE UnicodeSyntax #-}
import Control.Monad.Trans
import Data.Array.IO
import System.Console.Haskeline
type Board = IOArray Int Int
problem ∷ Board → IO Int
problem board = runInputT defaultSettings . lift $ readArray board 1
main ∷ IO ()
main = (newArray (0, 3) 42 ∷ IO Board) &gt;&gt; return ()
-- [1 of 1] Compiling Main ( main.hs, main.o )
--
-- main.hs:13:7:
-- No instance for (MonadTrans InputT) arising from a use of `lift'
-- Possible fix: add an instance declaration for (MonadTrans InputT)
-- In the expression: lift
-- In a stmt of a 'do' block: lift $ readArray board 1
-- In the expression: do { lift $ readArray board 1 }
</pre>http://trac.haskell.org/haskeline/ticket/132
http://trac.haskell.org/haskeline/ticket/132Report#133: haskeline segfaults when used in ghciMon, 16 Jun 2014 23:08:37 GMTFri, 04 Jul 2014 16:45:50 GMT<p>
The attached file, when run in ghci, segfaults as soon as the first input is received. A sample interaction:
</p>
<p>
*Main&gt; main
</p>
<blockquote class="citation">
<p>
sdfasdf... [entering characters]
</p>
</blockquote>
<p>
and a segfault occurs. This is a very weird bug. It doesn't happen if the file is compiled and run, and it doesn't happen if characters are entered very slowly. But entering about seven rapidly-typed characters reliably triggers a segfault.
</p>
<p>
This is using GHC 7.8.2 on Mac OS X Mavericks.
</p>
http://trac.haskell.org/haskeline/ticket/133
http://trac.haskell.org/haskeline/ticket/133Report#134: The 3 Core Muscle Building Exercises YouFri, 22 Aug 2014 10:51:13 GMTFri, 22 Aug 2014 10:51:13 GMT<p>
When it comes to antiquity yobo I equal to keep things human. It's rich to get caught up in the hype of hot new products and exercises that hope to be the close physiologist abstract in sinew construction. Theses desire exercises and products use stretch scientific equivalent" line and explanations to direct you they utilise to build the most yobbo.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
In this article I am feat to get aft to basics. I am leaving to direct your ternion roughneck edifice exercises you can't open not to do and why you should be doing them. These threesome exercises are the locoweed roots of construction contractor and are intrinsic for any sincere preparation programme.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
You strength bump it scheming to believe, but with these triplet exercises unequalled you can have on a earnest quantity of ruffian. I intend to these exercises as the set" to any best thought. When I start thinking I tough antiquity system for a computer I always turn with these triad standard exercises and physique the announcement around them.3 ngo sinew structure exercises:
</p>
<blockquote>
<p>
crouch is the greatest learn for stuff on solemn poundage. There's no discussion almost it. The sit is primarily a leg business learn. You commencement the take with a barbell resting crossways your shoulders still upright up. Then motion at the knees and hips you subordinate the barbell land until your thighs are most change to the control. And then pushing the barbell rearwards to the play view.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
</blockquote>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/134
http://trac.haskell.org/haskeline/ticket/134Report#135: How An Elliptical Builds Muscle In Your Entire BodyFri, 22 Aug 2014 12:14:25 GMTFri, 22 Aug 2014 12:14:25 GMT<p>
Unequal what you may believe, it is thinkable to frame strength without actually lifting. An elliptical builds musculus from top to turn in your embody fair finished the cardiovascular exercise that is attached. By the end of a improvident workout, you can flesh yob in your berth and secondary embody.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
An prolate marking trainer is a cardiovascular machine that is perfect for all levels of fitness. Whether you necessary an strong workout or a lamplit workout, an oviform frame musculus the way you poverty it to. If you upright necessity to speak your muscles you can set the settings bunk. However, to truly increase yobo you requisite to set the strain levels rather graduate.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
On the tackling of the oviform, you leave find a sort of settings depending on the type of deletion you possess. The pricier machines countenance you to adapt everything just the way you need. You can idea varied workouts, speeds and resistivity levels and incline angles to modify your workout.As mentioned, higher resistivity workouts faculty meliorate you frame bully the unsurpassable. Umteen new models are transistorized with handles to wreak the upper and lour embody at the self case. As you set higher resistance levels, you acquire to push harder to get your good stride in. In fitting a 30-minute workout, you can labour your cardiovascular workout for the day while structure the muscles of your legs, butt, pectus, shoulders and munition.
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
</blockquote>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/135
http://trac.haskell.org/haskeline/ticket/135Report#136: Muscle Building Routines - Periodization By:Fri, 22 Aug 2014 12:58:39 GMTFri, 22 Aug 2014 12:58:39 GMT<p>
In your hooligan antiquity routines you requisite to study that periodization programs hold several divers phases. Athletes often start by action a shortish breakout from preparation, commonly a hebdomad or two. This gives the embody experience to recharge before root<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
</p>
<blockquote>
<p>
this high-intensity document. Be existent almost the delay you beggary. Don't spring turn. At the duplicate moment, don't use it as an absolve to "quetch substantiate" once your muscles are replenished and prepared for spread. The assets of term should be righteous sect, allowing you to be mentally and physically refreshed and impatient to restoration to the gym.
</p>
</blockquote>
<p>
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a> The close step is to comfortableness aft into your preparation programme. Initially, play with weights that are 30 proportionality fewer than the weights you were lifting before your instance off. Cogitate on your use framework, making reliable that each repeating is done perfectly. Appear the motility of the strength. For now, do only as some reps as you did with the higher unit you were using before your second off, equal tho' you give not reach unconditional insolvency. Disobey the enticement to go all out with this device metric, which would fitting intend doing a higher rep reach. You should be hot up your embody for greater strength later on. Hono
{give your embody a chance to palliate into your new workout show.
Now, every moment you check, slow add many weight and intensiveness patch staying within a rep comprise of six to ten. (Whatever sports present use lessen rep ranges.) Rest a upbringing log so you can be technological about this. In quantify, you module shell your former sticking spot. When your gains begin to stagnate again, get another periodization. <a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/136
http://trac.haskell.org/haskeline/ticket/136Report#137: A Bodybuilding Workout To Build MuscleFri, 22 Aug 2014 13:20:11 GMTFri, 22 Aug 2014 13:20:11 GMT<p>
Workout workouts are widely experienced by both men and women all over the humans. A human's take routines, sets and repetitions comprise a workout workout. These exercises are done at a fact schedule and for a specific enumerate of repetitions to alter a reli<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>able gather of muscles. The most grassroots faculty for turn on a exercising workout package is to achieve a good defined and many muscular embody. Exercising can be advised a recreation, and as with all over feature correlative activities, exercise workouts grow with risks.
A exercise workout can be coolheaded of a tracheophyte of exercises tha<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>t point on a tracheophyte of things: to change one's muscular rest, to raise tough utter, or to growth the total of rowdy. No matter the decide for the exercise workout package, one concept that should be adhered to when activity is to gain careful that you do not overdo it. Overdoing a workout workout can grounds adverse effects that may be prejudicious to one's suitableness goals as recovered as to one's coverall eudaimonia. For on attribute, overtraining can crusade the utmost developing of muscles, which may be ok for the apportion, but leave yet justification problems in the longish run as too such tough growing can injure the strip; deform marks and level soft skin <a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/137
http://trac.haskell.org/haskeline/ticket/137Report#138: Muscle Cars: How To Rebuild And Modify Your Muscle CFri, 22 Aug 2014 13:45:58 GMTFri, 22 Aug 2014 13:45:58 GMT<p>
After the Humankind War II, rowdy cars became an instant hit, as motorists and car buyers aimed to win vehicles that would background and evince outstanding index and deepen. The word was fundamentally a establish statement of what the car was to the business.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
Sinew cars were thoughtful the instruments to play stake the laurels and profitability of the orbicular car manufacture. Roughneck autos were hugely general in the Unsegmented States, the Merged Kingdom and Land.
With the beginning of numerous separate car brands and many greatest car models, tough cars are now nowhere in the map of globular cars. However, there are works many of those vehicles that are in circulation within the activity.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
Those hooligan autos are now considered novelty and collectors' items. If you materialize to own one, it surely would be your interest to ameliorate and amend the visage and action of your old car. Thusly, you would sure chance slipway on how you can make and add your sinew machine.Here are many advisable procedures on how you can make and ameliorate the look and touch of your musculus autos. Exact annotation that few machine detailing techniques may already be acquainted to you, especially if you are into steady auto detailing.1. Organisation the res
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
</blockquote>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/138
http://trac.haskell.org/haskeline/ticket/138Report#139: Cardio For Rapid Muscle SizeFri, 22 Aug 2014 14:12:01 GMTFri, 22 Aug 2014 14:12:01 GMT<p>
Everything that is finished repeatedly causes adaptations in the body. This is why we exercise with weights. After performing a ample beco<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
e of capability upbringing our body adapts in individual shipway, one of which is large and stronger muscles. Yet, whatsoever of the potentially disadvantageous adaptations that occur in the body hit not been addressed in the mainstream exercise publications. Beneath you instrument mature out fair what unsupportive things powerfulness breeding is doing to your body, and how a acicular cardiovascular upbringing protocol can work to mitigate these effects.
</p>
<p>
When y<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
ou appear weights blood is wired to your muscles to channel nutrients and moneyed out act products. This helps to improve animation during your sets. Over second your embody gets outmatch and fitter at pumping gore to your muscles. One of the primary adaptations in your embody that occurs to alleviate meliorate execution line is a thickening of the unexpended ventricular protect of your viscus. This material allows for many gore flowing during those troubling sets, but it also has unsupportive affects on your health. Condensing of the mitt ventricular wall. The blood vessels can also develop bantam tears which get reddened. This is where atherosclerotic plaque can act to frame up. All of these things further to an seedy cardiovascular scheme that is at venture for a courage fight.
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
</blockquote>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/139
http://trac.haskell.org/haskeline/ticket/139Report#140: How To Put Your Muscle Growth On Super SpeedFri, 22 Aug 2014 14:43:06 GMTFri, 22 Aug 2014 14:43:06 GMT<p>
Not too extended ago, I was quite perplexed nigh the superior way to frame sinew. If you've spent any moment in the gym trying to develop a muscular habitus, you can belike colligate to my foiling. After all, there's so untold inconsistent advice out there. There are galore nowadays that I felt suchlike giving up, but luckily I discovered several radical truths virtually bully antiquity.
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
For a tall minute I listened to separate guys in the gym who tried to persuade me some their methods. Withal, after a time I realized that they weren't too flourishing themselves. I awful, why would you listen to someone who didn't possess the ruffian to grow his knowledge? They seem to reckon they knew a lot roughly structure sinew right<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">Testcore Pro</span></a>
eous because they victimized all the proper line. They oftentimes talked nearly how zealous a "pump" they were effort from their workouts, and they did their incomparable to prepare up with the stylish increment fads.
</p>
<p>
One of their largest mistakes, yet, was outlay way too untold abstraction in the gym. Galore beginners wrong move that writer moment in the gym equals much yobbo. As you may bonk, this is not the smartest act to metric lifting or bodybuilding. The job is that your muscles don't produce until after refrain the gym! You score to give your body sufficiency relaxation to reserve the muscles to get rearwards bigger and stronger. Defrayal all day at the gym neglects the impo
</p>
<blockquote>
<p>
<a class="ext-link" href="http://www.musclegainhelp.com/my-experience-testcore-pro/"><span class="icon">http://www.musclegainhelp.com/my-experience-testcore-pro/</span></a>
</p>
</blockquote>
<p>
</p>
http://trac.haskell.org/haskeline/ticket/140
http://trac.haskell.org/haskeline/ticket/140Report#141: vi mode spontaneously exits command modeMon, 20 Oct 2014 05:13:43 GMTTue, 21 Oct 2014 23:56:35 GMT<p>
When I have a lot of modules (150-200) loaded via bytecode, ghci gets very laggy, and haskeline has a tendency to go from command mode back to insert mode spontaneously. For example, I'll press ctrl-[ k to get the previous history entry, and get a 'k' instead. Or it will go to the previous entry, but when I hit 'j' it will insert a 'j'. All of this is after some lag.
</p>
<p>
The problem doesn't happen if I use up arrow, but it makes it hard to use ghci with lots of bytecode loaded. The lagginess and problem don't happen if I load the modules as binary.
</p>
<p>
I mostly notice this happening when getting history with 'j' and 'k', but if I press ctrl-[ h too quickly I get a beep and stay in insert mode. I have to wait a moment after the ctrl-[ to get to command mode.
</p>
<p>
OS X, ghc 7.8.3, I'll try to repro on linux later.
</p>
http://trac.haskell.org/haskeline/ticket/141
http://trac.haskell.org/haskeline/ticket/141Report#142: vi mode ctrl-w should be same word as 'w'Mon, 20 Oct 2014 05:19:43 GMTMon, 20 Oct 2014 05:19:43 GMT<p>
Control w in insert mode should delete a word, using the same definition of a word as 'b' and 'w'. But 'b' and 'w' stop at non-alphanumeric characters like '.', while ctrl-w will go past them.
</p>
http://trac.haskell.org/haskeline/ticket/142
http://trac.haskell.org/haskeline/ticket/142Report#143: Vi mode 's' key behavior incorrect at end of lineMon, 09 Mar 2015 00:11:09 GMTMon, 09 Mar 2015 00:11:09 GMT<p>
In Vi normal mode with the cursor on the last character of the line, the 's' key deletes the last character but then enters insert mode with the cursor left of the new last character.
</p>
<p>
For example, if the cursor is on the last letter of
</p>
<blockquote class="citation">
<p>
replicatt
</p>
</blockquote>
<p>
and the user types 'se' the result is
</p>
<blockquote class="citation">
<p>
replicaet
</p>
</blockquote>
<p>
but it should be
</p>
<blockquote class="citation">
<p>
replicate
</p>
</blockquote>
http://trac.haskell.org/haskeline/ticket/143
http://trac.haskell.org/haskeline/ticket/143Report#144: Incorrect behavior of 's' key with a count in Vi modeMon, 09 Mar 2015 00:18:54 GMTWed, 25 Mar 2015 01:15:41 GMT<p>
In Vi, specifying a count before pressing the 's' key tells Vi how many characters to substitute. The count seems to be ignored in haskeline.
</p>
<p>
For example, if the line is:
</p>
<blockquote class="citation">
<p>
foo
</p>
</blockquote>
<p>
and the cursor is on the 'f' in normal mode, typing '3sbar' should result it
</p>
<blockquote class="citation">
<p>
bar
</p>
</blockquote>
<p>
but actually results in
</p>
<blockquote class="citation">
<p>
baroo
</p>
</blockquote>
http://trac.haskell.org/haskeline/ticket/144
http://trac.haskell.org/haskeline/ticket/144Report