error on require with emacs --daemon

[jollm]

version 23.1.1, wrong type error number-or-marker-p nil, i'm not sure how to get a stack trace since it doesn't happen in interactive mode

[glasserc]

Hmm, that's very strange! I'm running emacs 23.1.1 too and emacs --daemon works fine. I'm guessing you're running the latest master?

I wrote the below to try to figure out where things are going wrong, but I think they are probably going wrong in the code that tries to compute a good face to highlight things in (lines 615-618). If you put a message before that and then after that, I bet you'll see the first one get output and not the second one. That's really the only place where I actually do math.

If that is where it's failing, then it's probably because there's no default frame background set at the time of require. Are you using color-theme? Do you have the color-theme calls before (require 'ethan-wspace) or after? If that isn't where the breakage is, maybe these approaches will help you track it down:

It would help a lot to know where the error was coming from -- is it not possible to run --daemon --debug-init? I tried and although I got "Entering debugger", I couldn't figure out how to actually see the debugged stack trace. Here are some ideas on how to figure out what's going on:

1. Sprinkle (message "Foo") calls throughout the code to see how far it's getting. The only code that actually does anything (besides declaring functions and modes and variables) are calls to ethan-wspace-declare-mode (lines 307, 361, 464, 520), defining what "whitespace" means (line 317: does some weird unicode decoding stuff) defining the mode-line element (line 571), computing a color for ethan-wspace-face (line 614),
2. Alternately, you can see how far it got by which symbols were defined (if you can get emacs --daemon to survive the bad require).
3. It might be possible to catch the error and introspect it to get information about it: stack trace and so on. I toyed with this for an hour but couldn't get anything working.

[jollm]

You were right on the money with the color-theme theory. I moved my color theme code to the top and that took care of it.
Would it make sense to put the face computation into some kind of hook or eval-after-load so that it has a better chance of success?

I too tried emacs --daemon --debug-init with no luck. It'd be nice to figure that one out.

Thanks for your assistance and all of your work on this project. I've been putting it to good use so far, it's nice to know that my files will have clean whitespace.

[glasserc]

Yeah, that's a pretty good idea. The only/easiest way I could find to implement this was to use window-configuration-change-hook. That hook gets called a lot so I only made recompute a good color when the background color changed. As a side effect, now the whitespace face color gets updated whenever you change color themes.

I think there might still be some issues for people who have different background colors for different frames (and I have no idea how to deal with that).

Thanks for the bug report and the suggestion!