Disable unicode if not available

[Abergard]

Hi, what about replacing ⇒ by -> if Unicode is not supported? It could by done by custom variable or whatever to set by users.

[raxod502]

It looks like @ikirill is no longer interested in this project. In my fork of irony-eldoc, Unicode is disabled by default and there is a defcustom to re-enable it.

[ikirill]

I merged @raxod502's commit in 0526b60ba09526c1f5d068f70ffdef67bc46a62b

[raxod502]

Oh cool! Thanks. Now that I look back on this, I guess it would be better to determine the default value of irony-eldoc-use-unicode based on char-displayable-p. Something like this:

(defcustom irony-eldoc-use-unicode
  (and (char-displayable-p "∷")
       (char-displayable-p "⇒"))
  "If non-nil, use Unicode characters ∷ and ⇒ instead of :: and
=> in eldoc messages."
  :group 'irony-eldoc
  :type 'boolean)

I can make a pull request if you'd like.

[ikirill]

@raxod502 On one hand, that's possible, but on the other hand: is that really even necessary?

char-displayable-p's doc says it's per-frame, would that matter?

Also, its doc says Since fonts may be specified on a per-character basis, this may not be accurate. I don't know exactly what that means, but it doesn't sound nice. My opinion would be to leave it as is.

[raxod502]

Actually, I just checked and my terminal-bound Emacs does report non-nil for char-displayable-p with those characters, but they still don't display well due to spacing issues. So I agree that this function is not a good indication of whether Unicode is really supported. Best to stick with a safe default. (I guess maybe checking (display-graphic-p) would be a reasonable way to do it, though.)

[ikirill]

I suspect display-graphic-p would then lead you to the wrong negative conclusion whenever the terminal draws the symbol correctly, with the right spacing, or the font defines the symbol with a spacing that's acceptable to you and the terminal. It's a bit of a rabbit hole, as far as I can see.

[ikirill]

In any case, thanks!