Yeah, that's one of the parser-related wishes I saw for a few time. I heads it's also possible with JavaCC. This would be also very useful for IDE plugins (the current Eclipse plugin only marks the first error). Anyway, when we get to the template language issues, we shall see what direction that will take (like if the parser will be quite different anyway).
Friday, January 13, 2017, 12:37:55 AM, Jaime Garza wrote: > It would be awesome if the parser was able to recover on error and > return multiple errors, instead of the first one. Perhaps you may > need to use a bottoms-up parser instead of javacc. My customers > complain that they need to try the “run” (I use a preview mode > actually) multiple times if they have multiple errors. > > Jaime > >> On Jan 12, 2017, at 3:10 PM, David E Jones <d...@dejc.com> wrote: >> >> >> These look good to me. Always feels good to clean out old and unneeded code. >> :) >> >> -David >> >> >> On Thu, 2017-01-12 at 23:58 +0100, Daniel Dekany wrote: >>> I have collected some further easy changes for FM3... Any comments? >>> >>> - Drop FTL classic compatible mode option (Roughly emulates FM1 >>> behavior at null-s and at some type handling issues) >>> >>> - Drop FTL non-strict syntax option (FM1 syntax - that's where you >>> could write <if x> instead of <#if x>). >>> >>> - Drop all the "public static void main(String[] args)" methods (security >>> concern) >>> >>> - Drop freemarker.log. That's a simple log adapter facility from the >>> ancient times of Java, kind of like commons-logging or slf4j. I >>> would instead introduce slf4j-api as a required dependency. >>> >>> - Drop legacy XML wrapper (freemarker.ext.xml, not to be confused with >>> freemarker.ext.dom) >>> >>> - Drop ant task (freemarker.ext.ant) >>> > > -- Thanks, Daniel Dekany
