iczelia

Results 68 comments of iczelia

Letting Jesus.JS in hell is like letting JavaScript in production. Oh...

I don't have a cygwin setup handy and likely won't have one for a while. A PR that reliably adds cygwin support to the `#ifdef` chain in `common.h` is more...

Workaround: add `repl.history_add("");` before any invocation to `input`. Might break when you log repl history somewhere, but it's not the case for me.

I get the same stacktrace: ``` java.lang.NullPointerException at org.antlr.intellij.plugin.parsing.ParsingUtils.parseText(ParsingUtils.java:206) at org.antlr.intellij.plugin.ANTLRv4PluginController.lambda$parseText$3(ANTLRv4PluginController.java:448) at com.intellij.openapi.progress.util.BackgroundTaskUtil.lambda$computeInBackgroundAndTryWait$6(BackgroundTaskUtil.java:171) at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$runProcess$2(CoreProgressManager.java:189) at com.intellij.openapi.progress.impl.CoreProgressManager.lambda$executeProcessUnderProgress$12(CoreProgressManager.java:608) at com.intellij.openapi.progress.impl.CoreProgressManager.registerIndicatorAndRun(CoreProgressManager.java:683) at com.intellij.openapi.progress.impl.CoreProgressManager.computeUnderProgress(CoreProgressManager.java:639) at com.intellij.openapi.progress.impl.CoreProgressManager.executeProcessUnderProgress(CoreProgressManager.java:607) at com.intellij.openapi.progress.impl.ProgressManagerImpl.executeProcessUnderProgress(ProgressManagerImpl.java:60) at com.intellij.openapi.progress.impl.CoreProgressManager.runProcess(CoreProgressManager.java:176) at com.intellij.openapi.progress.util.BackgroundTaskUtil.lambda$computeInBackgroundAndTryWait$7(BackgroundTaskUtil.java:170) at...

Originally discovered by https://github.com/mrbenjadmin - I do not use MacOS and am reporting the issue on his behalf.

@bobbylight I found a workaround! Turns out that you have to reset the font _in the styles_, not only just call setFont on the RSTA: ```java scheme.restoreDefaults(IDE.aplFont, false); ``` It...

One way to prevent this situation from happening would be immediately testing the file using `bzip3 -t` to determine if the compressed size matches the decompressed size.

OK. It seems like the version in the CMake build instructions is hardcoded, but I am not entirely sure how to make it update with the tag. @sorairolake @alerque -...

Yes, we can hardcode the version, but it's not sustainable.

I will try to retrofit https://github.com/antoniovazquezblanco/cmake-gitversiondetect for this purpose later. That said, I have never used CMake before :-).