Allow editing of text after coding of text #61

Activity

1. alessandrobelli commented on Aug 2, 2024

   

   alessandrobelli

   on Aug 2, 2024

   Contributor

   More actions

   This is definitely something we want to add, but it adds layers of complexity.
   For example, the codes are identified by the start and end position in a text, and their length. While the length change is easy, if the text is altered in a considerable way, this can easily become a problem.

   TLDR; It's on our schedule, but it won't be available anytime soon.

   Unfortunately for now, the workflow has to include a strong review of the text before coding starts...

   👍React with 👍2Reacted by jdittrich and Elen Le Foll
2. alessandrobelli

   added

   enhancementNew feature or requestNew feature or request

   on Aug 2, 2024
3. jdittrich commented on Aug 2, 2024

   

   jdittrich

   on Aug 2, 2024

   Last edited by jdittrich

   Author

   More actions

   While the length change is easy, if the text is altered in a considerable way

   Yes – the method I found to deal with text changes is:

   • Have the text changes in the form as objects with the properties length:int> and operation-type (which are: "retain", "delete", "add") – this is what many modern editors produce (I think I used quill 1)
   • Represent the annotate ranges of of text as boundaries, i.e. an objects with the properties boundary position index:int, boundary type (which are: "start", "end") and annotation id (that usually needs a temporary conversion)
   • For each change go though all boundaries and see if they need to be moved. A boundary is moved, if its position index is > than the position-index of the change. Deletions lower all boundary indices, additions raise them (now, nested loops are not great for performance, but the operations itself are simple)
   • …what I did not implement is cleaning up collapsed boundaries i.e. ones where their containing text has been entirely deleted.
   • convert back into the native format of representing annotation ranges.

   Which does not mean this is easy to do, just some example of how it can be approached.
4. jankapunkt

   added

   Hacktoberfest

   on Oct 4, 2024
5. jankapunkt commented on Nov 19, 2024

   

   jankapunkt

   on Nov 19, 2024

   Member

   More actions

   @kadewe the aforementioned comment by @jdittrich is an example of why we now use quill to manage the state of selections as controlled state as opposed to manual add/insert/update/remove elements.

   The clear advantage is that quill supports concurrent editing using a delta format, which will soon allow us to make selections of text, then edit the text and have the selections automatically update.

   However, there is one more level of complexity that @jdittrich missed out here, that is - we have to additionally compute overlaps of selections, because quill and any other editor will not automatically create an overlap, because it's actually their job to NOT overlap but override. Think about how google docs would work if the algorithm (operational transformation) would actually support overlapping editing, instead of overriding... This is why "merge" of concurrent edits is simply a controlled way of deciding which edit is the correct last state of truth overriding prior edits.

   Summarizing this:

   • from version 1.0 we use quill to control the state of the text and the selections
   • with quill we can support multiple plugins for visualizing selections, the default (and currently only supported one) is highlighted background
   • overlapping of selections has to be computed manually and has to be added until 1.0
   • additional deltas from post-selection editing of the source should be implemented but not for 1.0
   • performance might be affected on large documents with lots of selections by multiple users, this is to be researched aftr 1.0 release in order to find performance optimizations
6. jdittrich commented on Nov 19, 2024

   

   jdittrich

   on Nov 19, 2024

   Last edited by jdittrich

   Author

   More actions

   we have to additionally compute overlaps of selections

   As far as I am concerned, if you move all the boundaries, you also move the overlapping sections. In the solution I mentioned above, I never store or process overlapping sections directly: (notation as propertyName:)

   1. store the selections as: id:, from:, to: – since these are the domain object users operate on
   2. Derive boundary points from 1.: (belongTo:, type:<"start"|"end">, position:) which can be used for recalculating boundardy positions and for generating overlaps.
      3.The overlaps are only created as a view-model and entirely derived from existing data.: The text is subdivided into sections by the boundary points, each section has 0 or more highlights. The sections can also have 0 or more formatting options (which thus can be preserved (Usually you would first get the formatted ranges from the editor, then further chop them up for the highlighting – or you store both in your data model)

   (I have a demo (incedentally also based on quill, if I remember correctly) of this which might be easier to understand than my abstract description)
7. jankapunkt commented on Nov 19, 2024

   

   jankapunkt

   on Nov 19, 2024

   Member

   More actions

   @jdittrich overlapping selections might not be part of your usecase but since collaborative coding will be a crucial part of the upcoming releases we have to cover visualization of overlapping codes. Yes, the overlappings are only part of the view-model but they have to be actively computed each time a selection gets added/removed/moved, because the selection itself does not know which other selections are crossed.

   A demo would be very useful, can you link it here?
8. jdittrich commented on Nov 19, 2024

   

   jdittrich

   on Nov 19, 2024

   Last edited by jdittrich

   Author

   More actions

   overlapping selections might not be part of your usecase

   They are! (I derived them, rather than represent them directly)

   Yes, the overlappings are only part of the view-model but they have to be actively computed each time a selection gets added/removed/moved, because the selection itself does not know which other selections are crossed.

   Yes.

   A demo would be very useful, can you link it here?

   I could send code, I think, I do not have an online demo for it.
9. jankapunkt commented on Nov 20, 2024

   

   jankapunkt

   on Nov 20, 2024

   Member

   More actions

   @jdittrich I could create a demo repository and invite you and we build this together until it's a proof of concept. We could then merge it into openqda, making you our first external collaborator 🚀
10. jankapunkt

    pinned this issue on Nov 20, 2024
11. jankapunkt commented on Nov 20, 2024

    

    jankapunkt

    on Nov 20, 2024

    Member

    More actions

    @jdittrich here is the repo: https://github.com/openqda/editor-dev let me know if I can invite you :-)
12. jdittrich commented on Nov 20, 2024

    

    jdittrich

    on Nov 20, 2024

    Author

    More actions

    thanks – yes, please invite me (the account that I use here is right)
13. jankapunkt commented on Nov 20, 2024

    

    jankapunkt

    on Nov 20, 2024

    Member

    More actions

    @jdittrich done, let's continue discussion there and come back here later
14. jankapunkt

    added this to the Release 1.1 milestone on Jan 30, 2025
15. jankapunkt

    removed

    Hacktoberfest

    on Feb 5, 2025
16. jankapunkt

    modified the milestones: Next / Backlog, 1.1.0 on Apr 2, 2025
17. jankapunkt

    added the

    Feature

    issue type on Mar 19, 2026
18. jankapunkt

    added

    partially resolved in python portUse when covered in python port but not considered as resolved there yetUse when covered in python port but not considered as resolved there yet

    on Oct 27, 2026