cryptee / web-client

Cryptee's web client source code for all platforms.
https://crypt.ee
Other
444 stars 22 forks source link

[Feature Request] search&replace in documents #85

Open BasilTomato opened 3 years ago

BasilTomato commented 3 years ago

Is your feature request related to a problem? Please describe. At the moment there is no search & replace solution in Cryptee Docs. I can use the internal search function of the browser, but the complete document may be copied into an external editor to achieve search & replace functionality.

Describe the solution you'd like Internal search & replace solution, including "replace all" function. Maybe "Match whole word only" and "Match case" options would be helpful also.

Additional context n/a

johnozbay commented 3 years ago

Hi there ๐Ÿ‘‹๐Ÿป

Thanks a lot for filing this! Added to our to-do list for v3.0, and we'll do our best to get this out as quickly as possible once v3.0 is out.

Will ping this thread once I have more info!

Best, J

BasilTomato commented 3 years ago

Thank you!

BasilTomato commented 2 years ago

Could you give a status update regarding this issue? A search & replace function would be very helpful in the long run.

johnozbay commented 2 years ago

Hi there!

We had to make some major adjustments and changes to documents' structures to bring paper-mode to life, which is what delayed this feature.


TLDR; We're actively working on this, and hoping to release this soon, but it's surprisingly complicated to do this without having to re-calculate the entire document & its paper-layout on each keystroke. (i.e. in a 100 page document, type/change something on page 1 and it will shift all 100 pages in paper-mode)


Long version :

โ€“ i.e. in continuous mode, all text is technically on the same page. whereas in paper-mode, text is in different pages. (and overflows / gets pushed to next page as you type) while using continuous mode, search works by finding text on the same page = easy peasy done.

However, while using paper-mode, there is a critical scenario :

โ€“ย search needs to find text in multiple separate containers (one for each page) โ€“ and when replacing it needs to update its search indexes on each page. here's why.

let's say you're searching for : link (4 characters) and will replace it with : https://a-very-long-link-that-will-definitely-overflow-the-page (63 characters)

Let's say there's 4 occurrences of "link" in the document. On Page 1, Page 2, Page 3, Page 4.

Once you replace "link" on Page 1, it will shift all the text after itself by 59 characters, and some text may/will overflow from Page 1 to Page 2, and consequently Page 2's text will overflow to Page 3 etc etc. So this will cause all the occurrences of "link" on Page 2, Page 3 and Page 4 to shift / change positions / indexes as well.

It's surprisingly difficult to calculate these changes efficiently, since each keystroke shifts the entire document, so the entire document's contents after your cursor needs to get updated. (i.e. if you've got a 100 page long document, and making edits on Page 1 all the remaining 99 pages also need to get computed with each and every one of your keystrokes.)

We're using some smart tricks to reduce shifting / re-calculation but it's still surprisingly very difficult to achieve on the web. (not to mention, we're literally the very first open-source rich document editor for the web that has WYSIWYG paper-mode that works 100% on client-side, with no server-side calculations. [due to on-device encryption we can't use servers to calculate these with delta changes / updates etc] โ€“ย so due to us being literally the very first, we can't even google solutions to some of these problems ๐Ÿ˜… we have no choice but to invent some solutions that work across all browsers and doesn't rely on closed-source tools)


Hoping this makes sense! Thanks a million for your patience with this in the meantime! โœŒ๐Ÿป

Best, J

BasilTomato commented 2 years ago

thank you for the detailed explanation!