This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Ability to search and replace text across multiple files and/or directories
Changed to enhancement
Target milestone -> 3.4
Target milestone was changed from '3.4' to TBD.
reassigne to utilities module
*** Issue 30166 has been marked as a duplicate of this issue. ***
This has 12 votes (one of the most of anything in Issuezilla) - don't you think something firmer than P3/TBD is warranted?
When I start implementing new features, this will be the first feature on the list. Not guaranteed to be implemented for NB 4.0 (for now).
It is now planned to implement this feature by the internal milestone "Promo D". It should definitely be no later than in NetBeans 4.0. It probably will not be in NetBeans 3.6. See also: http://www.netbeans.org/community/planning/proposed/roadmap.html http://www.netbeans.org/community/planning/proposed/36/index.html
I've implemented a little module 'regexpreplace' which allows to replace found substrings in FileObjects of selected nodes (see contribs). It is based on regular expressions and it is fast and easy. Could you have a respect to this 'draft' when you will design the replace feature in IDE? I've checked its usabillity many times :).Thanx
I can't promise anything until I see the module. Where can I get it? I have looked at the three auto-update centers and did not find it.
I've uploaded it at contrib website: http://contrib.netbeans.org/servlets/ProjectDownloadList (the last one now).
*** Issue 33075 has been marked as a duplicate of this issue. ***
Unbelievable, nobody can move with this since 2001. Is it knowingly ignored?
It should be in the next release after 4.0.
Is the target milestone 4.1?
will this issue be implemented ? there is even solution from Eman H., this issue has 27 votes and 4 more on IMO duplicate issue 10021 Status is STARTED for more then year, I'm changing it to DEFECT and TM=TBD to get things moving...
Gili and others interested in this feature, I know that this feature is long awaited and that it has many votes for a long time. When deciding about which features and enchancements we should implement for NetBeans 4.0, we knew that many of you had asked for this feature for a long time. On the other hand we knew that the team implementing refactoring features were to finish the Rename... feature. We hoped that this feature would fulfil your needs to search & replace strings in multiple files, so we decided to put more effort on enhancements of the JUnit module. NetBeans 4.1 is primarily focused on enhancements of the projects infrastructure and minor features and enhancements. We need to adapt to the infrastructure changes and we do not have much time for other features and enhancements so search & replace on multiple files will not be added in NetBeans 4.1 either - sorry. Please tell us why the refactoring Rename function does not work for you and describe your use-cases and needs so that we can re-evaluate necessity and form of this feature.
The "Rename..." refactoring command is in no way a sufficient substitute for a true search and replace command. There are many situations in which replacing a string in a large file set is relevant including the following situations which are not covered by "Rename...": 1. Fixing all related javadoc after changing the class name LargeCar to HugeCar. The "Rename..." command only takes care of source code, not JavaDoc embedded in source code, so the class name LargeCar is still used in sections surrounded with /** */ in all source files. 2. Fixing JavaDoc after changing general terms used in a project. For instance if a use case name changes, you would want to make sure that all JavaDoc which contains the old use case name is updated. 3. Replacing embedded identifiers or tag names in XML files. If a schema allows you to declare a <largeCar>1234</largeCar> but the schema changes, and you are now required to write <hugeCar>1234</hugeCar> Similarly, the "1234" identifier could change across files. 4. Just like 3. above, but with properties files In general many systems contain lots of other files than just .java files, and since the "Rename..." only works for .java files there is an infinite number of situations in which "Rename..." is not sufficient. Think of all the places you could use a search and replace command: JSP files, HTML files, txt files, ... Being very fond of NetBeans I must say that I find it embarrasing that a technologically simple yet very powerful feature like this has not been implemented yet. May I remind you that search and replace across files was implemented already in the last millenium in popular IDEs like Microsoft Visual J++. In hopes of seeing this feature soon Randahl
Marian, I've got a very simple use-case I actually ran into yesterday. I was doing refactoring and I was modifying all calls from: themeNode.getTheme().isSubscribed() to themeNode.isSubscribed() A simple rename would not handle this. What basically happened in the code is that instead of retrieving the contents of a container and then invoking isSubscribed() on it, I wanted to invoke isSubscribed() on the container directly. I don't think any refactoring tools would have helped here. As Randahl pointed out, there are use-cases where project-wide Search or Search & Replace is needed and it has nothing to do with renaming. Thank you for your explanation on why this wasn't implemented sooner. I understand your reasoning and I must agree that the rename refactoring functionality has helped aliviate the need for this function somewhat -- but not completely. I guess one of the first questions I have is how hard is it to really implement this feature? We already have a search & replace on a per-node basis. Can't we simply the project search & replace invoke the command recursively in lower nodes? Sorry, I know nothing about Netbeans development, but it is just a thought :) Gili
I want to echo Randahl's concern that refactoring's "Rename" won't handle the infinite number of use cases involving non-java files! Just in the past month I've had two occasions/projects where I had the unenviable task of trying to replace some strings in dozens of HTML files. Using Netbeans, I had to "Find in Projects" and then manually do a replace in each file found :-( I was so aggrevated by this that I sent out an email to nbusers mailing list pleading with others to vote for this bug. This "feature" was asked for 4 years ago (probably even earlier: i vaguely recall people asking for it before NB was bought by Sun.) Sun should be friggin' embarrased that it can't implement such a popular and USEFUL feature in 4 years time!!
ping... I'm still missing a conclusion with this issue... Marian, do you have all that you need for make a decision what to do with this issue? IMO, you do. 1, You have use-cases - refactoring's rename doesn't cover renaming strings in non-java files, etc. 2, you have patch form ehucka 3, last but not least - it has 36 (!) votes I'd like to know - Will it be implemented? When? thank you.
No, I do not have all I need. Since this is not the primary feature to be implemented by me for the next release after 4.1, I need to estimate how much time does it take. I looked at the Replace module by Emanuel Hucka and projectized it (so that I can work with it in NB 4.x). The UI is far from ideal (and hard to understand, with no documentation or help). It seems that it simply modifies files on the disc, with no respect to files currently opened in the editor. I want to arrange a meeting between me, Emanuel and editor people but I postponed it because I am now helping the J2EE people with their bugs. I will add more information after we accomplish the meeting.
Is there any progress? It's top voted issue and it's also pretty old.
"It seems that it simply modifies files on the disc, with no respect to files currently opened in the editor." IMHO, that is what it should do. If the user needs to modify 1000 files, It's probably not a good idea to force he/she to open those 1000 files in the editor before he/she performs the search/replace. Or maybe you should implment a checkbox "Only search in open files".
vnicolici, I think what is meant is that if you search and replace 1000 files but two of them are currently open, they will get updated on disk but not in the open editor and then when you close those files there is a chance they will save to disk and clobber your search & replace changes; which is obviously not what the user expects.
*** Issue 10021 has been marked as a duplicate of this issue. ***
Issue #35555 contains useful comments from Tim Boudreau - read them before implementing this feature.
Implementation of this feature is tentatively planned for NB 4.2.
Here's a description line from the documentation of jEdit, another editor written in Java: "Multiple file search and replace; search in either the current file, all open files, or all files in a directory". If you need to know how it's done, jEdit is open source. I'm glad to see that it is at least on the radar here at NB, finally. Regarding the question of changing files on disk that are opened in the editor, all three of the editors I use regularly (emacs, sciTE, Textpad) either notify me if a file has changed on disk while I am editing it, so that I can revert to the changed version; or update the buffer automatically when the change is detected. The obvious example of where this occurs is when I check the file into CVS and have a CVS tag like $Id$ in the file.
Does anyone know what the status of this is? I just downloaded the 4.2 daily build and I don't see anything listed under the Edit menu. I'm a new user of NetBeans and I like it a lot from what I've seen of it so far. The most glaring omission in functionality that I've seen so far is the lack of a Replace in Files function. I hope this issue really does get resolved in 4.2. It looks like this issue has been out there for some time. Is anyone actively working on it?
Another useful feature would be a search and replace within selected text within a single file. This way you can do a replace all, but, restricted to a highlighted block of text. For an example, see Visual Studio. Eclipse also has this feature. Another thing that I noticed is that if you highlight say a word on a single line, and then hit Ctrl+F, it makes the selected text the default for the find. This I like. However, I think it would be nicer if it would do the same thing if you simply had the cursor on a word rather than having to select it. Also, it seems like '.' shouldn't be a word character. For example, if you have the text "header.jsp" in a file and you do a search for "header" and you have "Whole Words" checked, it won't find it. The same thing is true for '-'. This behavior is different than other editors such as Visual Studio and Eclipse.
I agree with everything jemiller said except the last part about '.' and '-' being excluded from as a word character. I am not fully sure excluding these characters is a good idea (their meaning is context dependant, so who's to say?)
You should also be able to specify a filename extension filter as well. For example, you might want to restrict the search to *.java or *.jsp. The same applies to the Find in Projects dialog. It would also be nice to be able to tell it to skip specified directories. i.e. you might have generated files in the build directory that you might want to skip or at least be able to tell it to only look in the src directory.
come on, in my office eclipse users are laughing at me...
It is pretty sad that work on such a basic feature has stretched out over so many years with so little progress. It seems so lame to have to switch to a different editor to do global search and replace. Come on guys!
mpetras, what will be with this issue? Is it still maintained by you?
I've heard many people asking for this feature. It was also requested on last NetBeans day in San Francisco. When is it planned to be implemented? It's currently the top voted issue in IssueZilla.
Indeed - although I only have a mild irritation towards the non-existence of this feature, I have been hearing people asking for this very pin-pointed feature enough of times. And put it this way (correct me if I am wrong), this feature will not have any negative impacts once implemented, and the specs is relatively straight- forward. That leads me to wonder why this can still be a missing feature since 3.3 dev; because in a way this seems to be a solid evidence that the majority have been getting along well with NetBeans without this feature rather happily!
The fact that it's the top voted issue means that people really want it. I see no downside in having this feature in NetBeans.
Don't get me wrong, I'm all for the feature ;-) It just strikes me as odd, the state as of it is now, that's all.
alexlamsl@netbeans.org ha scritto: > And put it this way (correct me if I am wrong), this feature will not have any > negative impacts once implemented, and the specs is relatively straight- > forward. Ok, guys. I'm quite new to netbeans and probably i should stay quiet in the background and let you talk about this "issue". I know also that's all free and there are also other IDE i can use instead of staying here and whine but things are really becoming absurd. Are you really talking about specs? Specs? This, IMHO, defect, bug, issue, whatever, has been filed, let me cut and paste: Fri Nov 30 20:30:00 +0000 2001. It's more that four (4) years ago. 4 years and here people is talking about specs? It's a search and replace function! Almost all editors have it nowadays come on... copy from them! Netbeans has a lot of complicated refactoring functions and does not have this little one feature. > That leads me to wonder why this can still be a missing feature since 3.3 dev; > because in a way this seems to be a solid evidence that the majority have been > getting along well with NetBeans without this feature rather happily! > . My opinion is that the majority likes netbeans in its complex and does not stop using it only because it lacks a basic feature that is not needed so frequently, but it's useful when you need it, and that can be "workaraounded" using the first stupid editor downloaded from the net. Sorry guys for beeing straigthforward but as i told you in my previous message: Eclipse users in my office are laughing at me. They are laughing rigth now while i'm reporting them what's happening here... what can i say to them? ciao
You can tell them that Eclipse also has it's issues. Just search bugzilla on eclipse.org and see issues with more than 50 votes (the top one is really interesting). You can have fun as well. That said, we need to have this feature.
Well said Romane. I guess this issue is the best starter for www.nbbounty.org, what do you think ?
Yes, nbbounty.org could help :)
IMO, Eman already provided his solution. Emane, update it and maybe you can offer it on nbbounty.org when there is no interest here ;)
I have already implemented better solution of this feature in my application (tree preview, regexp etc.). I can provide it as an inspiration :).
Tim Boudreau implemented this feature as a module in contrib/searchandreplace. He's asking for feedback because he's developing it somewhere on the airport so he can't try it on other OSes/platforms. Send feedback to him to tim dot boudreau at sun dot com. Let's see if Eman's or Tim's solution is better...
I built Tim's module against 5.0 APIs and you can download it here: http://roumen.name/blog/nbms/org-netbeans-modules-searchandreplace.nbm To try it out, just execute search/replace action from context menu of a project. It may need some polishing, but it works, I think that Tim should add it to nbextras.org so that people can get the module easily.
In reviewing all the text in this sudden outburst of commentary on this issue, on which I first commented in June 2005, I am struck by the thought: "Why is this a topic of conversation?" What I would like to know is, why has the NebBeans project management team refused to implement this feature? A specific answer to that question would allow us to address specific concerns. Otherwise, we're just like a dog chasing its tail. (And, it seems to me, the whole "rename ... refactoring" pseudo-solution was nothing but an attempt to avoid actually implementing this feature.) We don't seem to have any power to generate any movement on this issue. It appears to be a classic case of a development team ignoring its users because the way the users use the application doesn't mesh with the way the developers want them to use it. Addon, ad hoc modules and workarounds don't cut it. When I go to my "Edit" menu, I should see "Search/Replace in Files". And so should every new user of NetBeans -- research and modification of the application should not be required to perform such a simple action. Finally, at some point, if this feature is just not going to be implemented, the project managers should declare "as designed," close this bug and reject all future bugs filed on this issue. Put a note in the FAQ and be done with it. As things stand presently, I easily can see this conversation continuing to 2010. NB. I installed Roman's version of Tim B's module on my linux version of NB 5 and I do not have any context menu options for s/r.
In Tim's module the search/replace action is in the project context menu - which means you need to right-click on your project to see it. Is it really not there? I think it should be rather in the Edit menu, but that's how Tim implemented it now. AFAIK the reason why this feature was not implemented was resource-related. Marian to whom this issue is assigned works on several other modules. Marian, can you comment this? Thanks.
Btw, it might be a similar case as issue 2337 which was implemented recently. Opened for ages, but finally implemented for 5.0.
5.0 is out of door. We'll have to wait ages for 6.0 - IMO. TM=5.0 has no sense - changing to TBD for another evaluation
I've updated the search and replace module in CVS to move the action to the Edit menu. Note that it not only works over projects, it works over any folder on disk that you select - it is both in the project popup menu, and also in the popup menu available from any folder. Note that right now, the main menu item actually isn't enabled when a project is selected :-/ I need to write an action that proxies the enabled state of either the project sensitive action or the folder sensitive one and uses whichever is enabled - I'll get to that soon. pdxlooie: I get that you want this as a core NetBeans feature, and I agree it should be one. I think there are a bunch of reasons why this hasn't been implemented in the past - one of them is that a function like this can trash somebody's hard drive if it goes wrong, and so writing such a thing is a bit daunting. Anyway, if you are not seeing any items in the popup menu, please let me know which popup menus you're referring to. And note the module requires JDK 5 to be enabled - make sure it really is in Module Manager (it uses some functions of Charset and nio that weren't available in 1.4, and is marked as requiring 1.5 in the module's manifest, so it won't be loaded on 1.4 but you should see a warning on startup telling you that).
Tim, Thanks for the response, suddenly we have visibility! As far as technical issues are concerned, I pointed out last June that jEdit, an editor with which I'm sure you are familiar, has this feature and has had it for some time. So, I'm not minimizing the significance of the technical effort but the fact is, it's already been done. I will experiment with your module, now that I have more information. Thanks. mp
Please send me an email - tboudreau@sun.com - if you have any problems, requests, etc. Perhaps the spookiest bit of code you can write is something that someone could run against the root of their hard drive that would go off and whack every dll or whatever on their system - spookier still if you know that by writing it, several hundred thousand people will end up using it and god help you if you screwed up. Either a lot of self confidence or insanity is required...I'm settling for unit tests as a substitute for both :-) So please, *try* to break it - kick it, beat it, do the most ridiculously pathological things you can possibly think of asking it to do and if it does something stupid, tell me. Try to run it out of memory, file handles, whatever you can think of that would lead it to trash a hard drive. This thing has to be beyond bulletproof before it ships in any version of NetBeans - it's not a place for brave and stupid :-)
Tim, I totally agree with what you've said - until I realised that you mean possibly trashing *my* hard drive :-O But yes I'm sure I can get a college machines and strain your module on there ;-)
We (several people at Sun) have discussed UI of Search & Replace but have not found any solution about which we would think "Yes, this is a good solution." We realized that we do not know enough information on typical usage of the feature. I would like to ask several questions those of you who use Search & Replace (in UltraEdit, Vim, Emacs, other IDEs, wherever). Please do not post your answers here but rather send them directly to me (mpetras@netbeans.org) or reply to my e-mail at 'nbusers'. Thank you. 1) What is the rough number of files over which you perform replace with a simple invocation of the Search & Replace (S&R) action? Is it 5 files, 10 files, 30 files, even more? 2) How many matching strings there are in the files - 50, 100, 200, more? 3) When you use S&R, how accurate is your pattern, i.e. what is the approximate ratio between the number of matches you actually want to replace and the total number of matching strings? Is it close to 95% (19 matches replaced, 1 skipped), 90% (18 replaced, 2 skipped) or significantly less? 4) When you are deciding whether to replace the matching string or not, how much information do you usually need to make a decision? Is name of the file enough? Is the single line containing the matching string enough? How often do you need a broader context of the line within a file? 5) What is the need that makes you use Search & Replace? What do you replace? Is it parts of a source code (e.g. names of variables)? Or you want to change strings (labels of UI elements)? Or XML elements? Anything else? 6) Is support for regular expressions important for you? Is support for multiline regular expressions important for you? Do not hesitate to send even more information if you think it might be important regarding the design and implementation of the Search & Replace feature. I will send a summary of your answers here before I start implementing the UI.
Thank those of you who answered for the important information. Here is a summary of your answers as I have put it to the introduction to the UI specification: --------------------------------------------------------------------------- According to the survey I made among people interested in this feature, it is apparent that: * most people run the Replace action on dozens or even hundreds of files * there are dozens and often hundreds of matches found * users specify the search patterns as precisely as possible to avoid false matches – the result is that they usually replace 95 % or more of the found matches * to allow and/or ease precise specification of search patterns, most users use regular expressions in them * for many people it is enough to see the line containing the matching string to make a decision whether the string should be replaced or not; on the other side, many people (although less) need to see a broader context of the matching string * some users want to use multiline regular expressions and multiline replace texts – this use case will not be covered by this specification and by the initial implementation --------------------------------------------------------------------------- Together with implementation of Search&Replace, I will probably make some changes to the design of the Find dialog - I will address (fully or partially) issues #35256 ("Specifying files to search in the Find in Files dialog"), #35257 ("Make the Find in Files dialog less context-dependent") and #63864 (Support for "Find in the Current Project").
> to allow and/or ease precise specification of search patterns, most > users use regular expressions in them This is probably true of the people you asked for feedback, but I would be extremely surprised if it were true of the user population at large. I'm not saying that you should not support regexps, but I don't believe they should be a prominent part of the search UI; it should be an advanced feature or something hidden by default. The info you got does suggest that if the user exposes the regular expression UI (whatever that is), that should probably be visible by default for future searches. It would be nice if the UI could try to auto-detect if a regular expression has been entered (maybe try Pattern.compile() and see if it doesn't fail if certain characters are present?) - but let the user override this as well (sometimes you want to search for a regexp).
I think 'regular expressions ui' can be just one checkbox - enable/disable regexps. It is enough for both implementation and for users.
"This is probably true of the people you asked for feedback, but I would be extremely surprised if it were true of the user population at large." How am I to understand this? Should I ignore answers of those 15 people? Should I consider their answers as not representative simply because you (the only one) do not use regular expressions in search&replace? "I'm not saying that you should not support regexps, but I don't believe they should be a prominent part of the search UI it should be an advanced feature or something hidden by default." The support for regexp will be as prominent as it is in the current Find dialog. But it will NOT be hidden, definitely. As for the rest of the comments: there will be a "Regular expression" check-box (as it is now). If this check-box is checked, the entered search pattern is considered a regular expression and the replace text may contain back references to regexp groups defined in it. The check-box is unchecked by default and the user must check it for each new search (unless they select a previously entered regular expression from the combo-box) - this remains unchanged, too.
As long as the default is to have the regexp check box unchecked everybody is happy IMHO. But Tim is right (again IMHO) that the average user will not use reg exp for text find - e.g. I have never done that through my entire life from the IDE (using perl from command line is entirely different story). Maybe the usability studies that Jirka Mzourek should be doing are not that bad idea, did you ask them to include this into one they conduct? Just a side note: people who use reg exp as primary way to search are not "normal" ;-). You should have asked them what is their IQ and if that would be in the range 140-160 on average you would not conclude that the average IDE user has IQ 150, right?
IMH "Final User" O... so take it easy. I think that the interface should be similar (with the same default behaviour) to the find/replace in single file that is already present in the IDE (with the obvious addition of the "what files do you want to shred?" interface). From a user view i see the search/replace function as one. Then it's my choice to apply it to the current file or to a set of files. If you add support for, let's say, voice recognition in one of them, i think that the other should be updated as well. And btw i think that having this at least in NB6 (it's too late for 5.5 eh?) would be nice so, if it helps, do a first implementation that works exactly as the standard "current file" implementation but on a set of files. Then you can start to think about speech recognition, rfid support, neural networks and whatever you, me and other users like to see implemented. my two eurocents ciao
The significance of the regexp functionality will probably depend on how the regexp engine is implemented. Regexp are surprisingly useful even in "ordinary" text searches. I use them frequently. But if the editor relies on a "modified" regexp pattern-matching mechanism, the usefulness of the regexp option can be substantially diminished. These mods can make it more difficult to use regexp for those of us schooled in perl or Java or other standardized regular expressions. One assumes that NB will use the Java RegExp classes and therefore, its functionality will be as anticipated by the NB user. At any rate, it sounds like the new functionality has been designed as I would expect it to be and in a predictable manner. (For example, to use RE in TextPad, you have a checkbox below the search textfield. That checkbox maintains its state between searches.) As far as the poll is concerned, "the squeaky wheel gets the grease." The respondents may indeed be unrepresentative of the user population as a whole, but they are the ones following this issue and sufficiently interested in it to write about it. You do, however, have to be careful how far you generalize the results of the polling, considering the size of the sample. It appears to me that good decisions have been made. We are on the verge of getting some very desirable functionality ... finally. ;-)
Regexps provide a very powerful search facility and with positional matching, can allow very powerful replacements. I do agree that having it off by default is a good thing. But, it might be nice to have a link to a regexp tutorial off of the dialog so that users who are not aware of regexps, or who need a refresher can find appropriate information.
+1 for maintaining the same UI For search and replace whether it is invoked for a single file or multiple files. If you want to add additional UI beyond that how about we leave it for a separate enhancement request (as it isn't necessarily given that everyone would agree)?
I think the state of the "Use RE" checkbox should be retained, like it's in other editors (UltraEdit for example).
All you need to do is look at what Visual Studio (2005) has to see what's needed to be implemented. It's intuitive and powerful. Searching is easy using a regex or not. This is unrelated, but, another thing that I like about the way VS works is the fact that it has a notion of a "solution" which is a container of projects. You can restrict a search to a solution, a particular project, or, you can a directory and whether you want it to recurse or not. You can also specify the file extensions to filter on.
Fixed (implemented) in the trunk. Modified, added and removed files: utilities/src/org/netbeans/modules/search/: ResultView.form (deleted - last rev. 1.4) PrintDetailsTask.java (1.9) NodeRenderer.java (1.1 - initial revision) RemoveFromSearchAction.java (deleted - last rev. 1.3) SearchTask.java (1.17) ReplaceTask.java (1.1 - initial revision) SearchPerformer.java (1.39) NodeListener.java (1.1 - initial revision) ContextView.java (1.1 - initial revision) MatchingObject.java (1.1 - initial revision) Bundle.properties (1.35) ResultModel.java (1.54) ResultView.java (1.35) Item.java (1.1 - initial revision) IssuesPanel.java (1.1 - initial revision) Manager.java (1.10) ResultTreeModel.java (1.1 - initial revision) TextDisplayer.java (1.1 - initial revision) ResultTreeChildren.java (deleted - last rev. 1.15) TextFetcher.java (1.1 - initial revision) utilities/src/org/netbeans/modules/search/res/: next.png (1.1 - initial revision) context24.gif (1.1 - initial revision) context.gif (1.1 - initial revision) prev.png (1.1 - initial revision) utilities/src/org/netbeans/modules/search/types/: TextType.java (1.27) TextCustomizer.java (1.34) FullTextCustomizer.java (1.18) Bundle.properties (1.13) TextCustomizer.form (deleted - last rev. 1.18) FullTextType.java (1.54) Diffs: http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/PrintDetailsTask.java?r1=1.8&r2=1.9&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/NodeRenderer.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/SearchTask.java?r1=1.16&r2=1.17&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/ReplaceTask.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/SearchPerformer.java?r1=1.38&r2=1.39&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/NodeListener.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/ContextView.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/MatchingObject.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/Bundle.properties?r1=1.34&r2=1.35&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/ResultModel.java?r1=1.53&r2=1.54&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/ResultView.java?r1=1.34&r2=1.35&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/Item.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/IssuesPanel.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/Manager.java?r1=1.9&r2=1.10&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/ResultTreeModel.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/TextDisplayer.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/TextFetcher.java?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/res/next.png?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/res/context24.gif?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/res/context.gif?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/res/prev.png?rev=1.1&content-type=text/vnd.viewcvs-markup http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/types/TextType.java?r1=1.26&r2=1.27&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/types/TextCustomizer.java?r1=1.33&r2=1.34&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/types/FullTextCustomizer.java?r1=1.17&r2=1.18&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/types/Bundle.properties?r1=1.12&r2=1.13&diff_format=u http://utilities.netbeans.org/source/browse/utilities/src/org/netbeans/modules/search/types/FullTextType.java?r1=1.53&r2=1.54&diff_format=u
Yiiiheeeeeeee! Many thanks! - can't wait for NB6!
Ladies and Gentlemen, Thank you very much!! I should love this (hmm, how can I get hold of a trunk build?) for two reasons: foremost, enjoying the functionality, and secondly, it shows that the NB team is committed to implemented or fix even very old bug reports and enhancement requests. Otherwise NB would be in danger to build up a reputation similar to the one that the JDK had before Mustang, namely that some bugs never get fixed (in Mustang bugs reported 10(!) years ago have been eliminated). It would be great if, in this respect, release 6.0 could be (and I am confident it will be) for NB what Mustang is for JDK/JVM. Now if only the 6.0 dailies and the changelog on the NB website could be resumed... Georg
Great. But if there would be an ability to preview contents of replaced files before replace it will be excellent. ;)
couldn't that be done using a search before doing replace?
Is there a plugin of the current build for nb5.5 available?
There is no plugin for NB 5.5 available. It should be possible (and easy) to port it to NB 5.5 - just apply the patches (diffs) on the NB 5.5 sources and rebuild the Utilities module.
I tried a 6.0 daily a few days ago but couldn't find this. How do I access this functionality?? I'd like to test it. Thanks NB team!!!!
*** Issue 90537 has been marked as a duplicate of this issue. ***
Wanted to tried this in NB 6.0 M8 but I got an exception: 1. Selected "Web Pages" folder in a web application. 2. From the "Edit" menu, selected Find/Replace in Projects 3. Entered the search and replacement strings. 4. The Search results opens with 34 files to be changed. I clicked directly in Replace 5. This came out: java.lang.AssertionError at org.netbeans.modules.search.MatchingObject.replace(MatchingObject.java:598) at org.netbeans.modules.search.ReplaceTask.doReplace(ReplaceTask.java:142) at org.netbeans.modules.search.ReplaceTask.replace(ReplaceTask.java:91) at org.netbeans.modules.search.ReplaceTask.run(ReplaceTask.java:77) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:541) [catch] at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:963) Is it a problem with the replacing or somewhere else (to be expected in a Milestone release)?
It is probably a bug in the search-and-replace code. It will probably not be fixed in M9 because of lack of time (two days remaining for development). I will provide a binary patch for M8 once I fix the issue.
> (two days remaining for development) But after that there is a full week for bugfixing, isn't there?
Yes, you are right. I thought only high priority bugs could be fixed but we have a whole week for fixing any bugs. So this issue might be fixed.