Added a Find/Replace facility

[pkriens]

• Case sensitive or not
• Wrap search
• Only whole words
• Not modal
• Command-F opens the dialog. When there is a selected text in the current tab, it will be the find target
• Command-G finds the next find target
• Can search and replace all in other tabs
  • will search from cursor, next tabs, before cursor if wrap search is on
  • if found, that tab will be current
• Wildcards using globbing
  • foo*bar – foorrrrbar
  • foo\d\dbar - foo12bar
  • {foo,bar} – foo or bar

[grayswandyr]

Thanks! Further remarks/issues/wishes:

• Differentiating Replace>Find from Replace is nice but doesn't seem much standard to me (the former meaning is AFAIK the one implemented in most editors). Perhaps remove Replace or move it past Replace>Find, which is the most common.
• The checkbox about case sensitivity is insensitive when checked, and vice versa
• When typing Ctrl+F, the search window appears and you can enter the string to look for, but neither hitting Enter nor Ctrl+F/G works, you have to move with Tab to Find or click Find
• Ctrl+Z-ing a replace/replace all takes 2 steps to come back to the original situation, instead of 1.
• Replace the Search Tabs string by All tabs or In all tabs
• Search tabs doesn't always start the search in the currently-displayed tab, which I would find more intuitive
• Sometimes, search (with a glob, but I don't know if it's specific to that mode) doesn't highlight the found string (I don't know what was found). It seems to come back if I first focus on the editor then click Find again
• A backwards mode would be useful

[pkriens]

Hmm, I remember why I should not do these things :-(

Differentiating Replace>Find from Replace is nice but doesn't seem much standard to me (the former meaning is AFAIK the one implemented in most editors). Perhaps remove Replace or move it past Replace>Find, which is the most common.

Which is the most used by you ... :-) I changed the order but I am used to Eclipse which has a replace.

The checkbox about case sensitivity is insensitive when checked, and vice versa fixed.

When typing Ctrl+F, the search window appears and you can enter the string to look for, but neither hitting Enter nor Ctrl+F/G works, you have to move with Tab to Find or click Find

Added them as shortcuts to the buttons

Ctrl+Z-ing a replace/replace all takes 2 steps to come back to the original situation, instead of 1. Yup, too bad. This is a long standing issue in Alloy. It happens with all text replaces. Not time to figure out what the cause is.

Replace the Search Tabs string by All tabs or In all tabs done though not sure this better.

Search tabs doesn't always start the search in the currently-displayed tab, which I would find more intuitive

Hard to imagine. The code is completely independent of Alloy and gets the tab 0 indexed from current. You have to show me an exact scenario. Changed quite a bit to make backward search possible so it might work now.

Sometimes, search (with a glob, but I don't know if it's specific to that mode) doesn't highlight the found string (I don't know what was found). It seems to come back if I first focus on the editor then click Find again

There is something fishy. When I switch the tab now, I force the JTextPane to grab focus. Seems to work but imho this is all magic.

A backwards mode would be useful

You're not very shy are you? :-) It was a challenge so i could not resist ... Reverse search with regular expressions is not trivial. I am not guaranteeing perfect matches around the cursor in the first pane though, is tricky. Especially with globs.

[grayswandyr]

When typing Ctrl+F, the search window appears and you can enter the string to look for, but neither hitting Enter nor Ctrl+F/G works, you have to move with Tab to Find or click Find Added them as shortcuts to the buttons

Still doesn't work on my machine but that's OK.

Search tabs doesn't always start the search in the currently-displayed tab, which I would find more intuitive Hard to imagine. The code is completely independent of Alloy and gets the tab 0 indexed from current. You have to show me an exact scenario. Changed quite a bit to make backward search possible so it might work now.

Can't reproduce this in the new version, so forget it.

Two remarks:

• can you link Backwards Search to Shift+Ctrl+F/G?
• When invoking Ctrl+F for the first time, the 3 middle buttons are greyed out and I must first do Find before i can do Replace>Find (which I'd call Replace & Find next)

A further non-shy wish (if you have time, no pressure!): smart case find & replace. As a Java programmer, I guess you know how useful this is :-)

[pkriens]

Would be nice if you could approve this one as well @grayswandyr

[grayswandyr]

I don't understand what Cmd+D does?

[pkriens]

It expands the selection to the next block. It allows you to see how the parser decomposes the tree and it makes it easier to select a full expression.

pred x {
         always one Int or no String
}

if you select Int, press Cmd-D, then it will expand to always one Int, when you do it again, it expands to always one Int or no String, and again selects the predicate. It basically expands up the ancestor tree. It is kind of useful if you want to see how the parser decomposed your expressions. I am still always surprised by always :-)

I'd been experimenting with searching semantically. I.e. search for references to a field or a sig and thought it was interesting. We already keep a compiled module. We could even rename a sig or field reliably without text matching.

Anyway, I can remove it if if you don't like it ...

[grayswandyr]

I like it but it doesn't work on the two files (which I can't disclose) I tested it with. On one file, everything is selected after one Cmd-D stroke; on the other, nothing is selected. We can still keep the fetaure saying it's best-effort and sometimes it doesn't work, or remove it. I'm not sure it's worth spending too much time on it to fix it. Tell me what you prefer.

[pkriens]

Lets keep it in there. If I get examples I can adapt. It follows the parse tree but it is very sensitive to the Pos position. If the expr span is identical, I go up a level until I find a larger span.

With this approach I could also refactor. I.e. change the name of a sig or field. This would only affect the selected sig/field even though there could be other texts that have the same name.

Anyway, can you can approve this PR now?