Hi Andy, here you go: https://github.com/openjdk/jfx/pull/2276
This is a draft PR, where I've reverted my original changes, so VFlow, TextCell and others remain private in com.sun. That really limits the customization options, but it should be a first step toward a more customizable control in the future. I still keep my "full" changes just in case you want to compare them with this PR (https://github.com/jperedadnr/jfx/tree/codefolding). In any case, let's discuss #2276 first! Jose On Mon, Aug 24, 2026 at 8:36 PM Andy Goryachev <[email protected]> wrote: > Dear José: > > First of all, I am very excited, thank you for taking effort to look into > this! I'll definitely take a look at the code, please forgive me ahead of > time it might take some time. To make it slightly easier, would it be > possible to create a draft PR please? > > When I saw your message, I was still in the process of considering various > code folding APIs. I would like to bounce a few ideas off you then. > > 1. The code folding APIs should be compatible with large models. It is > entirely possible that the most use cases will deal with small models > (code) that require full text to compute folding ranges (as well as syntax > highlighting and other things), but the API should be compatible with large > models. > > I was thinking that the view would query the model for the folding given a > range currently in the view. Something like this: > > List<FoldingRange> getFoldingRanges(int startIndex, int lineCount); > > This would happen in layoutChildren(), where the cells will get populated > accordingly. > > > 2. There is a question of showing the folding toggles - would it be a new > sidebar that contains only the toggles, or should the toggles be included > in some other component (LineNumberDecorator?) Meaning, should the toggles > occupy their own visual column or share this column with other similar > things, breakpoint toggles for example? > > > 3. I would strongly suggest that we do not expose VFlow and other > currently internal parts to the public right now. I mean we might do it > eventually, but right now it will be super counterproductive. A private > implementation allows us to iterate and add new features without > introducing breaking changes. We can think of opening up the skin details > once the feel the project reached a certain maturity level (look, the > regular control's skins are not yet fully open!). > > > 4. Speaking of VFlow - in the early days I was considering reusing the > VirtualFlow, but decided against it because it was designed for virtual > lists/tables and not as a general purpose virtualization mechanism. So > maybe one possibility is to extract parts of VFlow into a universal virtual > flow component that can deal with scrollbars and conversions between view > and model coordinates. Something tells me this might be a complex project > on its own... > > > These are just my current thoughts; I'll take a look at your code once the > draft PR is there. > > What do you think? > > -andy > > > > > *From: *José Pereda <[email protected]> > *Date: *Monday, August 24, 2026 at 10:41 > *To: *Andy Goryachev <[email protected]> > *Cc: *openjfx-dev <[email protected]> > *Subject: *Re: [External] : RichTextArea/CodeArea extensibility > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCfhdgYGWvirGjOclZFS1I1Zi9ALKqEiWPkrOsCGAffZM9YsYn0_VMdAyj6H1sPj-u88JIC2Ftc26MHUSJzSOg_yOH7W96hPJWCm4eUnI0FQzWKPwCsZhtOYbl4V$> > > Hi Andy, following up on the topic, I took some time to work on some > possible changes for the richtext module, according to what I described in > my initial email, and that is in the RFE > https://bugs.openjdk.org/browse/JDK-8390346. > > TL;DR: See https://github.com/jperedadnr/jfx/tree/codefolding > <https://urldefense.com/v3/__https://github.com/jperedadnr/jfx/tree/codefolding__;!!ACWV5N9M2RV99hQ!Ixog6-QkDVGzrQLb_pl10ZNZ_c9tY-of81oI4t9lSfFy-7iw9wDZ9qgnCqyQUf8B-cNYc4XbPLNTVKwyuvGhK5FJqqFT$> > for code changes, javadoc, basic tests and a new demo application > (headings-demo). > > Detailed summary: I'll classify the changes into three main parts: > > 1. Scope changes for skin related classes (directly related to > https://bugs.openjdk.org/browse/JDK-8390346) > I've moved VFlow, CellArrangement, TextCell classes (and a few others) > from com.sun.jfx.incubator.scene.control.richtext into the > jfx.incubator.scene.control.richtext.skin package, making most of its > public methods private or package-private, and only keeping > public/protected the methods that serve as extension hooks, and creating > some factories. > > 2. Mapping between view and model (partly related to > https://bugs.openjdk.org/browse/JDK-8355957) > I've added a RowMap class to the skin package, which maps the rendered > paragraphs (view) to the document paragraphs (model). By default, the > mapping is 1:1, so nothing changes, but subclasses can provide custom logic > to hide paragraphs as needed. It plays the same role as a FilteredList to > ListView. > > 3. Demo app > As a working simple demo of both parts. I've added the Heading demo app, > which customizes the RTA to allow showing/hiding document sections on > demand, and validates the above changes. > > While I understand from previous conversations that JDK-8355957 is planned > and will be added to the richtext module at some point, the scope of these > changes would precisely ease such implementation: the foundation for a > complex feature like that will already be set, and only the particular > details (i.e., the fold() API, the concrete FoldRowMap implementation, > etc.) will be needed. In any case, the extensibility changes would allow > developers to modify the control when/as they need, without waiting for the > long iteration cycles that an RFE usually takes. > > Moving forward, I'd like to propose three PRs, starting with the scope > changes (no RowMap yet), then the RowMap and implementation detail, and > finally the demo app. > > What do you think? > > On Fri, Aug 14, 2026 at 1:12 AM Andy Goryachev <[email protected]> > wrote: > > > there is always a missing feature in a control! > > So true. > > I've filed https://bugs.openjdk.org/browse/JDK-8390346 RFE. > > Thank you, and keep the feedback coming! > > -andy > > > > > *From: *José Pereda <[email protected]> > *Date: *Thursday, August 13, 2026 at 05:10 > *To: *Andy Goryachev <[email protected]> > *Cc: *openjfx-dev <[email protected]> > *Subject: *Re: [External] : RichTextArea/CodeArea extensibility > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCfhdgYGVv2tP3z6lyCkjQs8Cg_xSyki_NWBBDU_fJjXTdQow62a5dsIGsyHjkx10C2NV7uJbadwPDjvQYOpjDX8iXr1toqkTQ-W1Td8Mbnic5I9XXDDPez_FTT5$> > > Thanks, Andy! > > The code folding feature is a complex one, definitely. Even > with extensibility in place, if developers had to implement it on their > own, that would be quite a challenge! So having it baked into the control > is a big plus. > > However, my concerns still stand: there is always a missing feature in a > control! JavaFX built-in controls have, well, for most parts (as you > mentioned, behaviour is still unresolved...), a solid base for extension, > that makes it easy for developers to create their own custom controls. > > Therefore, I believe it is important to define an extensibility path, not > only for CodeArea but for the RichTextArea itself. > > As I mentioned in my previous email, the VFlow/TextCell classes are two > important ones to start with. Following the analogy of ListView/Cell > classes, defining the required protected/public API for those two would > naturally lead to more changes in related classes. > > In any case, we can keep the discussion here for now, hoping that others > will jump in as well. And moving forward, should we file a JBS ticket under > the umbrella JDK-8351982, and come up with a basic proposal with a draft PR? > > Thanks! > > On Wed, Aug 12, 2026 at 9:28 PM Andy Goryachev <[email protected]> > wrote: > > Dear José: > > Yes, the code folding is probably the next thing being planned (please see > [0] if there are other items that should take priority, feel free to > comment). One thing I should mention is that we could use some help in > defining the interface suitable for most use cases. For example, most of > the editors I've been involved with do not handle large models well, and > one of the design goals of the RichTextArea was to support large models. > If you have any suggestions for the API, we would very much like to hear it. > > You are right about the relative freedom we currently have with the API > changes because of the incubator module. Your question about separation > line between public APIs and hidden implementation is a good very one. In > fact, it was one of my gripes with javafx vs swing is that it was nearly > impossible to make minor adjustments to the implementation or behavior. > The major reason the implementation detail is hidden in javafx is that it > significantly reduces the maintenance burden and add to stability of the > platform, at the expense of flexibility. > > Javafx made one baby step in the right direction by making the skins > public, but it was done without completing other steps that would have > enabled customization of the skin. I've tried to make the next step in > this direction by proposing the public InputMap [1] . The input map will > not help in adding folding to the CodeArea, but it does provide an extra > level of customization when no extra control surfaces are needed in the > default skin. I would insist on the InputMap for controls in general, but > that's a different topic. > > We *could* attempt to forgo the usual practice and open up the skin and > its internals, making VFlow and related classes a public API. On one hand, > it might help short term by allowing deeper customization, but at the same > time it might cause more problem down the road when a substantial change in > the implementation or public API is needed. A better alternative is to > focus on missing APIs that would enable the desired functionality (via > plug-ins like TabStopPolicy, for instance). Yet another alternative would > be to fork the skin and the behavior under GPL. > > Getting back to folding, I think it should be made a part of the standard > offering in CodeArea (I don't exactly know whether it is needed or can be > implemented generically as part of RichTextArea). This way, the > application does not have to mess with the internals and risk compatibility > issues. > > Sorry for a long response. To summarize, > > > 1. you have the power to influence the design by offering feedback and > suggestions > 2. we can still make drastic changes while the project is incubating > 3. our goal is to make a useful component that works for majority of > use cases > > > Your feedback is welcome and very much appreciated. Please let me know > what you think. > > -andy > > > References > > [0] https://bugs.openjdk.org/browse/JDK-8351982 RichTextArea (Incubator) > Feedback and Bugs in jfx24-25 > > [1] https://github.com/openjdk/jfx/pull/1495 > <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1495__;!!ACWV5N9M2RV99hQ!MNwHT4TaNozadxgENEr7zLVqmPnS4dgoPLVhzNjRTod0V507LdZ4xjxiOb4HzGvn0IbW77kUjvfOCV_b5UXsygD40dhS$> > 8314968: > Public InputMap (v3) > > > > > > *From: *José Pereda <[email protected]> > *Date: *Wednesday, August 12, 2026 at 04:40 > *To: *openjfx-dev <[email protected]> > *Subject: *[External] : RichTextArea/CodeArea extensibility > > While working with the CodeArea control, if developers want to implement > missing features like code folding ( > https://bugs.openjdk.org/browse/JDK-8355957) on their own, that is > currently not possible because relevant classes (like VFlow, TextCell, > CellArrangement, RichTextAreaBehavior, ...) are in the private, > non-exported package com.sun.jfx.incubator.scene.control.richtext. > > First question: once the incubator module is ready to be moved to a > permanent module, is the intention to keep > com.sun.jfx.incubator.scene.control.richtext as a private, non-exported > package (in its new place)? > > It currently holds around 40 classes, most of which don't need access to > com.sun.* classes outside its module. If that is the case, projects using > RTA/CodeArea would need a way to access and extend at least the skin layer. > Although the CodeAreaSkin class is public, one of its core classes, VFlow, > is in a private package, and is final. It should probably follow the > VirtualFlow case: a non-final class in a public package with protected > methods. The same applies to the TextCell class (compared to the Cell > classes). > > However, if there is still time to make some changes and move some of those > classes to a public scene.control.richtext package, these would be some of > the required changes that would allow implementing the code folding > feature, and would definitely help developers customize the control in many > other different ways: > > - Move classes to the public skin package, scene.control.richtext.skin: > VFlow, TextCell, CellArrangement, CaretInfo, Origin (and the few types > their signatures expose), and provide skin factories: > RichTextAreaSkin.createVFlow() / createBehavior() (protected), and > protected getVFlow() (again, similar to how it is done for instance in > ListViewSkin/VirtualFlow). > > - Row-mapping: this would require changing every "row index == paragraph > index" assumption in VFlow/CellArrangement with an overridable mapper, that > would default to identity. > > - TextCell extensibility: public package, non-final, with protected hooks > to be able to add inline segments and a visual to and from document > position mapping used by hit testing / caret / selection. > > - Protected geometry & navigation methods in VFlow and in the behavior, so > subclasses can modify the default implementation. > > Are there any plans already to address any of these changes? Is it possible > to consider any or all of them in the near future? I realize these are > substantial changes, but precisely that is one of the benefits of being an > incubator module, isn't it? > > Thanks! > > -- > > > > -- > > > > -- > --
