RSyntaxTextArea icon indicating copy to clipboard operation
RSyntaxTextArea copied to clipboard

Editor having multiple tabs (multiple document)

Open ricardojlrufino opened this issue 10 years ago • 5 comments

I'm working on an editor with support for multiple tabs, my implementation by design questions / performace is using the same instance of Textarea changing only the RSyntaxDocument.

I realized that some things but have stopped working, especially small details in the Gutter, because it stops responding to DocumentListener.

The UndoManager too, but I managed to solve this with minor changes.

I wonder is feasible to support multiple documents (change document) It would be too complex?

Here are images of some details that had problem

selecao_426

selecao_425

ricardojlrufino avatar Dec 08 '14 18:12 ricardojlrufino

With the latest commit, I think I've fixed most of these issues. Please pull it and check it out. The following should be fixed:

  • Line numbers
  • Code folds (though note they won't remember their collapsed/expanded state)
  • Marked occurrences of the word at the caret position.

Besides fold states, the "active line range" indicator is still broken. I'm not sure of the best way to fix that, as there's no well-defined interface I can call into to force a re-evaluation of this state.

Note also that these states (code folds, marked occurrences, etc.) aren't saved when you swap Documents, but are rather recalculated each time a new Document is set. The performance impact of this is likely inconsequential, but it is at least worth noting.

In any case, making modifications to recalculate the active line range may have to wait until the next release. I'd like to make a 2.5.5 release in the next day or two to address an issue found early on with 2.5.4.

bobbylight avatar Dec 10 '14 03:12 bobbylight

I did some similar corrections, did not think you would fix so fast ... but thank you, I will check! Congratulations!

ricardojlrufino avatar Dec 10 '14 03:12 ricardojlrufino

I just ran into some problems with this as well, where when you change documents, any line highlights are applied to the new document again (but based on the byte offsets of the old document, which certainly isn't correct).

To fix this, I guess storing highlights in the document might be better (would even allow adding highlights on a document not currently shown), though perhaps that would violate the document / ui separation. Alternatively, the LineHighlightManager could remember the document along with every LineHighlightInfo (it seems that the Position object already stores does not allow extracting the document it is linked to).

matthijskooijman avatar Nov 02 '15 16:11 matthijskooijman

(Btw, I realize that one textarea per tab would fix this, but that's really a workaround, and I didn't write this original code, so I'll have to talk to others to see if that would be an option).

matthijskooijman avatar Nov 02 '15 16:11 matthijskooijman

Looking more closely at the java Document API, it seems you can associate some arbitrary properties with every document, so that could be used to store the undo manager and line highlightmanager along with the document (or perhaps just the data, not the full manager)?

matthijskooijman avatar Nov 02 '15 16:11 matthijskooijman