I would estimate that the find and replace we envision would require a
minimum of a couple of month of full time work by an experienced
developer. It would require a deep-dive into multiple parts of the
application to understand how many different parts expose find/replace
style things:
* text files
* Notebooks as a whole
* Notebook cells
* file browser (just find)
* Multiple documents
* New third party defined extensions/document types.
Each of these search contexts would need to be able to expose/provide
a consistent API that can be plugged into a modular set of UI
components that provide the search UI and display results. Then those
same original components would need a second API that the search
facility can use to render matches. To get a sense of the complexity
involved, I would have a look at how VS Code does search/replace in
different contexts. Even though this will be a lot of work, it will be
less work, and a better UX than us reimplementing search/replace
across all these different contexts.
> --
> You received this message because you are subscribed to the Google Groups
> "Project Jupyter" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to
jupyter+u...@googlegroups.com.
> To post to this group, send email to
jup...@googlegroups.com.
> To view this discussion on the web visit
>
https://groups.google.com/d/msgid/jupyter/a61ca4ee-e713-4bf3-81aa-eeb9c25e2181%40googlegroups.com.
> For more options, visit
https://groups.google.com/d/optout.
--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgra...@calpoly.edu and
elli...@gmail.com