Interactive find with selection mode

[aaxu]

I have a couple questions regarding how we should design this function. Currently, selected text prior to entering interactive find will be transformed into a single regex line. However, if the selected text contains more than one line, then the regex search will contain \n characters, but this will make it so that the search will not match to anything since we have a carriageReturn function that handles this. Not sure if there will be a easy way to handle this..

Another weird thing that I noticed is that if you copy and paste several lines into the search area, only the first line will be used for searching,

I also have a few ideas of how to make the interface better:

• Have two mode, one for regex and one for standard search. If the program is in standard search, then do not convert the selected text to a regex line. If not, then convert.
• Maybe make the window increase in lines (up to a certain point, say 5 lines) so the user can see a bit more if their search contains multiple lines.
• Make cursor blink in the InteractiveFind window so it is clear that the user is editing the search when in InteractiveFind.

Let me know your thoughts on this and how you think we should re-design this to accommodate multiple lines or if it is even necessary sine it's not very common (at least from personal experience).

[dschuyler]

I've got some work-in-progress on a multi-line Find UI, but it lead me into a rabbit hole. I need to revisit it.

[Here are some notes from ci_edit/design/find. I'm sorry that this is a bit of rambling that isn't formally lain out]

Find UI

What features should a find / replace tool have

find (xor i.e. a radio button or dropdown selection)

• all
• next
• prior

replace (xor)

• all
• current
• next
• prior

regex (boolean) match case (exact) smart cap replacement (boolean, smart means that lower case says lower case; upper case stays upper case) span lines (boolean. aka wrap) whole words (boolean, aka by word) within (as in, find within this context)

• anything (same as selecting all options?)
• comments (a grammar?)
• code (a grammar?)
• licenses (a grammar?)
• selection
• quoted (strings) though maybe this is a grammar
• a particular grammar (like py, js, cpp)

files

• recursive (boolean)
• where (multi-selection i.e. checkboxes)
  • current file
  • open files
  • current directory (or include '.')
  • path
    • include (list of strings)
    • exclude (list of strings)

Maybe (not sure on these)

• mark lines with matches (boolean)
• querySelect style
• find misspelled word
• error (i.e. go to the next compile error or similar)
• external call/script
• highlight all matches (boolean)

Might be a silly idea, but what about a set notation so say where and how to search

Something that would describe what to search (e.g. search in comments or don't search in comments).

within: code || comments || content || markup || quoted /* && marked && selection */ within: -code +comments -content &marked +markup &quoted =selection

Here is a draft of a multi-line find UI

   find: dog
replace: cat
options: -exact +highlight +regex +smart -words +wrap
 within: +code +comments +content +markup +quotes
that is: -marked -selected -changed
  paths: +example.txt
exit^w  forward^f  reverse^r  replace^s  all^e  mark^m

There are some options that I'd like to operate on the main document

undo/redo/save/quit if these actions are done in the find UI, they should affect the current file.

[aaxu]

Wow that's a lot of options. It sounds complicated and I'm not sure if it'll make the bar really convoluted and cause a steep learning curve, but it's nice if we want to become the most customizable editor!