rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2754255056
@dweiss I also wonder, with an "autoformat" workflow, if we even care so
much.
I don't understand what is so sacrosanct about google's format: to me it is
ugly. Snippet tag is
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755082414
I've toyed with it a bit but I don't see a way for it to not break those ///
comments. An alternative is to fork it, fix what we need and then use the
forked version from spotless. T
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2758276309
You're right - this may be a problem. I use intellij and even gjf there does
not work exactly the same way
(https://github.com/google/google-java-format/pull/1165). I stopped caring
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2757832416
awesome! I really hope the patch is accepted: this will definitely give us a
path forward.
--
This is an automated message from the Apache Git Service.
To respond to the message, p
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2757929583
yeah: only thing I will say about choice of formatter is that normally I try
to configure the editor in the repo to match what the build expects. e.g. for
languages like python and ty
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2757854863
Let's wait a few days and see if there's any feedback. Like I mentioned
above, what we use for formatting/checking format adherence shouldn't really
matter for anybody who uses grad
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2756947753
[here's the gjf issue I asked for the direction they'd like to
follow](https://github.com/google/google-java-format/issues/1193)
--
This is an automated message from the Apache Git
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2756943569
It'll work with those indented lines as well - it actually will align block
indentation to the column they should be starting at. So:
```
/// [Collector] for cutter+recorder
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755678098
Here is what I did.
* added a brute-force non-formatting to any /// line comments in my fork of
google-java-format [1]
* added a local, precompiled binary of the above to my for
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755707979
@dweiss very nice. the `///` can have leading whitespace in front of it
which is preserved too. I dont know how their parser works but you can simulate
the leading-case by adding a me
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2754350593
We'd probably have to apply reformatting to 10x and main to keep cherry
picking easier. Other than that - it's a simple thing to do.
--
This is an automated message from the Apach
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755137112
Yes, that's correct -
https://github.com/google/google-java-format/issues/1153#issuecomment-2344790653
--
This is an automated message from the Apache Git Service.
To respond to th
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755128619
Yeah. I'll take a look at that, interesting. Part of the problem is that
different Java versions seem to be returning a different tokenization of those
comment strings. Seems like so
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755132797
@dweiss I think that is because google-java-format uses internal JDK
compiler apis to parse it. just like error prone. it is why you have to add all
the opens?
--
This is an automa
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755105202
@dweiss I'm wondering if we could send them a PR such that any `///` line
comment respects the `--skip-javadoc-formatting` flag (or some other flag to
say "dont mess around"). it woul
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2755090672
https://github.com/google/google-java-format/blob/master/core/src/main/java/com/google/googlejavaformat/java/JavaCommentsHelper.java#L46-L60
All it takes would be to preserve a
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2754226935
I played with this a bit and reduced noise in two ways:
Original file:
113 files changed, 3656 insertions(+), 5216 deletions(-)
1. Disable reformatting of Apache
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2754343679
> I just think autoformat the code in a consistent way, call it a day.
I agree, it does not matter which one you pick if it's an automated process.
> I don't understand
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2754358922
I will play with the "don't reformat javadoc option". Maybe it's an easier
solution to these problems? If we can coerce Google formatter to treat `///` as
javadoc then problem solved.
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2754235469
For the record those diffstats were based on `./gradlew -p lucene/suggest
spotlessApply` and include the changes of the patch/formatter XML itself
--
This is an automated message fr
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2751009070
@dweiss thank you so much for that starter commit for evaluation. I will try
it tonight and fire up eclipse and see what our options are.
I finally finished parser (https://gith
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2751317728
https://github.com/google/google-java-format/issues/1193
> Disabling Javadoc formatting doesn't prevent either issue.
So it seems it's broken entirely. Argh.
--
This is an
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2751070467
I think in the markdown case, the bug I saw was that it didn't treat `///`
as javadoc but as an ordinary inline comment. But I can experiment with the
option still.
--
This is an a
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2751059970
Nice!
So... google java format has this option, at least in the cmd line version:
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2750242048
It's close but there are many differences. See the commit above and try
running it on one of the modules, for example suggest (./gradlew -p
lucene/suggest spotlessApply).
Mayb
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2749828583
@dweiss what do you think about exploring the option to swap out spotless
`java.GoogleJavaFormatStep` with `java.EclipseJdtFormatterStep` but using
google-java format config:
https:/
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2749834480
The Palantir one is no better off from what I can tell, it is a fork of the
google one with some cosmetic tweaks. I know eclipse JDT doesn't choke on these
constructs, although I don'
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2667192244
The markdown would have a huge advantage for the many analyzers with
xml-style prettyprint docs today. I don't think `@snippet` works with languages
other than java.
For me, ed
rmuir commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2667156816
Related: if we bump main to java 23+
(https://github.com/apache/lucene/issues/14229) then we could do snippets in
javadoc with the typical markdown mechanisms.
--
This
dweiss commented on issue #14257:
URL: https://github.com/apache/lucene/issues/14257#issuecomment-2667110544
https://github.com/google/google-java-format/issues/789
https://github.com/google/google-java-format/issues/886
Unfortunately, I think these make this issue a no-go to unles
30 matches
Mail list logo
