haskeline: http://trac.haskell.org/haskeline/report/8
Trac Report - en-ushaskelinehttp://trac.haskell.org/haskeline/chrome/common/trac_banner.pnghttp://trac.haskell.org/haskeline/report/8
Trac v0.11.1#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#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#63: Multiword UTF-16 code points aren't handled correctly on WindowsSun, 04 Jan 2009 20:57:45 GMTThu, 04 Jun 2015 17:13:59 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#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#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#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#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#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#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#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