0

I am unable to :delight major mode strings (in the mode-line) from use-package because I am intializing powerline with use-package itself.

My guess is that the :delight'ing part occurs at the wrong time and mode-line-format is set without the updated major mode strings (it works fine if powerline is :disabled).

What is a good approach to solve this issue?

Here is my init-mode-line.el for reference. New link: init-mode-line.el.

  • I don't actually know how the use-package integration works, but I can see in the commented (delight...) form in your link that you are missing the argument :major from each of the major mode declarations. Please refer to the documentation at emacswiki.org/emacs/DelightedModes – phils Feb 26 '16 at 12:53
  • That commented part wasn't being used (some old copy pasta). I use delight in conjunction with use-package which allows us that :delight shortcut: it is used the same way diminish is used. However, as I mentioned, it works pretty fine when I disable the powerline. – Mathieu Marques Feb 26 '16 at 13:17
  • Well you did point to that file "for reference", and that commented block contains the only instance of the word "delight" in the file. Show us the code you're actually trying to use. Showing a version you're not using helps no one. – phils Feb 27 '16 at 1:12
  • As a example, see init-css.el. The issue doesn't live in how I use the keyword :delight but how I set mode-line-format. That's why I only showed init-mode-line.el (updated link). Sorry if this was unclear. – Mathieu Marques Feb 27 '16 at 10:31
2

The short answer is that powerline and delight are not directly compatible; but I've made a change to delight (new version 1.04) to make such integration possible in general, and I've added a delight-powerline library which builds on top of that to handle powerline specifically.

Original answer follows...


Well I tried your config. My first comment is that you seem to be specifying the default mode names in most of your :delight specs, which is kinda weird. e.g. org-mode already uses "Org" as its mode-name -- there's surely very little point in using :delight org-mode "Org".

However I can confirm that delight is still working for major modes with powerline enabled, because if I visit an org-mode buffer and check mode-name it tells me (inhibit-mode-name-delight "Org" "Org") (normally those two values wouldn't be identical, of course, but see above...)

This is delight's way of getting the mode line to show the delighted value without also showing that custom value in other contexts (e.g. M-x describe-mode which also displays mode-name).

This suggests to me that powerline is calling format-mode-line explicitly, which is delight's trigger (via advice) to show the original version of the name. (n.b. It's slightly unintuitive, but format-mode-line is not called by the normal mode-line display code, but provided so that other things can render mode line constructs.)

That's an incompatibility between the two libraries, I'm afraid.

You can disable delight's advice (after it has been loaded) like so:

(ad-disable-advice 'format-mode-line 'around 'delighted-modes-are-glum)
(ad-activate 'format-mode-line)

This will fix your powerline output, but also means that anything else which displays a major mode's mode-name will also show the delighted version. That's probably still preferable for you, though.

Better would be some advice to act only when powerline is being called. This wasn't an option for the standard mode line rendering, but could certainly be done for cases like this.

I've uploaded a delight-powerline.el integration library to the EmacsWiki.

Note that it requires the equally-new version 1.04 of delight.el.

  • I want to have the upper hand on how things look (and thus avoid the - very unlikely - renaming of the modes I use). More than that, having a ready to be customized block for every package (although suboptimal) suits me best :). I have tried your snippet and it does the job, thank you. On a third note, why use defvar + setq for inhibit-mode-name-delight? What's the difference with setq-default only in that case? – Mathieu Marques Feb 28 '16 at 2:11
  • That was because delight.el itself did not declare the variable already. I've resolved that in the updated libraries, though -- see the link in the revised answer. – phils Feb 28 '16 at 2:36
  • Ok, will update ASAP thanks :) it needs a bit of time to be ready for an update through list-packages I guess. But my question was more of an educational purpose: it was working with setq-default only as well. – Mathieu Marques Feb 28 '16 at 2:49
  • Since the introduction of lexical binding, it's good form to defvar all dynamic variables in case they end up being referred to in a library which uses lexical binding. I don't actually know whether setq-local on an undeclared variable will also force it to be dynamic. I had simply noted the issue, and went with the standard approach. – phils Feb 28 '16 at 2:57
  • Oh ok, I see. Thanks for the clarification, and your work on delight.el :) – Mathieu Marques Feb 28 '16 at 3:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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