No face set with Emacs 24 and solarized-dark theme about erc-hl-nicks

[leathekd]

Hmm, that's odd. Was it working under some other theme? While I don't believe theme choice should affect the highlighting as erc-hl-nicks creates a new face on the fly, stranger things have happened.

erc-hl-nicks highlights any word in a buffer where:

• erc-channel-users is set
• the word is a channel user
• the word (trimmed of special characters) isn't in the list of nicks to skip
• and the word doesn't have a face that we don't want to highlight over (e.g. erc-notice-face)

Could any of that explain what you're seeing?

The code is here if you're interested: https://github.com/leathekd/erc-hl-nicks/blob/master/erc-hl-nicks.el#L185

[bradwright]

erc-channel-users appears to be set, and 3/4 don't apply for me (I have no values for any of those). I'm using the ZNC bouncer though, I wonder if that's a problem? It might report users differently.

[bradwright]

The format is like so:

("nick"
       ([erc-server-user "nick" "server.com" "~nick" nil nil
                         (#<buffer #example-chat>)]
        .
        [erc-channel-user nil nil nil]))

[leathekd]

Hmm, I haven't been able to reproduce this. I also use ZNC and it's working fine.

• What other ERC modules are you using?
• Are there any messages in the Messages buffer that might indicate something is up?
• Can you toggle debug-on-error and reproduce? Do you get any errors?

I grepped the erc code and found an instance where it'll return the default face in erc-get-fg-color-face. It should log an error or write to the messages buffer.

[bradwright]

Here are my modules:

(pcomplete services netsplit fill button match track completion 
readonly networks ring autojoin noncommands irccontrols move-to-prompt 
stamp menu list hl-nicks)

Nothing useful in *Messages*, even after using debug-on-error

[bradwright]

For extra reference this is my entire ZNC configuration:

https://github.com/bradleywright/emacs-d/blob/master/modes/znc.el

I'm also having some trouble with this... I had erc-highlight-nicknames working in Emacs23 but I recently upgraded to Emacs24 and thought I'd give ERC another go, but neither erc-highlight-nicknames nor your erc-hl-nicks seems to work at all.

Is there any setup beyond (require 'erc-hl-nicks) and then adding hl-nicks to the erc-modules list?

On further investigation, it's not just hl-nicks... in fact ERC wasn't displaying any faces at all... and this was caused by interference with global-whitespace-mode. Turning off whitespace makes ERC colors show up (no other major modes that I use have color problems because of that... Any thoughts on how I might enable global whitespace mode globally, but disable it per-ERC buffer?

[leathekd]

Interesting, thanks for the info! I was never able to reproduce this issue, perhaps this was what I was missing. I'll look into whitespace mode.

In the meantime, I believe you can use M-x whitespace-mode to disable the mode for a particular buffer. I could be wrong though. I'll update when I know more.

[leathekd]

uh, wow. I just enabled global-whitespace-mode and it stripped all of the faces from an existing erc buffer.

[leathekd]

Ok, I don't yet have a clue what whitespace-mode is doing to ERC buffers, but adding this to my init.el and restarting (or eval this and then close and reopen all ERC buffers). Apparently whatever whitespace-mode does is permanent, simply turning it off didn't allow new entries to be colorized.

(setq whitespace-global-modes '(not erc-mode))

Ah yeah, that is working now, thanks. Looking back, my issue was probably different than what the original reporter was experiencing. Sorry for the spam!

[leathekd]

No problem. The issue may yet be related. At least this is the only time I've seen any text in an ERC buffer with just the default face. Even text that isn't highlighted should have erc-default-text as its face.

Not to mention: https://github.com/bradleywright/emacs-d/blob/master/modes.el#L290

:)

Thanks.

[leathekd]

Hey, @bradleywright I don't know if you were emailed about this, but there is a potential workaround to the issue you were seeing above.

[bradwright]

Ah awesome, thanks for bumping!