Add Support for TokenMarker

[dprutean]

I am looking to move from jidesoft.com code editor to RichTextFx. Few features I miss:

• Support for TokenMarker. TokenMarkers are Java classes generated by JFlex lexical parser. See http://jflex.de/ and http://syntax.jedit.org/. I ask you to implement this because a good implementation will work very well on large files - the text verification will be done from the last line without any highglight till after the edited line, where the highlight is the same.

• Add search / replace dialog directly to the editor. Having this directly build-in is a great advantage.

• Consider features for editing large files. The best editors I saw, like the one from jidesoft can edit very large files, computing the lines and loading only the visible one. This feature may be pretty difficult.

• Improve the sample application in your jar. When launching java -jar richTextFx.jar start directly the demo, and inside show all features you have.

[JordanMartinez]

@dprutean RichTextFX is meant as a base upon which others can build. As such, the lack of support for syntax highlighters and search/replace dialog is intentional.

As for the large files see #282. The feature you describe (as I understand it) is already implemented via an efficient VirtualFlow. See TomasMikula/Flowless

Improve the sample application in your jar. When launching java -jar richTextFx.jar start directly the demo, and inside show all features you have.

What do you mean by that? How should the sample application be improved?

[dprutean]

Still is nice to have maybe an extra module ( jar ) with search/replace functionality. Everybody needs this. Also having at least a base class / some samples for few language parsers would be great. Maybe the most powerfull free parsers at the moment, for SQL, Java, Groovy, etc. Users who decide for ReachTextFx will need also a solution for this, and having at least something included is great. Many users will contribute to extend this base.

With improved examples I mean to simply double-click a jar ( could be a samples.jar ) and samples should start. There on different tabls should be few examples ( if different ). On one tab should show a checkbox for 'Show line number', 'show end line'- -maybe show end line markers in gray, etc.
Also a tab with source code for each example. A tab may be for showing behaviour on large files,etc.

[JordanMartinez]

Everybody needs this.

In my own project, I have no use for a search/replace functionality, though I understand why many others would want that.

Still is nice to have maybe an extra module ( jar ) with search/replace functionality. Everybody needs this. Also having at least a base class / some samples for few language parsers would be great. Maybe the most powerfull free parsers at the moment, for SQL, Java, Groovy, etc. Users who decide for ReachTextFx will need also a solution for this, and having at least something included is great. Many users will contribute to extend this base.

I understand your desire, but as soon as we would add that feature, then others would ask that we add more such features using similar justification as you are now doing. That would quickly fall out of the scope of this project: changes that help one such party here may provide inflexibility to other parties who use this code in a different way.

Tomas has shown in the demos package how RichTextFX could be built upon to add such functionality. So, although I wouldn't merge such features into the main project, if you wanted to create a demo that adds such functionality to the demo package, I would merge that.

In some ways, it would make sense to create a RichTextFXUtils project that could quickly augment the code here with such features.

With improved examples I mean to simply double-click a jar ( could be a samples.jar ) and samples should start. There on different tabs should be few examples ( if different ). On one tab should show a checkbox for 'Show line number', 'show end line'- -maybe show end line markers in gray, etc.
Also a tab with source code for each example. A tab may be for showing behaviour on large files,etc.

Are you suggesting something similar to the approach taken by ControlsFX's samples.jar?

[dprutean]

Agree with you. I find the best if possible to create one more module in your project. It is an advantage to have them together. A good find/replace functionality is not simple, may include regexp, show of markers on the right of the text pane, shortcuts ( F3 search next ), etc.
Right, controlsfx-samples.jar is a nice sample. If you look in their source code they also use separate modules for samples and others. They have tabs for source code, also great.

[JordanMartinez]

Right, controlsfx-samples.jar is a nice sample. If you look in their source code they also use separate modules for samples and others. They have tabs for source code, also great.

We can discuss this further in the issue I've just opened.

Agree with you. I find the best if possible to create one more module in your project. It is an advantage to have them together....

Wait, so what are you agreeing with? I said we shouldn't merge such features into this project at all (which includes creating a separate module for that), but that seems to be what you are implying. Perhaps I wasn't as clear as I could have been?

[TomasMikula]

As for large files, with the provided document representation (implementation of EditableStyledDocument), the whole document is still in memory. It's just that paragraphs that are not visible are not part of the scene graph.

👍 for some RichTextFX-Extras project.

[dprutean]

Sorry for the last comment, is my mistake. Adding a search-replace functionality may also have a method to disable it: disableSearchReplace() - for users who wants to implement something else or simply disable.

This is like when buying a car : the producer may say "we don't put any radio in our cars, some of our customers doesn't need one or they can choose what they like". Still, I think is better to already have the radio inside, the time spent to find and put one inside is also important for me. Same with implementing new code.

Having a module in the same project has few advantages

• may create a separate jar
• is possitive for code mentenance, dependencies, etc.
• is better for Google search ( more keywords pointing to one project )

Thank you also for the comment on large files. I plan to use the editor to edit SQL scripts, sometimes they can be database backups which are really large. The editor may stop to load text from the file if a certain limit is reached, and continue to load only if the scrollbar goes very down. Like facebook does when scrolling its content. Just think about it.

[JordanMartinez]

Adding a search-replace functionality may also have a method to disable it: disableSearchReplace() - for users who wants to implement something else or simply disable.

This is like when buying a car : the producer may say "we don't put any radio in our cars, some of our customers doesn't need one or they can choose what they like". Still, I think is better to already have the radio inside, the time spent to find and put one inside is also important for me. Same with implementing new code.

I see RichTextFX more as a supplier of auto parts that an automaker (i.e. developers) can utilize to build a fully-featured car (e.g. code editors). Being a parts-maker, RichTextFX does not have the goal of building a fully functional car. The fact that it provides StyledTextArea, which (to use your analogy) can function as a car, is an exception, not the norm.

RichTextFX's goal is to provide a rich text area base upon which others can build. Developer's use-cases, as is my understanding, generally falls somewhere in these categories:

1. a standard RichTextArea (because that is missing from standard JavaFX library)
2. a slightly-customized RichTextArea (overrides default behavior in some way) for a special use case
3. a base for a heavily-customized RichTextArea that includes non-text Nodes (images/emoticons, shapes, paragraph bullets, and tables).
4. a base for a code editor that uses a specific items to accomplish some tasks (e.g. syntax-highlighting)

With that being the goal, one concern is to not include "features" that may be useless for some users, inflexible for others, or otherwise complicate things for others unnecessarily. For example, features that may benefit some but annoy and/or complicate use-cases for others would not be desirable, such as implementing a specific syntax-highlighter.

The other concern is limited manpower and scope. Keeping the scope narrows makes it easier to fix bugs, which leads to stable code for everyone, and focuses the direction and manpower of the project, so that things actually get done rather than being talked about.

However, the last concern to keep in mind is whether a developer can implement a feature on top of the base. If the developer cannot, then I think it should be included in the project. Specifically, #222 comes to mind. How would a developer implement that on top of the base area? It is possible, but it would feel very hackery.

With those considerations in mind, should a search-and-replace feature be included? Here are my thoughts:

• Since it can be implemented as a feature on top of the base which this project provides, it doesn't need to be implemented like the multiple carets/selections issue I mentioned above.
• However, just because it doesn't need to be implemented directly in the code base, would it benefit enough users without hindering others to be worth it? Looking back at the four categories I mentioned above:
  • Category 4: Desirable, no doubt. One could include options for plain text, regex, within selection, etc.
  • Categories 1 & 2: May or may not be useful. For users like myself who don't need that functionality, it would make more sense to override the default behavior (assuming SHORTCUT + F calls the search-and-replace method) than to disable it via method call.
  • Category 3: How it would be implemented? How do you search and replace an image, shape, etc.? If ignoring those items, how would you write the code to incorporate that use case along with the others? I suppose using generics and functional interfaces would work, right?
• The code needed for this sounds like a lot of work, which will only increase this project's complexity when other features are merged. That increases the amount of time between stable releases.

This is why I think implementing the code inside a RichTextFX-Extras project would make more sense.

Update: For my comment about users in Categories 1 & 2, it would make more sense, if this was implemented, to not have SHORTCUT + F run the search-and-replace method by default and instead allow the user who needs it to include that behavior in their class. This prevents users from Category 1 from being surprised without hindering everyone else since they'll be customizing the area anyways.

[JordanMartinez]

Closing due to being outside the scope of this project. I've also written an explanation of what "out of the scope of this project" means in the wiki