dbordak / telephone-line

A new implementation of Powerline for Emacs
GNU General Public License v3.0
554 stars 51 forks source link

Telephone-line fails to display evil-state segment for custom states without appropriate face #87

Open ogdenwebb opened 6 years ago

ogdenwebb commented 6 years ago

For example, there's some plugins for Emacs which provide custom evil-state, such as evil-multiedit, but telephone-line doesn't have appropriate face for them, so mode-line won't display anything.

;; with 
(evil   . (telephone-line-evil-tag-segment))
;; *Messages* buffer
Error during redisplay: (eval (telephone-line-add-subseparators (quote (#[257 "\304\300!\205I\0\205I\0\305 \204\0\306 !\226\202;\0
\307=\203(\0\203$\0\310\202;\0\311\202;\0
\312=\203:\0\2036\0\313\202;\0\314\202;\0\315\203F\0\316\317\"\202G\0\211\262\207" [evil-mode evil-state evil-visual-selection telephone-line-evil-use-short-tag boundp evil-visual-state-p symbol-name block "VB" "V-BLOCK" line "VL" "V-LINE" "VISUAL" seq-take 2] 5 "

(fn FACE)"])) telephone-line-abs-hollow-left (quote evil))) signaled (wrong-type-argument sequencep telephone-line-evil-multiedit)
Error during redisplay: (eval (telephone-line-separator-render telephone-line-halfsin-left (telephone-line-face-map (quote nil)) (telephone-line-face-map (quote evil)))) signaled (wrong-type-argument sequencep telephone-line-evil-multiedit)

Probably telephone-line needs a fallback face for this case.

dbordak commented 6 years ago

You can probably just define a face with that name in your own config file and it'd work.

I could add a fallback, but then I'd either need to spam the message buffer with warnings or ignore it entirely, and I definitely don't want to do the latter since it'd hide the fact that there's a better solution.

ogdenwebb commented 6 years ago

You can probably just define a face with that name in your own config file and it'd work.

Yes, I know that. Meanwhile in my opinion, it's a bit kinky workaround, because I need define face for every single custom state to omit this issue in the future.

dbordak commented 5 years ago

(...) I need define face for every single custom state (...)

FWIW, this is how I think it should be. It's annoying, but it's not like you have programmatically created states.

If there are any of these that are sufficiently popular I could just add them to the package. I don't use any myself, though.

sebasmonia commented 5 years ago

An intermediate solution...could be providing a macro that defines faces for custom states + adds them to the config. So, a helper for the users, documented. But you would still have to define the face.

I agree that using a fallback is not a good idea.

countvajhula commented 5 years ago

What's the reason for opposing a default face if there isn't one specified for the state? If it is the need to have messages to indicate this to the user, I'm not sure that would be necessary since defining custom states is a supported and documented feature of evil.

At the moment when this case is encountered, (1) telephone line breaks and dumps error output to the messages buffer (2) the user must go down to elisp land to fix it.

IMO the alternative for a custom state of defaulting to a sane face with just the name of the state would be preferable. If the user would like to customize the face then they certainly can (as is well-documented in telephone line), but they need not be forced to do so to get basic functionality, which is often all they need.