dbuenzli / down

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. :=)

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).

Alas, no.

I use emacs with TERM = xterm-256color.

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

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:

down/src/down.ml

Lines 1000 to 1001 in 14e5552

    
           let install_down () = match Tty.cap with 
        
           | `None -> log_disabled "%s" err_no_ansi

The Tty.cap determination logic is here:

down/src/down_std.ml

Lines 371 to 374 in 14e5552

    
           let find_cap () = match Sys.getenv "TERM" with 
        
           | exception Not_found -> `None | "dumb" | "" -> `None | _ -> `Ansi 
        
           let cap = find_cap ()

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

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?

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.

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).

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.

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!

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

�[01;35mWarning�[m: 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.)

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).

@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.

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 running as-is inside Emacs 😃

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

	let install_down () = match Tty.cap with
	\| `None -> log_disabled "%s" err_no_ansi

	let find_cap () = match Sys.getenv "TERM" with
	\| exception Not_found -> `None \| "dumb" \| "" -> `None \| _ -> `Ansi

	let cap = find_cap ()