search

dbuenzli / down

An OCaml toplevel (REPL) upgrade
http://erratique.ch/software/down
ISC License
81 stars 3 forks source link

Warning: Down v0.0.1 disabled. No ANSI terminal capability detected. #15

Open Fourchaux opened 5 years ago

Fourchaux commented 5 years ago

Config: Linux x86_64, Emacs 26.2, OCaml 4.08.0

In an Emacs session, running an OCaml REPL (C-c C-s from Tuareg mode) then trying #use "down.top";; give:

Warning: Down v0.0.1 disabled. No ANSI terminal capability detected.

Any problem with Emacs, Tuareg, Down?

N.B.: no pb using a terminal directly - Konsole (KDE) here. :=)

dbuenzli commented 5 years ago

Either your TERM variable is unset or it's set to dumb. I believe the latter is set in emacs since the terminal has no ANSI capability IIRC (cf. M-x shell vs M-x ansi-term).

Fourchaux commented 5 years ago

Alas, no.

I use emacs with TERM = xterm-256color.

(This variable is actually used with M-x shell or M-x ansi-term).

dbuenzli commented 5 years ago

It turns out I just came back from a tour into the insane world of emacs PATH, shell and environments. It is absolutely frightening.

I still suspect your term variable is not set correctly since the logic is pretty simple. The message is you see is from here:

https://github.com/dbuenzli/down/blob/14e55522494a2ec1bc5f67672fe21f7cdb2a4ef2/src/down.ml#L1000-L1001

The Tty.cap determination logic is here:

https://github.com/dbuenzli/down/blob/14e55522494a2ec1bc5f67672fe21f7cdb2a4ef2/src/down_std.ml#L371-L374

Could you please check what Sys.getenv "TERM" returns in that OCaml repl session ?

Fourchaux commented 5 years ago

Yep, in that REPL I have:

# Sys.getenv "TERM";;
- : string = "dumb"

( and not string = "xterm-256color" as in a "classic" OCaml session. )

Pb with the tuareg-interactive-mode?

dbuenzli commented 5 years ago

I don't know I'm using caml-mode but I have the same problem.

I rather suspect it's a problem with the comint mode use to implement this at least in caml-mode (try comint-run). It seems unclear where it gets its environment from (try Sys.command "env"). I don't think it goes through a shell to invoke the program it's rather an execvpe of the specified command.

dbuenzli commented 5 years ago

I personnally have other environment problems (the C stubs are not found, basically I would like to have opam env wrapper when I launch my ocaml from emacs).

But since you don't seem to have that problem maybe simply setting comint-terminfo-terminal might work for you (see https://www.gnu.org/software/emacs/manual/html_node/emacs/Shell-Options.html).

dbuenzli commented 5 years ago

FWIW I managed to solve all the problems on my side by installing the opam melpa package and the exec-path-from-shell package and adding the following to my init.el:

(exec-path-from-shell-initialize)
(opam-init)
(setq  comint-terminfo-terminal "xterm-256color")

but then as I expected the caml inferior process window does not interpret ANSI escapes.

Fourchaux commented 5 years ago

Tests du matin. A la fraîche, pour l'instant.

I tried several values (chosen in the list given by the command $toe) for comint-terminfo-terminal (xterm-256color, screen, screen-256color, linux, ansi too).

"down.top" actually loads without problems. Good.

Unfortunately (as you expected...) the resulting display is unusable. Even the initial # prompt does not appear!

dbuenzli commented 5 years ago

A la fraîche, pour l'instant.

Lucky you...

Even the initial # prompt does not appear!

Here if I run an ocaml inferior process the ANSI escapes are still uninterpreted but then setting stdin to raw mode fails:

        Ocaml version 4.07.1

Warning: Down v0.0.1 disabled. Failed to set stdin in raw mode.

However if I ocaml via comint-run I see the behaviour you mention and erratic input behaviour.

TBH I stopped using emacs for shells and toplevels a long time ago as I was never able to cope with the fact that emacs really wants to threat these windows as regular emacs buffers.

I see utop has an -emacs cli argument it could be useful to investigate what it's doing when this is enabled. But I have other work to be done right now.

(One good outcome of this investigation is however, that I was able to understand things a bit better and make compilation mode interpret ANSI escape sequences, namely by adding:

(add-hook 'compilation-filter-hook ; ANSI colorize
          '(lambda ()
             (let ((inhibit-read-only t))
               (ansi-color-apply-on-region (point-min) (point-max)))))

to my init.el, I wonder why they don't do these things by default.)

ivg commented 5 years ago

The M-x ansi-color-for-comint-mode-on <RET> will solve the colorizing issue (as well as bolding and other ansi terminal controlling escape sequences will be rendered correctly).

dbuenzli commented 5 years ago

@ivg this doesn't work here. The colors work "out-of-the-box" if I run via comint-run but not if I start it via caml-mode.

Fourchaux commented 4 years ago

About your comment:

TBH I stopped using emacs for shells and toplevels a long time ago as I was never able to cope with the fact that emacs really wants to threat these windows as regular emacs buffers.

I try these 2 Emacs packages https://github.com/akermu/emacs-libvterm
and https://github.com/jixiuf/vterm-toggle.

And the result is: down

Down running as-is inside Emacs :smiley:

Now, how to send the OCaml source code to the VTerm buffer, I don't know 😞

About emacs-libvterm: https://www.reddit.com/r/emacs/comments/cmrhgs/emacslibvterm_is_awesome/?sort=new