web-client icon indicating copy to clipboard operation
web-client copied to clipboard

[Feature Request] search&replace in documents

Open BasilTomato opened this issue 4 years ago • 5 comments

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

BasilTomato avatar Sep 03 '20 15:09 BasilTomato

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

johnozbay avatar Sep 04 '20 09:09 johnozbay

Thank you!

BasilTomato avatar Sep 04 '20 10:09 BasilTomato

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

BasilTomato avatar Nov 09 '21 15:11 BasilTomato

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

johnozbay avatar Nov 15 '21 10:11 johnozbay

thank you for the detailed explanation!

BasilTomato avatar Nov 15 '21 11:11 BasilTomato