1

In realgud, there are fringe indicators used to show what position the debugged program is stopped at. However the face for the bit map is statically created and the background/foreground colors for it are set once when the lisp code is loaded, or run. Specifically:

(if (equal 'dark (frame-parameter nil 'background-mode))
    (progn
      (defface realgud-overlay-arrow1
        '((t
           :foreground "green"
           :weight bold))
        "Fringe face for current position."
        :group 'realgud)
      ;; ...
      )
  ;; else
  (progn
    (defface realgud-overlay-arrow1
      '((t
         :foreground "black"
         :weight bold)))
    ;; ...
    ))

This has a problem that when a frame's background parameters are changed, this doesn't track that. It could also be the situation that realgud was loaded say either from a frame or when emacs had a different dark/light background parameter than the one which a debugger is currently stopped at.

So how does one fix this?

Alternatively, it might be good to ditch the fringe setting altogether, but if that's done there should be a solution that works in a terminal without bitmap capabilities.

Edit:

It also occurs to me that since this property is available under list-faces-display, maybe the right thing is not to change this and wait for realgud to become popular enough for various theme authors to decide to explicitly set that. Alternatively, I could set the colors based on some other more popular face setting, but I don't see something in list-faces-display that sticks out. Thoughts here?

1 Answer 1

2

how does one fix this?

Defining faces via defface inherently involves predicating face attributes on terminal characteristics, e.g. whether the background is light/dark or whether the terminal can render bitmaps. In your example, the t symbol in both face specs is an example of such a predicate which matches all terminals. See the Elisp Manual node on Defining Faces for the full description of the syntax of face specs.

Using this capability, your sample face would canonically be defined like so:

(defface realgud-overlay-arrow1
  '((((background  dark)) :foreground "green" :weight bold)
    (((background light)) :foreground "black" :weight bold))
  "Fringe face for current position."
  :group 'realgud)

or

(defface realgud-overlay-arrow1
  '((default :weight bold)
    (((background  dark)) :foreground "green")
    (((background light)) :foreground "black"))
  "Fringe face for current position."
  :group 'realgud)

or similar. The required display characteristics can then be further fine-tuned, e.g. ensuring the terminal supports colour (class color) or graphics (type graphic).

I am not familiar with how Emacs renders faces under the bonnet, but I assume it involves running through their current face spec and applying those attributes corresponding to the current terminal characteristics.

maybe the right thing is not to change this

I am not familiar with the realgud project, the features it provides or the constraints under which it must operate, but my opinion regarding the sample face you list is that its definition should definitely be adapted to make better and more idiomatic use of the provided Emacs facilities, especially when the current behaviour leads to issues with static face definitions. Perhaps the author(s) can look at other packages which make heavy use of faces and fringes for inspiration - one such package being flycheck.

wait for realgud to become popular enough for various theme authors to decide to explicitly set that

Explicit support for realgud by custom themes should be added independently of realgud having sensible defaults which will do the right thing in a bare Emacs instance. Custom themes should offer customisation, not bug fixes. :) By the way, I recommend taking the initiative in contributing support for new packages to custom themes, otherwise you might be waiting a long time for someone using the same theme/package combination to come along. :)

I could set the colors based on some other more popular face setting

You most definitely could. The two most common sets of faces you could browse initially are the Standard and Font Lock faces. Failing that, you could look at the palette of your favourite custom theme.

1
  • 1
    All great suggestions and advice. github.com/realgud/realgud/pull/177 incorporates the changes suggested. When I get time, I'll add some pull requests in various themes I use.
    – rocky
    Commented Jun 29, 2017 at 22:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.