[Documentation] Synchronize code and docs of test/editor.cxx

[Albrecht-S]

I wrote in this comment on issue #135:

The docs in chapter "Designing a Simple Text Editor" show in paragraph "Syntax Highlighting" much code including the entire style_parse() function. This code has obviously not been updated regularly, there are some parts missing/incomplete/outdated.
... we should synchronize the code and the docs at some time. I'm also not sure if it's useful to add the entire new functionality to the editor demo. Maybe it would be a compromise to

• do only a small fix but not to update the entire code or
• remove the function from the docs and refer to the real code in the source distro and
• fix the syntax highlighting code by adding separate files/functions that can be shared with fluid

or something like that. In the simplest case we'd just document that the documentation is incomplete and that the real code in the source distro should be consulted (to avoid too much code duplication in the docs).
[End of citation].

The mentioned "new functionality" refers to the new style_parse() function in a separate file in fluid.

I'm opening this issue and classifying it as "Documentation" as a reminder that this should be done. It's low priority but since the editor code is documented it should be synchronized in one way or the other.

[erco77]

My suggestion would be to redefine the editor demo to not be a code highlighter (which is hard), but something more simple and practical.

Perhaps ^F search could highlight all matches in the file instead of just one word at a time, highlighting the 'current'
word in a different color from the other matches.

I think all people want to see is how highlighting works, and not be distracted by lots of syntax parsing code.

[rempas]

First of all I would like to thank you for your work on FLTK. I finally found the GUI library that I want to use and I hope I can also contribute to the project in the future If I properly learn C++ and when I feel ready to!

I have 2 suggestions for the doc example.

1. Implement the missing callback functions. These are insert_cb | view_cb | close_cb | undo_cb.
2. Change the example a little bit, split it to files. I personally made a header file for the commons includes and for the global variables, a file for the main(), a file for the menu bar, a file for the EditorWindow, a file for the callbacks and a file for the other functions. And of course an associative header file for each one of them (except for the one in the main). Also I would be nice to use #pragma once as we are writing C++. Even if you don't do that, PLEASE PLEASE PLEASE, make this more clear!! I wasn't able to finish the project because I can't properly implement some stuff. For example:

l_Menu_Bar*m = new Fl_Menu_Bar(0, 0, 640, 30);
m->copy(menuitems);

where should I create that? Inside the class constructor or inside the main? It's not clear and I don't know if I'm just a beginner and I should have figured that out be myself... Or:

w->editor = new Fl_Text_Editor(0, 30, 640, 370);. What is w? I suppose it's a variable of type EditorWindow but when it was created?
Please do not suppose that we know how to do that, for noobies like me, It's not the best thing.

Again I hope I could help a bit!

[MatthiasWM]

I am sorry that I am so late to this, and will probably still take some time until I have something useful. I agree that writing a text parser should not be part of the tutorial. I am more thinking about a boilerplate start, adding feature by feature, and, as @rempas said, making it clear where the code goes. Also, a copy of the C text parser is part of FLUID. No real reason to repeat that here.

[Albrecht-S]

@MatthiasWM Please feel free to work on this but I removed this issue from the 1.4.0 milestone because it's not important enough to hold the release.

[MatthiasWM]

See #883

[MatthiasWM]

PR #883 merged.