milkypostman
powerline under emacs 23.3.1 - ? "looping at generating new separator ..."
I am using emacs 23.3.1, somehow when using default theme, the minibuffer kept displaying "generating separator ..." is this a bug?
I am running on chromebook with ubuntu under crouton - so no much room for me (if it's due emacs 23) unless I would compile emacs 24 on this complex setups. thanks
It should only generate a separator 4 times. there is another person that has been having this similar problem on another machine.
Regardless, If it's ubuntu you should be able to use the PPA for Emacs 24.
I'm wondering if this is a linux problem. I haven't had much time to track down the error because I cannot reproduce it.
On May 3, 2013, at 15:52, Isaac Pei [email protected] wrote:
I am using emacs 23.3.1, somehow when using default theme, the minibuffer kept displaying "generating seperator ..." is this a bug?
I am running on chromebook with ubuntu under crouton - so no much room for me (if it's due emacs 23) unless I would compile emacs 24 on this complex setups. thanks
— Reply to this email directly or view it on GitHub.
I have the same problem using Emacs 24 (a current bzr clone). When the powerline is enabled, I have just a blank mode-line, and it seems every few commands (like buffer switching, or when a window's vscoll changes) I get the aforementioned message, and this error is printed in Messages (reformatted for better readability).
generating new separator
Error during redisplay:
(eval (let* ((active (powerline-selected-window-active))
(mode-line (if active (quote mode-line) (quote mode-line-inactive)))
(face1 (if active (quote powerline-active1) (quote powerline-inactive1)))
(face2 (if active (quote powerline-active2) (quote powerline-inactive2)))
(separator-left (intern (format "powerline-%s-%s"
powerline-default-separator
(car powerline-default-separator-dir))))
(separator-right (intern (format "powerline-%s-%s"
powerline-default-separator
(cdr powerline-default-separator-dir))))
(lhs (list (powerline-raw "%*" nil (quote l))
(powerline-buffer-size nil (quote l))
(powerline-buffer-id nil (quote l))
(powerline-raw " ")
(funcall separator-left mode-line face1)
(powerline-narrow face1 (quote l))
(powerline-vc face1)))
(rhs (list (powerline-raw global-mode-string face1 (quote r))
(powerline-raw "%4l" face1 (quote r))
(powerline-raw ":" face1)
(powerline-raw "%3c" face1 (quote r))
(funcall separator-right face1 mode-line)
(powerline-raw " ")
(powerline-raw "%6p" nil (quote r))
(powerline-hud face2 face1)))
(center (list (powerline-raw " " face1)
(funcall separator-left face1 face2)
(when (boundp (quote erc-modified-channels-object))
(powerline-raw erc-modified-channels-object face2 (quote l)))
(powerline-major-mode face2 (quote l))
(powerline-process face2)
(powerline-raw " :" face2)
(powerline-minor-modes face2 (quote l))
(powerline-raw " " face2)
(funcall separator-right face2 face1))))
(concat (powerline-render lhs)
(powerline-fill-center face1 (/ (powerline-width center) 2.0))
(powerline-render center)
(powerline-fill face1 (powerline-width rhs))
(powerline-render rhs))))
signaled (wrong-type-argument arrayp unspecified)
Debugging this a bit more, the error actually comes from pl/hex-color, and the problem is that it (and pl/interpolate) sometimes get called with the undefined color. The attached patch fixes the issue. However, I'm not sure if using the default foreground color is the right choice in that case. Maybe the default background color is what you intended?
The patch: https://gist.github.com/tsdh/5531651
This is interesting. From my recollection the interpolate should never get called unless both colors are specified.
I'd be curious to figure out why its getting called with no color in the first place.
Things are busy today but I should have some time tomorrow. Hopefully I can take a look at this then.
On May 7, 2013, at 5:19, Tassilo Horn [email protected] wrote:
Debugging this a bit more, the error actually comes from pl/hex-color, and the problem is that it (and pl/interpolate) sometimes get called with the undefined color. The attached patch fixes the issue. However, I'm not sure if using the default foreground color is the right choice in that case. Maybe the default background color is what you intended?
The patch: https://gist.github.com/tsdh/5531651
— Reply to this email directly or view it on GitHub.
so it seems like there is a deeper problem here.
in the pl/wrap-defun function, it is testing if there are two faces passed to the separator function and that color doesn't even get called.
anyways, there is only one line where interpolate is called (line 141 in powerline-separators.el),
(if (and face1 face2) (pl/interpolate color1 color2) "None")
And you can see that it doesn't even try to call interpolate unless both faces are defined.
So are the faces we're dealing with here not defining a background color???
Is there a specific theme you're working with and possible mode-line or mode-line-inactive that might not be defining a background color?
@tsdh WOW wait, are you like the tsdh wro created tsdh-dark/tsdh-light from the Emacs default themes?
also, last question: is it undefined or is it nil? because one thing we could do is check that what hex-color provides back is non-nil in the separator functions and use None if it's nil.
@milkypostman Yep, that's me. Do you like them?
I use the current tsdh-dark theme from emacs bzr, and there I get:
(face-attribute 'mode-line :background) ;=> unspecified
(face-attribute 'mode-line-inactive :background) ;=> unspecified
Ups, so it's actually the symbol unspecified, not undefined (and neither nil).
ahhhhhhhhhhhhhh
this makes complete sense. but it's silly that this returns unspecified and not nil
I am committing 82a4f33 and a9c559e
and they seem to now work with your themes
@tsdh yes I do like your themes. Especially the weird borders on some of the things.
except that variable width fonts in the modeline tend to mess up right-aligned text because I don't know how, when re-rendering the modeline, to calculate how much space the left side will take up, well, actually I need to know how much space the right side will take up.
Great.
Hm, I have no idea about space calculation with variable width fonts...
BTW: Your commits solved the issue for me. Thanks!
frame-char-width is a built-in function but it doesn't allow you to specify the font.
I have the latest powerline from melpa and I do see endless "pl/ generating new separator" messages. My emacs-version is "GNU Emacs 24.3.50.1 (x86_64-w64-mingw32)\n of 2013-06-10 on ALIMANTADO"
this is all very weird, hopefully someone can help out with this because I am unable to really figure out what is causing this problem.
On Sat, Jun 29, 2013 at 3:26 PM, Alex Vorobiev [email protected]:
I have the latest powerline from melpa and I do see endless "pl/ generating new separator" messages. My emacs-version is "GNU Emacs 24.3.50.1 (x86_64-w64-mingw32)\n of 2013-06-10 on ALIMANTADO"
— Reply to this email directly or view it on GitHubhttps://github.com/milkypostman/powerline/issues/31#issuecomment-20238325 .
I had a similar problem, looks like it doesn't like 3 character hex values for some things. I was getting args out of range for #111, changing it to #111111 allowed it to work.
So the theme settings are causing this? It seems like this should be an easy thing to check for?
On Mon, Aug 5, 2013 at 1:28 PM, atom [email protected] wrote:
I had a similar problem, looks like it doesn't like 3 character hex values for some things. I was getting args out of range for #111, changing it to #111111 allowed it to work.
— Reply to this email directly or view it on GitHubhttps://github.com/milkypostman/powerline/issues/31#issuecomment-22138557 .
Seems like pl/interpolate to me. It is trying to work with 6 character strings but 3 character strings should be valid. Probably should attempt to expand shorthand before parsing there? If it is a 3 character string duplicate each? #0F9 => #00FF99
Yeah that's probably it. By chance would someone want to send a pull request?
On Monday, August 5, 2013, atom wrote:
Seems like pl/interpolate to me. It is trying to work with 6 character strings but 3 character strings should be valid. Probably should attempt to expand shorthand before parsing there? If it is a 3 character string duplicate each? #0F9 => #00FF99
— Reply to this email directly or view it on GitHubhttps://github.com/milkypostman/powerline/issues/31#issuecomment-22140881 .
Might be nicer to use color-values here as well. I might have time to do this later, but not sure.
I just went ahead and removed the message. I think the message itself was causing the message to reappear. Basically by doing a message I was asking emacs to update the modeline which then cause another message recursively. At that point its hard to say how emacs would deal with it.
I also cleaned up the color functions in cf70809587926368779155536b28bc17382d6795
Please close if this works.
I'm still affected by this issue. Are there any further developments regarding the message loop?
How are you still effected? The message is no longer in the codebase...
On Tuesday, September 10, 2013, Jelle Licht wrote:
I'm still affected by this issue. Are there any further developments regarding the message loop?
— Reply to this email directly or view it on GitHubhttps://github.com/milkypostman/powerline/issues/31#issuecomment-24157392 .
A bit late (4 months!) but the unspecified thing is a defface convention. (unspecified == nil)
