Fork me on GitHub
#lein-figwheel
<
2016-12-16
>
talexxx00:12:43

That’s weird, the file is definitely in :source-paths

talexxx00:12:50

The file the macro is reading is in resources, though

talexxx00:12:08

Is it a good idea to duplicate resource paths in source-paths?

danielcompton03:12:45

@talexxx: figwheel isn't smart enough to know to recompile a macro when data that that macro read changes

curlyfry11:12:14

@bhauman Is there a way to auto-expand the code part of the heads up display? I find that I always have to hover to see the code where something actually went wrong

hlolli13:12:21

anyone aware of a possible cause of figwheel slowing down. Im using emacs and now when I save my cljs files, a spinner shows up for a minute. This happened to my colleague recently, to my surprise now me too. Not sure if new emacs version or new figwheel is the cause here. Using sidercar-api btw.

hlolli14:12:39

ok, in my case Im not sure if figwheel is to blame, running it on seperate terminal causes emacs still to be slow to save the file and sometimes ever crash. So I leave my question as unvalid for now.

bhauman14:12:14

@curlyfry I don't understand the behavior that you are talking about. If I am understanding you. The code context pointer part of the heads up display should always be visible. If it's not visible then you may have a bad CSS interaction. If I'm not understanding you perhaps a Screenshot would help?

curlyfry15:12:08

@bhauman It was definitely a bad css interaction, kind of embarrassing... Thanks! 🙂