Error during redisplay: [...] signaled (wrong-type-argument sequencep unspecified) #66
Comments
shackra
added a commit
to shackra/emacs
that referenced
this issue
Apr 14, 2018
|
This is my current telephone-line configuration https://github.com/shackra/emacs/blob/master/configuracion.org#telephone-line |
|
Could you try commenting out your segments (so you only run one at a time) to narrow it down? |
|
If I comment all my segments ( |
|
I just tried with the following config (I added a dummy defun since I don't have one of your functions), I don't get any errors: I do see that the entire config uncommented is filling the message buffer, though, so I'll see if I can find out what's going on |
|
Ok, looks like it's somewhere in |
|
oh wait, sorry, I forgot like two other Yeah, I don't get any errors with that config... I'll add the actual definitions of those functions next |
|
weird. You can grab the defined functions from my configuration thou https://github.com/shackra/emacs/blob/master/configuracion.org#utilidades-1 In my case, as stated on previous comments, if I left telephone-line-* variables untouch the error stills happen, is weird that you don't catch anything. |
|
Just redefine |
|
Just ran it with this config, no errors... |
|
I guess I've gotta go into the less code-y questions: When did this start happening? thats all I can think of at the moment... Or maybe try clearing your elpa cache? |
|
(Confusion) it's such a terrible shame. 🎶 And you ran it in such a way that that
Hard to say since 90% of the time I use Emacs as a daemon and connect to it with emacsclient, such usage does not reproduce the bug, running Emacs normally does.
GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
GNU/Linux; Arch Linux to be more precise
I feel really tempted to do that, actually. BRB. |
;)
Oh, I missed that part of it, but no I don't usually run it as a daemon. Does it perhaps only happen if you run emacs normally while a daemon is already running? ...and I'm also on Arch, so no problems there :P |
|
Just tried running your config, still not seeing anything... (although, damn, it took forever to install, you have a lot of packages :P) |
|
I'm back! After deleting ~/.emacs.d/elpa and starting Emacs the error stills happens:
Well, this time the daemon was not running and the error popped anyway, so is safe to discard that.
lol! I was going to ask if trying to use a face not defined in Emacs could cause some sort of error in Emacs thus making telephone-line barf all over *Messages*, but since you report no issues with my exact same configuration on exactly the same flavor of GNU/Linux then we can discard that as root cause too. I was going to suggest that maybe something was running in my conf when Is there a way for telephone-line to report errors more precise? Like adding a function that can change some internals and upon executing such command we can get something on *Backtrace*? This may sound naive but I'm sure you cannot do much with something that looks almost like hexadecimal code. |
|
BTW, this is how the mode-line looks at the right side when the error happens:
And this is how it looks when emacs is ran as a daemon, no error happens because of that and I connect to it with emacsclient:
|
|
Hm... If you try running one of the commands that errored out, what do you get? For instance, I just tried evaling |
|
Also, as for the spacing on the right, is it because the broken one is missing subseparators, perhaps? Is that gap at the end the same width as the missing subseparators? |
I got this on |
I... I don't know? it seems it is of the same size as a separator. |
|
That command output is correct. That doesn't make any sense; when you run the command manually, it works, but when it runs on the modeline it doesn't work? |
|
Maybe is when Emacs startups that it fails because the barfing of telephone-line occurs once instead every time redisplaying(? the mode-line is required, thus why the output is correct for me. |
|
BTW, I cannot reproduce the bug on Windows with Emacs from MSYS2. |
|
Could you try starting from a fresh This is really confounding at this point; the situation that causes this bug is really unclear... |
|
With following minimal configuration I'm unable to reproduce the bug on Archlinux: |
|
This being the case, I may move my elisp to |
|
I temporally moved my configuration into But honestly this does not tell me anything useful, maybe you have better eye than me. |
|
While using bug hunter on my configuration I notice my orange face in the separator at the same place the artifacts occurred as reported 8 days ago.
|
|
While at my bug hunt session, I was able to reproduce an error from the code Also, using the following assertion code: I ended with the exact same result. |
|
If I comment one section of my |
|
Having the bug reproduced despite the fact I comment the entire content of my |
|
I still have the visual artifact at the right side of the frame though EDIT: after getting rid of my |
shackra
added a commit
to shackra/emacs
that referenced
this issue
Apr 28, 2018
Evita desorden y la posibilidad de fallos en la configuración, aumenta el control sobre la configuración. - dbordak/telephone-line#66 - felipeochoa/rjsx-mode#68
|
Ah, I can explain at least part of this -- the function that renders separators uses the Clearly you still had an inherited background property, though, so maybe I'm not pulling the trait correctly? or maybe that custom was set incorrectly? |
|
I can confirm this. I hit the same problem with my custom segment where the segment was assigned its face via a function. One of the faces that could be returned from this function did not have an explicit :background property (but it had an implicit via :inherits mode-line which did not help). Once I explicitly set a :background property for all faces that could be returned from the function Messages buffer became quiet. This is a bit anoying since then I can not color the segment with the same background color as the mode line but with a different foreground color. :( Is this possible to fix with a reasonable effort? E.g. checking if the face have a :background property and if not do something "intelligent"? Note: My custom segment was between "ryo" and "accent" segments, thus NOT adjacent to a nil segment. |
|
Forget the note. I mixed up faces definition with segment definition. :( |
|
may can you post the related code? |
(defface fnord-telephone-line-base
'((t (foreground "black" :weight bold)))
"Meta-face.")(defface fnord-telephone-line
'((t (:foreground "white" :inherit (mode-line fnord-telephone-line-base))))
"Fnord face.")(defun fnord-telephone-line-modal-face (avtive)
"Select face to use based on ACTIVE value."
(cond ((not active) 'mode-line-inactive)
(t 'fnord-telephone-line)))(telephone-line-defsegment fnord-telephone-line-segment ()
"Displays current fnord state."
(when (bound-and-true-p prog-mode)
(propertize "Fnord"
'face 'telephone-line-unimportant
'help-echo "Fnord!")
))(setq telephone-line-faces (quote ((evil . telephone-line-modal-face)
(modal . telephone-line-modal-face)
(ryo . telephone-line-ryo-modal-face)
(accent . (telephone-line-accent-active . telephone-line-accent-inactive))
(fnord . fnord-telephone-line-modal-face)
(nil . (mode-line . mode-line-inactive)))))(setq telephone-line-lhs (quote ((evil . (telephone-line-evil-tag-segment))
(accent . (telephone-line-vc-segment telephone-line-erc-modified-channels-segment telephone-line-process-segment))
(fnord . (fnord-telephone-line-segment))
(nil . (telephone-line-projectile-segment telephone-line-buffer-segment))))) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm seeing these messages on *Messages* buffer and I cannot figure out why the error. No messages are displayed when running emacsclient:
The text was updated successfully, but these errors were encountered: