Bug 148989

In description you are talking about editor search. So reassign to the editor for evaluation.
As for the "Find In Project" functionality you can find line breaks by using '\r' and '\n' in the regexp. The same for
the replace ...

Yes, the regex way is a kind of workaround here, but ...
1. it must be learned, nothing for beginners, of if you are in a hurry. wildcard's are much more complicated than just
using '*'.
2. I'm more thinking about a cut-'n-paste usage for find AND replace.

What about of transforming the cut string to a valid regex-string on pasting it into the Find/Replace dialogue?

(In reply to comment #2)
> What about of transforming the cut string to a valid regex-string on pasting it
> into the Find/Replace dialogue?

Another interesting idea.
This would slightly teach users in regex over the time, a little!

But please have a look on combined find/replace dialogue of NotePad++, and how they deal with \n \t etc..
This is my favourite from all editors.

I think, we don't need 2 separate dialogues and actions for find and replace, but better availability in any context e.g. bug 187174 148984 146810.

*** Bug 194292 has been marked as a duplicate of this bug. ***

*** Bug 189029 has been marked as a duplicate of this bug. ***

*** Bug 184191 has been marked as a duplicate of this bug. ***

*** Bug 158046 has been marked as a duplicate of this bug. ***

*** Bug 195575 has been marked as a duplicate of this bug. ***

I will change whole infrastructure for search, which will enable multiline search and regexps.

This is a big change and it doesn't have a high priority now. I hope it will be at least in 7.3.

Regexp search/replace is working in NB 8.0 FCS build.  I just used it to match newline characters with \n.  I think this issue can be closed.

(In reply to swpalmer from comment #10)
> Regexp search/replace is working in NB 8.0 FCS build.  I just used it to
> match newline characters with \n.  I think this issue can be closed.

I do not think so. The request [1] was to paste in text which has linebreaks and which isn't formatted as regex.

[1] https://netbeans.org/bugzilla/show_bug.cgi?id=148989#c0

I also don't think this should be closed. The functionality needed is to allow the user to select text in the editor and find other occurrences of that selected text at least within the current document.

For me, I want to be able to find duplicate blocks of code in order to identify functionality that can be replaced with more maintainable functions.

Bump. Really, without this in my workflow I consider stop using Netbeans. I started using it today. This is such a simple but useful thing to create. Have I missed anything? I dont want to convert things on the fly to regex. 

Sometimes I just want to do a fast search marking text .. 
- copy
- ctl+f
- paste
- enter
.. and editor jumps to line

Even Dreamweaver has this since 2005.

(In reply to lindberg123 from comment #13)
> Sometimes I just want to do a fast search marking text .. 
> - copy
> - ctl+f
> - paste
> - enter
> .. and editor jumps to line

NetBeans has Ctrl+F3 to search either selected text or an identifier under cursor (if no selection is present).

I think, 10 votes can be considered as more than P4.

Here is a concrete example of something that should work, but doesn't. Ages ago, in code that I am cleaning up, a tool created lots of named queries that were never used. They are still present in 75 files and look like this:

@NamedQueries({
  @NamedQuery(name = ..., query = ...),
  @NamedQuery(name = ..., query = ...),
  @NamedQuery(name = ..., query = ...),
  @NamedQuery(name = ..., query = ...),
  ...
})

I tested the following regular expression in a search:

@NamedQueries\(\{.*?\}\)

But the matching appears to be done line by line, so this doesn't work. If it did, I would be able to clean up all files in a single operation.

There should be an option for global matching rather than line-by-line matching. I think that would also take care of the original request. The default for this option should be single-line search except when multiline text is pasted into the search field. For multi-line search in Literal and Basic Wildcards mode, the "containing text" field should be a text area. In Basic Wildcards mode, * and ? should not match text containing line breaks, and any style of literal line break (\n, \r, \r\n) should match any style of line break in the files.

(In reply to swpalmer from comment #10)
> Regexp search/replace is working in NB 8.0 FCS build.  I just used it to
> match newline characters with \n.  I think this issue can be closed.

No. Until there is support for multiline wildcard matching, it's nowhere near ready to be closed.

To add insult to injury, multiline regex may work in the "test" flyout, but not when applied.

Find/replace Regex to find HTML FORM opening tags which may be broken over multiple lines:

<form([^>]*)>

Sample text:

<form name="foo"
action="/foo.php">

Matches in the test flyout, *does not match* when applied to project files. (8.0.2)

Inconsistency like that makes the test function rather pointless. It's hard to even comprehend in what kind of design the two could behave differently.

There is neither support for in-line modifiers such as (?s), nor UI features (more checkboxes) to set them pattern-wide (apart from "i"). If you are going to cite java-util.regex.Pattern syntax right there in the UI, how about supporting it?

Incidentally, there is one method (hilariously elaborate) to achieve a multiline match in NetBeans search/replace for the example above, thanks to at least having explicit matching capability now as you point out:

<form((?:[^>]|\n|\r)*)>

So yes, if we look for "anything except '>', OR a newline, OR a carriage-return", we're in business.

PS - I've just received two bounces from CCs' mail servers, forwarded back to me by the Oracle mail server after making the above comment, so now I know two of the CC list's real email addresses (albeit both AWOL or defunct). If you're going to go to the trouble of giving us all "masking" email addresses (can't see the point of this myself), you might try to ensure the mask stays on the face, eh?

Some comments suggest that you should be able to select some text and by pressing Ctrl+F the text should be copied to the 'Find What' field as valid regular expression.

Does this also include to escape characters, which are special tokens in regexes, like brackets and dots?

Eg. if I select this from comment 16:

@NamedQueries({
  @NamedQuery(

and press Ctrl+F to start searching, I'd espect this to be in the find field when searching for regular expressions is enabled:

@NamedQueries\(\{\n  @NamedQuery\(

Or should I create a separate bug for escaping brackets, dots, question marks, etc.?

Sebastian

I had used Netbeans and left years ago. Recently I decided to give it a try and really loved it; so many improvements since I last used it. But it's unbelievable that it still lacks a multi-line search/replace and that's a total deal-breaker for me. Having a multi-line text input and being able to make a simple text search with that input contents shouldn't be too hard to implement. It's not regex, just plain text search. It really comes handy being able to select chunks of code and copy/paste it into search input and paste some other multi-line code to replace input - and have all occurrences replaced. Even some basic editors have this.

It would perhaps be one of the most basic refactoring features. Say if you want to replace code containing 5 lines of code in a set order with a method call. How many times did I get RSI and bloody eyes doing this kind of thing? What is the human error rate? What is the point of running PMD CPD if my IDE does not give me any action to do anything with the output? I feel like an idiot while AI is everywhere around me.

(In reply to bht from comment #21)
I'm with you with the part I understand, but can you please explain the abbreviations, so I can understand the other parts.

These acronyms were for RSI = Repetitive strain injury, PMD CPD is the tool that finds duplication in source code, AI = Artificial Intelligence. What I meant to say is that computers are fairly smart today, and that there is perhaps some catching up to do. But I must admit that the solution is not trivial if it is really useful, so perhaps that could be a field for a plugin.