<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Nico has answered the main question in your e-mail, and if you're interested in the topic, I encourage you to find and read the thread, he quoted.</div><div class="gmail_quote">
<br></div><div class="gmail_quote">I'd also like to comment on some specific points in your e-mail.</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Wed, Nov 20, 2013 at 8:53 PM, Arthur O'Dwyer <span dir="ltr"><<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm being nosy here, but... What's the rationale for having<br>
clang-format understand Java syntax, when libclang itself doesn't<br>
claim to understand Java?  It seems like a *prerequisite* for this<br>
kind of work is to implement a Java parser... and is that really a<br>
goal of the Clang project?<br></blockquote><div><br></div><div>Clang-format doesn't use libclang, which is a C interface to Clang. Clang-format also doesn't use Clang's parser. The only thing we use, is Clang's lexer, and all the parsing (quite relaxed, so it can be used on almost anything resembling valid C/++/ObjectiveC/++ code) is done by clang-format itself. So in order for clang-format to format a language, there's no need for Clang's parser to understand it.</div>
<div><br></div><div>This patch implements formatting of some JavaScript constructs, not Java (though, we have plans to support Java). We'll probably need to change Clang's lexer to support some of the JavaScript syntax features (e.g. regular expression literals), but only if this is easier to do in the lexer, and if it doesn't affect its performance.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Java also has many keywords that aren't in C++ (yet), such as<br>
"abstract", "extends", "final" in weird* positions, "finally",<br>
"import", "native", "package", "throws", "transient"... and the "<<<"<br>
and ">>>" operators. You're not planning to hack up clang-format with<br>
ad-hoc cases for *all* of these, are you?<br></blockquote><div><br></div><div>Keywords are usually not a problem, as they can frequently be treated as identifiers. Clang-format has a very relaxed parser, so it doesn't need to understand much of the language it formats.</div>
<div><br></div><div>As for the operators not present in C++, this is what we can (and we'll have to) add support for on the side of clang-format, without touching the lexer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Who's using clang-format on Java code, and why?<br></blockquote><div><br></div><div>I don't think someone uses clang-format for Java and JavaScript code extensively, as we don't support these languages yet. But we have requests to support them from people, who are not satisfied with other existing formatters.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
–Arthur<br>
<br>
[* – By which I mean "saner than C++11's syntax", of course. :) ]<br>
<div class="HOEnZb"><div class="h5"></div></div><br></blockquote><div><br></div><div>-- </div><div>Regards,</div><div>Alexander </div></div>
</div></div>