Hi Aliaksei 2016-10-20 9:16 GMT+02:00 Aliaksei Syrel <alex.sy...@gmail.com>:
> Was tough decision :) We decided (in GT) that next moldable tool should be > a "Moldable Text Editor for Pharo". Here are some requirement that must be > full-filled by text editor: > Could you explain what is wrong with TxText model to achieve this? (I comment bellow each point). And do you have any links to understand what moldable text editor means? > - support of very large files (gigabytes) > TxText-Athens implement text morph to show big text models. Maybe the way how it is designed is not suitable for Sparta and Bloc. Then I will understand if you will just drop away this code and build Bloc/Sparta optimized version but on top of same text model. If you talk about showing *files* it is not enough of course because full text model needs to be loaded from file which is not scale when file size is huge. But TxText model looks very smart to provide lazy logic where text elements are loaded and built by demand. And it looks much easy to do than with Rope kind model. TxText is linked list of elements. No problem to build them lazily. > - multithreading (styling, syntax highlighting in background) > I am really interesting how it could be done and why Rope model is better than TxText model from this perspective. Styling is just editing text by splitting elements and marking them with specific attributes. How to do it in background when somebody could edit text in same time? Rope model or TxText model is complex structure. It is quite difficult to make it safe for concurrency. > => text model has to be immutable > So solution is to not modify existing model. For example we could extract full string from text, build new model and install it into widget. But here is same problem original copy could be modified by user while new model is built. What to do then? I actually made conclusion that background styling is bad idea. (in the way when we show text to user and only then start styling it) - fast access by index (for styling; parser returns Tokens with indices) > Ok. Here Rope model works better then TxText. But is it really important case? For your styling example it is possible to solve it differently. Imaging if parser will produce text model itself. So any parse node will not point to token string but to text element inside text model. And then styler will just mark them with attributes directly. No index access will be needed. And such approach could lead to very interesting things. Imaging that source code is text model where elements are marked by AST-nodes (as attributes). > - optimised for sparta (use all amazing text features provided by Moz2D) > I see same kind of text attributes in Sparta text as in TxText. What else you added to text to cover specific Sparta features and why attributes was not enough for this?
