Ticket #79 (new defect)

Opened 8 years ago

Last modified 5 years ago

Emacs and haskeline (or GHCi) do not interact very well

Reported by: nad Owned by: judah
Priority: minor Milestone:
Version: 0.6 Keywords:

Description (last modified by nad) (diff)

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 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?

Change History

  Changed 8 years ago by nad

  • description modified (diff)

  Changed 8 years ago by judah

Thanks for the report. I'm unable to reproduce this on OS X 10.5.7; what operating system and which binary/source distribution are you using?

It's very strange that this would be happening since ghci/haskeline should only be doing a getLine to read the input from the emacs shell.

  Changed 8 years ago by nad

Linux (Ubuntu 9.04), http://haskell.org/ghc/dist/6.10.3/ghc-6.10.3-i386-unknown-linux-n.tar.bz2.

I get the same error when using Emacs 22. With GHC 6.10.2, which uses Editline, I get a similar error, but a longer string is necessary to trigger it. GHC 6.8.3, which uses Readline, seems to be unaffected.

  Changed 8 years ago by judah

  • owner set to judah

Ok, I installed ghc-6.10.3 on an Ubuntu machine and was able to reproduce your issue. I'll look into this, though I probably won't have time to dig deeply until next week.

As a workaround, if we can figure out the cause, we may be able to fix this in the ghci-haskeline package: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ghci-haskeline

  Changed 8 years ago by judah

This appears to be a problem with GHC; I've submitted a bug report at http://hackage.haskell.org/trac/ghc/ticket/3256 .

  Changed 8 years ago by judah

  • priority changed from major to minor

It appears that Emacs itself inserts the EOT into the output when ICANON is not set. See the above GHC ticket for an example C program with the same behavior.

I don't think there's anything Haskeline can do about this issue, since it seems like a bug in Emacs; but feel free to update the ticket with any suggestions.

  Changed 8 years ago by judah

  • version set to 0.6

  Changed 8 years ago by nad

The reference to ICANON led me to the following message:


This is apparently a feature of the Emacs shell.

in reply to: ↑ description ; follow-up: ↓ 10   Changed 5 years ago by aleksey

Replying to nad:

Is there a known (simple) workaround for the problem?

cat | ghci instead of ghci works for me in shell-mode.

in reply to: ↑ 9   Changed 5 years ago by nad

Replying to aleksey:

Replying to nad:

Is there a known (simple) workaround for the problem?

cat | ghci instead of ghci works for me in shell-mode.

I've been using a custom implementation of "comint-input-sender":

  (set (make-local-variable 'comint-input-sender) 'agda2-send)

Implementation of agda2-send:

  (defun agda2-send (proc s)
    "Sends the string S to PROC.
  Splits up S into small chunks and sends them one after the other,
  because when GHCi is used in shell buffers it chokes on overly
  long strings (some versions of GHCi, on some systems)."
    (let* ((chunk-size 200))
      (dolist (chunk (agda2-chunkify chunk-size s))
        (comint-send-string proc chunk)))
    (comint-send-string proc "\n"))

Agda no longer uses GHCi, though.

Note: See TracTickets for help on using tickets.