Re: RFR: 8214856 : Errors with JSZip in web console after upgrade to 3.1.5

Hi Priya, This is not related directly to your change, but why is the JSUtils.getBinaryContent call nested in a $.get()? Is this just to handle errors and check if the zip file is available? It seems like we fetch the zip file twice when we could just test the error argument in the JSUtils.ge

Re: RFR: 8214856 : Errors with JSZip in web console after upgrade to 3.1.5

+1 Hannes Am 05.12.18 um 13:44 schrieb Priya Lakshmi Muthuswamy: oops sorry for the tabs. updated webrev : http://cr.openjdk.java.net/~pmuthuswamy/8214856/webrev.01/ Thanks, Priya On 12/5/2018 5:33 PM, Hannes Wallnöfer wrote: Am 05.12.2018 um 12:52 schrieb Hannes Wallnoefer : A minor

Re: RFR: JDK-8241693, The paragraphs in the help page should not be in a

Jon, The code changes look good, in fact the HelpWriter code looks much better. The improved CSS class names also show nice attention to detail. Visually I notice that the help page now uses less space between lines and therefore appears a bit more „cramped“. The reason seems to be that „ul.b

Re: RFR: JDK-8241693, The paragraphs in the help page should not be in a

Am 31.03.2020 um 18:58 schrieb Jonathan Gibbons : > With respect to the line height, it is hard to know how much the appearance > was intentional, and how much was accidental side effects of setting the > increased line height for some other reason. That being said, Mercurial > annotations to t

Re: RFR: JDK-8241625 use new "member-list" CSS class instead of general "block-list" for list of members

+1 I just realised how much of an improvement this is by understanding how entailed the existing code is. The use of the getMemberTree method with hard-coded CSS class for very different purposes and the resulting HTML were pretty confusing. The new MemberWriter interface and reduction of per-w

RFR: 8240169: javadoc fails to link to non-modular api docs

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8240169 Webrev: http://cr.openjdk.java.net/~hannesw/8240169/webrev.00/ This patch allows using external documentation even if

RFR: 8241982: Make TestSearchScript.java run with GraalJS

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8241982 Webrev: http://cr.openjdk.java.net/~hannesw/8241982/webrev.00/ This makes TestSearchScript.java run with GraalJS in ad

Re: RFR: 8240169: javadoc fails to link to non-modular api docs

-matching modularity“ so it covers both cases. New Webrev: http://cr.openjdk.java.net/~hannesw/8240169/webrev.01/ <http://cr.openjdk.java.net/~hannesw/8240169/webrev.01/> Hannes > Am 02.04.2020 um 16:06 schrieb Hannes Wallnoefer > : > > Please review: > > JBS: https

Re: RFR: 8237383: Members inherited from non-public types are not included in index

Thanks for the review, Jon. I uploaded a new webrev that includes some but not all of your suggestions. I think we should do more in a separate cleanup, especially the one to put IndexItem and SearchIndexItem in a single class hierarchy. http://cr.openjdk.java.net/~hannesw/8237383/webrev.01/

Re: RFR: JDK-8241895 use new "details-list" CSS class instead of general "block-list" for list of details sections

Hi Jon, The changes look good to me. As I said in my previous review, the separation of method and CSS class use is a big improvement. The html.*Writer classes still make be a bit uneasy. Browsing through the classes I found a number of unused methods, but that is not related to your changese

Re: RFR: JDK-8242056,Merge support for AnnotationType builders/writers into support for other types

Wow, that’s a substantial amount of code/classes removed! The code changes and generated docs look good. +1. Hannes > Am 02.04.2020 um 22:37 schrieb Jonathan Gibbons : > > Please review a mostly-cleanup change to merge support for annotation types > into the support for other types, like class

Re: RFR: 8240169: javadoc fails to link to non-modular api docs

gt; it clear which directory structure they are reading source code from. > > If this simple refactoring works, the review is Approved. Otherwise, I'd > like to understand the issues in more detail. > > -- Jon > > > > On 4/3/20 1:38 AM, Hannes Wallnoefer wro

Re: RFR: 8177280: @see {@link} syntax should allow generic types

Jon, I uploaded a new webrev for this issue: http://cr.openjdk.java.net/~hannesw/8177280/webrev.04/ Changes include: - updated test to match changes in HTML/CSS - added @since 15 tag to new DocTrees method - allow parameterised types

Re: RFR: 8240169: javadoc fails to link to non-modular api docs

um 11:42 schrieb Hannes Wallnoefer > : > > Thanks for the review, Jon. > > I agree the test is weird. I had to check it does the right thing with > everything in the same directory. > > I’ll rewrite it to use separate directories as you suggest. > > Hann

Re: RFR: JDK-8242326: use new "summary-list" CSS class instead of general "block-list" for list of summary sections

Hi Jon, I’m not quite sure if we talked about this in one of the previous review threads or maybe on Slack. But I can’t find it now so here we go: With this changeset there are now three get*ListItem(Content) methods in SubWriterHolderWriter, all with the same implementation returning HtmlTre

Re: RFR: 8241982: Make TestSearchScript.java run with GraalJS

elp indicate when a test was skipped for any reason. > > -- Jon > > On 4/2/20 7:57 AM, Hannes Wallnoefer wrote: >> Please review: >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8241982 >> Webrev: http://cr.openjdk.java.net/~hannesw/8241982/webrev.00/ >>

Re: Discussion: Re: RFR: JDK-8242326: use new "summary-list" CSS class instead of general "block-list" for list of summary sections

Jon, +1 for leaving the changeset as it is. For future refactoring, all three options sound reasonable to me. For option 3, I think I would prefer a new subtype such as ListContent rather than doing it behind the scenes. Hannes > Am 13.04.2020 um 18:28 schrieb Jonathan Gibbons : > > It's a

Re: RFR: JDK-8242649 : improve the CSS class names used for summary and details tables

Hi Jon, This isn’t yet a review of the code, just a quick feedback that there is a problem with the generated API docs in Firefox and Chrome. The first column of the overview, module, and package tables does not have the usual alternating background colors, but the darker grey used for the tab

Re: RFR [15] 8224612: javadoc should better handle empty set of doclet options

Hi Pavel, looks good to me. Nice you went the extra mile with random empty set implementation :) Hannes > Am 17.04.2020 um 13:17 schrieb Pavel Rappo : > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8224612: > > http://cr.openjdk.java.net/~prappo/8224612

RFR: 8243388: Moving search result selection clears search input

Please review a trivial javadoc UX fix: JBS: https://bugs.openjdk.java.net/browse/JDK-8243388 Webrev: http://cr.openjdk.java.net/~hannesw/8243388/webrev.00/ API (index page only): http://cr.openjdk.java.net/~hannesw/8243388/api.00/

Re: RFR: JDK-8242649 : improve the CSS class names used for summary and details tables

.openjdk.java.net/~jjg/8242649/webrev.01/ > Api: http://cr.openjdk.java.net/~jjg/8242649/api.01/ > > -- Jon > > On 4/16/20 6:20 PM, Jonathan Gibbons wrote: >> OK, I will look at this tomorrow. Thanks for catching this. >> >> -- Jon >> >> On 4/16/2

Re: RFR: JDK-8242649 : improve the CSS class names used for summary and details tables

> Am 24.04.2020 um 16:43 schrieb Jonathan Gibbons : > > > I'll fix the Table {@code tag. There's a certain irony there, giving this > week's discovery in the jfr code ;-) Indeed :) I’m fine with keeping those methods, just wanted to mention it. Hannes

RFR: 8243562: Make display of search results consistent with color scheme

Please review a simple change to make the highlight color for javadoc search results fit in with the javadoc color scheme. JBS: https://bugs.openjdk.java.net/browse/JDK-8243562 Webrev: http://cr.openjdk.java.net/~hannesw/8243562/webrev.00/ API (index page only): http://cr.openjdk.java.net/~hannes

Re: RFR: JDK-8242532 convert tests to use Text Blocks

Hi Jon, I find that using text blocks increase readability greatly, and the patch looks mostly very good to me. There are a few cases where I am not quite sure about the criteria used to decide whether or not to use text blocks. Nothing too bad but I think these are worth discussing: TestCons

Re: RFR: JDK-8242532 convert tests to use Text Blocks

ome cases with interposed > values, like > "start of message " + value + " rest of message". > > -- Jon > > > On 5/5/20 8:55 AM, Hannes Wallnoefer wrote: >> Hi Jon, >> >> I find that using text blocks increase readability greatly,

Re: RFR: JDK-8245062 HtmlStyle: group and document members for nav, header, summary, details

Hi Jon, Line 198: "Note: the "Summary" information on a module declaration page would be better characterized as "Details" information." Not sure I understand the rationale behind this sentence. It seems the module page is still a summary list that links to details, although the details are on

RFR: 8164408: Add module support for @see, @link and @linkplain javadoc tags.

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8164408 Webrev: http://cr.openjdk.java.net/~hannesw/8164408/webrev.00/ In the process of adding module support to DocCommentParser I switched the code to using ReferenceParser (both classes contained almost identical code to parse doc

Re: RFR: 8164408: Add module support for @see, @link and @linkplain javadoc tags.

Thanks for the review, Jon. > Am 29.05.2020 um 19:03 schrieb Jonathan Gibbons : > > > I think the proposed behavior, that 'foo.bar' resolves in favor of a type or > package, is OK, and favors backwards compatibility, which is good, although > it would not be my first choice if we were starting

Re: RFR: 8164408: Add module support for @see, @link and @linkplain javadoc tags.

Am 01.06.2020 um 16:55 schrieb Jonathan Gibbons : > > Unless I'm missing something, it still seems wrong to put the trimmedSig in > the tree, instead of the sig. You already have the module name available as > a separate parameter to the newReferenceTree call. > > I'm concerned that if you par

Re: RFR: 8164408: Add module support for @see, @link and @linkplain javadoc tags.

new module reference syntax as that method is only used to create links to external modules. Hannes > Am 02.06.2020 um 17:14 schrieb Jonathan Gibbons : > > > On 6/2/20 7:13 AM, Hannes Wallnoefer wrote: >> That’s correct, the toString() representation and default link label wil

RFR: 8246429: Javadoc comparators are not module-aware

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8246429 Webrev: http://cr.openjdk.java.net/~hannesw/8246429/webrev.00/ I originally fixed this as part of 8198705: Javadoc search needs a fix to handle duplicate package names in different modules, but it is a distinct issue so I fil

Re: RFR [15] 8245981: Upgrade to jQuery 3.5.1

Hi Pavel, the changes look good and generated docs are working fine for me. Hannes > Am 04.06.2020 um 18:28 schrieb Pavel Rappo : > > Hello, > > Please review the change for https://bugs.openjdk.java.net/browse/JDK-8245981 > > http://cr.openjdk.java.net/~prappo/8245981/webrev.00/ > > This u

Re: RFR: 8246429: Javadoc comparators are not module-aware

style of the method I’m adding to, which in this case unfortunately varies within a single class. Hannes > Test: yay for Text Blocks. > > -- Jon > > On 6/4/20 7:19 AM, Hannes Wallnoefer wrote: >> Please review: >> >> JBS: https://bugs.openjdk.java.net/browse/JD

RFR: 8198705: Javadoc search needs a fix to handle duplicate package names in different modules

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8198705 Webrev: http://cr.openjdk.java.net/~hannesw/8198705/webrev.00/ This adds code in AbstractIndexBuilder to detect search index items that display the same label in the search result. If there are, the module information is adde

Re: RFR: 8246429: Javadoc comparators are not module-aware

, Jonathan Gibbons >> wrote: >> >> On 6/5/20 9:10 AM, Hannes Wallnoefer wrote: >>> Thanks! >>> >>>> Am 04.06.2020 um 16:51 schrieb Jonathan Gibbons >>>> : >>>> >>>> +1 >>>> >>>> I'

Re: RFR: JDK-8246705: javadoc gives "misleading" and incomplete warning message.

Looks good to me. I can’t quite work out why the message in testExplicitBinaryModuleOnLegacyPaths changes from module_not_found to module_not_found_on_sourcepath instead of module_source_not_found, but it seems like the correct message in the context. Hannes > Am 06.06.2020 um 01:48 schrieb J

Re: RFR: [15] JDK-8247235 doclint should permit "self-closing" tags for void elements in HTML5

Hi Jon, Looks good! Hannes > Am 10.06.2020 um 03:17 schrieb Jonathan Gibbons : > > Please review a small update to doclint to permit the use of '' and > '', > which are legal in HTML5, per the rules here: > https://html.spec.whatwg.org/multipage/syntax.html#start-tags > > -- Jon > > JBS: ht

RFR: 8236935: Improve UX of the search control

Please review a fix to display a „Loading search index…“ message in javadoc search while the search index files are loading and updating the results when loading is completed. JBS: https://bugs.openjdk.java.net/browse/JDK-8236935 Webrev: http://cr.openjdk.java.net/~hannesw/8236935/webrev.00/ Th

RFR: 8241969: Type annotation is not shown for wildcard type in Javadoc

Please review a simple fix to show type annotations for wildcard types: JBS: https://bugs.openjdk.java.net/browse/JDK-8241969 Webrev: http://cr.openjdk.java.net/~hannesw/8241969/webrev.00/jdk.patch The code generating the wildcard link was just missing a call to generate the annotation. An appr

Re: RFR: 8236935: Improve UX of the search control

Thanks Jon. > Am 11.06.2020 um 03:14 schrieb Jonathan Gibbons : > > Hannes, > > Code looks good and seems to work OK. > > It would be nice to see a version without the 5 second delay, but I guess we > will see soon enough. The 5 second delay makes clear that the index files > are loaded for

Re: RFR: [15] JDK-8236539 Relative link tags in record javadoc don't resolve

Hi Jon, Looks good! Hannes > Am 12.06.2020 um 02:18 schrieb Jonathan Gibbons : > > Please review an interesting but trivial fix for an issue that was reported > on amber-dev > a while back. > > On JDK 14, the test case that was provided executed as described, reporting > incorrect diagnostic

RFR: [15] 8243533: Only one of several deprecated overloaded methods listed in the Deprecated list

Please review a simple fix to show all overloaded members in the deprecated list: JBS: https://bugs.openjdk.java.net/browse/JDK-8243533 Webrev: http://cr.openjdk.java.net/~hannesw/8243533/webrev.00/ This adds a new compareParameters(Element, Element) method to the javadoc Comparators class and

Re: RFR: [15] JDK-8245696 javadoc crashes when a doc-files directory contains a '#' file

Hi Jon, Looks good! Hannes > Am 17.06.2020 um 06:48 schrieb Jonathan Gibbons : > > Please review a simple fix to prevent javadoc crashing when it encounters a > badly-named > file in a doc-files subdirectory. > > The problem is caused by checks in JavaFileManager causing > IllegalArgumentExc

Re: RFR: JDK-8243113 : Always identify version of javadoc used to generate docs

Hi Jon, The URL for the webrev looks correct, but it contains the patch for 8245696 (invalid file names in doc-files). Believe me, I hate juggling bug ids just like you :) Hannes > Am 17.06.2020 um 00:33 schrieb Jonathan Gibbons : > > Please review a small patch to modify the "Generated by ja

Re: RFR: [15] JDK-8245696 javadoc crashes when a doc-files directory contains a '#' file

Jon, I just noticed that in the mix-up of this bug with 8243113 the wrong bug id ended up being added to the @bug tag in TestDocFiles.java. Hannes > Am 17.06.2020 um 15:13 schrieb Hannes Wallnoefer > : > > Hi Jon, > > Looks good! > > Hannes > >> Am 17.

Re: RFR: 8236935: Improve UX of the search control

Thanks for the reviews, Jon! > Am 18.06.2020 um 22:25 schrieb Jonathan Gibbons : > > I played with the posted APIs again. It seems to be the case that the > "loading" message only appeared briefly, for only as long as no search > results are found. Once some results are found, even if not all h

Re: RFR: 8236935: Improve UX of the search control

just remove the `if (expr)` ? It is already the case that > this code is protected inside `if (!indexFilesLoaded()) ...` > > -- Jon > > On 6/10/20 2:44 PM, Hannes Wallnoefer wrote: >> Please review a fix to display a „Loading search index…“ message in javadoc >> search while

Re: RFR: 8236935: Improve UX of the search control

outside of the UX fix is that all index files are generated all the time, even if they contain no items. Hannes > Am 29.06.2020 um 16:36 schrieb Hannes Wallnoefer > : > > I uploaded a new set of API docs that keeps the „loading…“ message at the top > of the result list until all the i

Re: RFR: 8236935: Improve UX of the search control

-- Jon > > On 7/10/20 6:40 AM, Hannes Wallnoefer wrote: >> Ping. I realized I hadn’t uploaded the webrev, just the rendered API docs >> with the delayed index loading, so here is the new webrev: >> >> https://cr.openjdk.java.net/~hannesw/8236935/webrev.01/ >> &g

RFR: 8248566: Make API docs more usable on mobile browsers

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8248566 Webrev: http://cr.openjdk.java.net/~hannesw/8248566/webrev.01/ API docs: http://cr.openjdk.java.net/~hannesw/8248566/api.01/ This is by no means a complete solution to all problems of API docs on small browsers, but it is a fir

RFR: 8249133: Javadoc: Browser back navigation does not jump to previous position anymore

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8249133 Webrev: http://cr.openjdk.java.net/~hannesw/8249133/webrev.00/ API docs: http://cr.openjdk.java.net/~hannesw/8249133/api.00/ This patch makes use of the browser History API to add the current scroll position to the browser hist

Re: RFR: 8249133: Javadoc: Browser back navigation does not jump to previous position anymore

> Am 16.07.2020 um 16:57 schrieb Hannes Wallnoefer > : > > Please review: > > JBS: https://bugs.openjdk.java.net/browse/JDK-8249133 > Webrev: http://cr.openjdk.java.net/~hannesw/8249133/webrev.00/ > API docs: http://cr.openjdk.java.net/~hannesw/8249133/api.00/ > &g

Re: RFR: 8249133: Javadoc: Browser back navigation does not jump to previous position anymore

this current > drawback. > > -- Jon > > > On 7/16/20 9:10 AM, Hannes Wallnoefer wrote: >> Unfortunately I removed a line from my patch that is needed after all. New >> webrev and API docs below. >> >> I also added a comment to explain the purpose of the code. &g

RFR: 241518: Member signature parameter span contains closing but not opening parens

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8241518 Webrev: http://cr.openjdk.java.net/~hannesw/8241518/webrev.00/ API docs: http://cr.openjdk.java.net/~hannesw/8241518/api.00/ This changes the „parameters“ span in member signatures to contain both opening and closing parens, wh

Re: RFR: 241518: Member signature parameter span contains closing but not opening parens

updated, and it didn’t seem to be necessary for the issue being fixed. However, I’m open to making that change either as part of this issue or as a new issue. Hannes > If so, should we fix that too? > > -Pavel > >> On 28 Jul 2020, at 13:45, Hannes Wallnoefer >

RFR: 8250779: Anchor is ignored when reloading a page in Chrome

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8250779 Webrev: http://cr.openjdk.java.net/~hannesw/8250779/webrev.00/ The fix consists in not calling history.replaceState at the end of the patch when the current URL has a fragment identifier. The rest of the patch consists in co

RFR: 8250954: Avoid multiple warnings for external docs with mismatching modularity

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8250954 Webrev: http://cr.openjdk.java.net/~hannesw/8250954/webrev.00/ This is a trivial fix to print only one warning per external documentation bundle in case of mismatching modularity, instead of printing one for each contained pac

RFR: 8216497: javadoc should auto-link to platform classes

Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8216497 Webrev: http://cr.openjdk.java.net/~hannesw/8216497/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8251181 Most of the new code is added to the Extern class where it fits in quite nicely and can use the existing suppo

Re: RFR: 8216497: javadoc should auto-link to platform classes [v2]

Switching to reply by email to javadoc-dev only in order to not spam all the other mailing lists with each comment/reply. > Am 22.09.2020 um 19:37 schrieb Jonathan Gibbons : > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties > line 350: >

Re: RFR: JDK-8260388: Listing (sub)packages at package level of API documentation

Hi Daniel, Thanks for the feedback (and the review of the java.net.URI change). I agree that the value of this feature varies depending on the code base, since it is all based on package naming. However, I think the module spanning aspect is actually a good thing in most cases, as it compleme

Re: RFR: JDK-8260388: Listing (sub)packages at package level of API documentation

tion be recorded in the table? > > Something like: > >Package java.net > > >Related Packages > > >+ java.net.spi > >+ java.net.http in module java.net.http > > best regards, > > -- danie

Re: RFR: JDK-8260388: Listing (sub)packages at package level of API documentation

Daniel, I uploaded documentation with the cross-module link indication you suggested: http://cr.openjdk.java.net/~hannesw/8260388/api.02/ I’m not qute convinced, curious to hear what you and others think. Hannes > Am 11.03.2021 um 12:07 schrieb Hannes Wallnoefer > : > > That is

Re: RFR: JDK-8263507: Add links to page sections in sub-navigation of package summaries

Am 09.04.2021 um 17:22 schrieb Jonathan Gibbons : > > Hannes, > > Reading your email, and the comments about the number of tables, reminds me > of the suggestion to merge most of the tables (all those for different kinds > of classes and interfaces) into a single tabbed table, as is now becomin

Re: RFR: JDK-8263507: Add links to page sections in sub-navigation of package summaries

I have imlemented the tabbed classes and interfaces table and playing around with the wording. It looks like dropping the word „Summary“ would give us enough space to actually expand the first „All Classes“ tab to „All Classes and Interfaces“, which I find more meaningful and correct. That is e

Re: RFR: JDK-8263507: Add links to page sections in sub-navigation of package summaries

Am 13.04.2021 um 07:22 schrieb Jonathan Gibbons : > > Just asking: does the "Classes" tab refer to "all classes, including enum > classes, record classes, exceptions and errors", or "all classes except enum > classes, record classes, exceptions and errors" ? It just includes „ordinary“ classes

Re: RFR: JDK-8263507: Improve structure of package summary pages [v3]

Thanks for the reivew, Jon. Comments inline below. > Am 30.04.2021 um 06:33 schrieb Jonathan Gibbons : > > On Mon, 19 Apr 2021 09:45:27 GMT, Hannes Wallnöfer > wrote: > >>> This adds a feature to add sub-navigation links to the package summary >>> page, but ended up more like a refactoring of

Re: RFR: JDK-8266779: Use instead of ZERO_WIDTH_SPACE [v2]

Thanks for the review, Pavel. > Am 10.05.2021 um 16:21 schrieb Pavel Rappo : > > > It's unfortunate that the text blocks in tests are formatted for a fixed > width; diffs are filled with unrelated changes. Update copyright years and > you're good to go. Thanks for fixing this, Hannes. It’s no

Re: RFR: JDK-8267394: Do not rely on object identity for empty valid Content instance

There are 24 failing tests if the `isValid()` check is omitted in HtmlTree.add(Content). I started going after „invalid“ HtmlTree instances using stack traces to locate their origin, but gave up after 3 or 4 due to the reasons given earlier: there’s quite a few of them, and even if we find them

Re: RFR: JDK-8259806: Clean up terminology on the "All Classes" page

Yes, the move is from „All Classes“ to „All Classes and Interfaces“. This is also the new terminology used in the combined tabbed table in package pages, regardless of release. Hannes > Am 05.06.2021 um 21:16 schrieb Jonathan Gibbons : > > Up until recently, we used > > Types (now Classes a

Re: RFR: JDK-8274625: Search field placeholder behavior [v2]

Thanks for the review, Pavel. > Am 05.10.2021 um 19:34 schrieb Pavel Rappo : > > We should use standard tools for standard tasks where possible. In this case > using a "placeholder" instead of the custom "watermark" workaround fixes the > problem, simplifies the code and looks better. > > Upda

javadoc search enhancements

I’ve been working on various enhancements for the javadoc search feature for the past weeks and am looking for feedback. The enhancements are: - Less strict search: Allowing the search query to consist of multiple space-separated tokens that can match anywhere in the indexed elements whithout

Re: javadoc search enhancements

information (in condensed form) would belong in the help page in the final product. Hannes > -- Jon > > > On 3/3/22 7:43 AM, Hannes Wallnoefer wrote: >> I’ve been working on various enhancements for the javadoc search feature for >> the past weeks and am looking for