It would be great to have one... But, as always, the question is, who
will make it. Though there can be a lot of interesting challenges in
this. Some thoughts bellow...

Doing anything with the parser in FM2 can be sometimes frustrating, as
the syntax is not uniform (each directive has its own syntax
technically, even if they look similar), and has several glitches that
can't be fixed for backward compatibility. So if someone reimplements
parsing, they should emulate them. It's possible, but I guess not very
motivating for contributors.

FM3 is much more rewarding. As we are free from backward compatibility
there, the syntax will be much more uniform (almost no
directive-specific syntax for example - the set of core directives
should come from outside the parser).

Furthermore, ideally, in FM3 the parser should become composable from
a "top-level language" (like `<#name exp, exp, ...>`, `${exp}`, etc.)
and an expression language syntax (like `obj.m()`, etc.). That's
mostly so that we can have multiple top-level languages (like <#> VS
[#] without ugly parser hacks, but even a very different,
Velocity-like or WebMacro-like syntax). Multiple expression languages
also have potential of course. But, JavaCC doesn't support dynamically
composing syntaxes. I have seen some hacks for that though. Or we can
generate multiple cc files. Neither of these are ideal, so even
returning to hand written parsers (if not lexers) is a possibility.
I'm not yet sure what the best approach will be. Any advice is

Of course, parsing for IDE-s is certainly separate from the parser
that's used in production (speed and result size is more important for
the last). Especially for a template language, because parsing in
IDE-s should also parse HTML, XML, or whatever you generate in that
template. There you certainly want to reuse the web page
(HTML+JavaScript+CSS) editing facility that already exists somewhere
else. (For those who don't know this kind of thing, see the PHP editor
of Eclipse, or, I guess, the AngularJS editor.) Not sure how that goes
with a language server.

Any research, especially with some working demonstartion, is highly
welcome in the above areas. I think it's a fun topic, especially in

Monday, February 19, 2018, 11:42:41 AM, Angelo zerr wrote:

> Hi,
> I tell me if Freemarker could provide a Freemarker Language Server.
> Today the main IDE (Eclipse, intellij, etc) , Editors code (VSCode, Atom,
> Sublime, Vim,etc) provides a LSP support
> to
> manage completion, hover, hyperlink, etc in their editor for any language
> (HTML, JSON, Java, TypeScript, JavaSCript, CSS, etc) which provides a the
> language server.
> I think it should really fantastic if Freemarker could provide this same
> feature with a "Freemarker Language Server" like JDT Java does it
> The Freemarker Language Server could maintain FTL files of the project in
> memory in  Template structure which can be updated with a none valid FTL
> content (when user change the content of the editor).
> But today we cannot use the Template structure for the  Freemarker Language
> Server, because:
>  * the FMParser is not tolerant. So if you try to parse a FTL content which
> is not valid (ex : a <#if which is not closed), the parser throws an error.
>  * the Template structure cannot be updated with a "replaced content". It's
> not a blocking issue since LSP support "incremental", and "full" kind
> (see TextDocumentSyncKind at
> Regard's Angelo

 Daniel Dekany

Reply via email to