ncurses: the best way to disable background color?

[kmizumar]

First and foremost, I would like to express my gratitude for providing such excellent software.

I am using Lem (main/HEAD) in ncurses mode and would like to know the best way to disable background rendering so that the terminal's background remains visible. First, I tried the following settings in my ~/.config/lem/init.lisp, but they had no effect.

(if (typep (lem-core:implementation) 'lem-sdl2/sdl2:sdl2)
    ;; transparent background with sdl2
    (sdl2-ffi.functions:sdl-set-window-opacity
     (lem-sdl2/display:display-window (lem-sdl2/display:current-display)) 0.8f0)
    ;; enable default color mode (-1) with ncurses
    (charms/ll:use-default-colors))

However, when I run M-x lisp-eval-string (charms/ll:use-default-colors), the display appears as follows. This is not exactly what I expected, but I suspect that the settings specified in init.lisp are being overridden before they take effect at startup.

Next, I tried adding the following code to init.lisp.

(define-color-theme "lem-dark" ("emacs-dark")
  (:background nil))

(load-theme "lem-dark")

This resulted in a display that is almost as expected, but...

Running commands like C-x C-e lisp-eval-at-point results in the following error.

The value NIL is not of type LEM/COMMON/COLOR:COLOR
Backtrace for: #<SB-THREAD:THREAD tid=268140 "editor" RUNNING {10039E86D3}>
0: (LEM-LISP-MODE/EVAL::COMPUTE-EVALUATED-BACKGROUND-COLOR)
1: (LEM-LISP-MODE/EVAL::DISPLAY-EVALUATED-MESSAGE #<LEM/BUFFER/INTERNAL:POINT (29, 0) "(define-key *global-keymap* \"C-\\\\\" 'undo)" {1006B57B13}> #<LEM/B
2: ((LAMBDA (LEM-LISP-MODE/CONNECTION:CONNECTION) :IN LEM-LISP-MODE/INTERNAL::PULL-EVENTS) #<LEM-LISP-MODE/CONNECTION::SELF-CONNECTION {1005FCD253}>)
3: ((LAMBDA NIL :IN LEM-LISP-MODE/INTERNAL::START-THREAD))
4: (LEM-CORE:RECEIVE-EVENT 0.001)
5: (LEM-CORE::READ-EVENT-INTERNAL :ACCEPT-KEY T :ACCEPT-MOUSE T)
6: (LEM-CORE::READ-EVENT-WITH-RECORDING-AND-RUN-HOOKS :ACCEPT-KEY T :ACCEPT-MOUSE T)
7: (LEM-CORE:READ-COMMAND)
8: (LEM/COMMON/TIMER::CALL-WITH-IDLE-TIMERS #<FUNCTION (LAMBDA NIL :IN LEM-CORE::COMMAND-LOOP-BODY) {B800774C7B}>)
9: (LEM-CORE::COMMAND-LOOP-BODY)
10: (LEM-CORE:COMMAND-LOOP)
11: (LEM-CORE::TOPLEVEL-COMMAND-LOOP #<FUNCTION (LAMBDA NIL :IN LEM-CORE::RUN-EDITOR-THREAD) {10046E38AB}>)
12: ((LAMBDA NIL :IN LEM-CORE::RUN-EDITOR-THREAD))
13: ((LAMBDA NIL :IN LEM-CORE::RUN-EDITOR-THREAD))
14: ((FLET BT2::RUN-FUNCTION :IN BT2::ESTABLISH-DYNAMIC-ENV))
15: ((LABELS BT2::%ESTABLISH-DYNAMIC-ENV-WRAPPER :IN BT2::ESTABLISH-DYNAMIC-ENV))
16: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
17: ((FLET "WITHOUT-INTERRUPTS-BODY-" :IN SB-THREAD::RUN))
18: ((FLET SB-UNIX::BODY :IN SB-THREAD::RUN))
19: ((FLET "WITHOUT-INTERRUPTS-BODY-" :IN SB-THREAD::RUN))
20: (SB-THREAD::RUN)
21: ("foreign function: call_into_lisp_")

This seems to be caused by the value of color becoming nil inside compute-evaluated-background-color, which is then passed to color-red, color-green, and color-blue.

lem/extensions/lisp-mode/ext/eval.lisp

Lines 81 to 91 in 791397f

	(defun compute-evaluated-background-color ()
	(let ((color (parse-color (background-color))))
	(multiple-value-bind (h s v)
	(rgb-to-hsv (color-red color)
	(color-green color)
	(color-blue color))
	(multiple-value-bind (r g b)
	(hsv-to-rgb h
	s
	(+ v (if (< v 50) 5 -5)))
	(color-to-hex-string (make-color r g b))))))

Replacing this part with when-let avoided the error, but the evaluated region's background is now filled with an unintended color.

I'm unfamiliar with nurses, so I might be doing something wrong. Could you advise me on the best settings to prevent background filling in the area where I am editing code?

[cxxxr]

Thank you for your interest in lem.

Perhaps this would be better

(define-color-theme "lem-dark" ("lem-default")
  (:background nil))

(load-theme "lem-dark")

emacs-dark/emacs-light has a flaw in setting the base16 value, so there is a problem with code that assumes base16 and causes a runtime error.
Therefore, we used lem-default instead.

[kmizumar]

emacs-dark/emacs-light has a flaw in setting the base16 value, so there is a problem with code that assumes base16 and causes a runtime error.

oh, I didn't know that. thank you for the information.
i'll try to find out comfortable settings for me.