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.
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
*** Issue 33075 has been marked as a duplicate of this issue. ***
Unbelievable, nobody can move with this since 2001. Is it knowingly
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
but the schema changes, and you are now required to write
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
I've got a very simple use-case I actually ran into yesterday. I was
doing refactoring and I was modifying all calls from:
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 :)
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!!
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
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?
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".
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
*** 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
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
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-
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.
firstname.lastname@example.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-
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?
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:
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
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 - email@example.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
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 (firstname.lastname@example.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
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
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:
ResultView.form (deleted - last rev. 1.4)
NodeRenderer.java (1.1 - initial revision)
RemoveFromSearchAction.java (deleted - last rev. 1.3)
ReplaceTask.java (1.1 - initial revision)
NodeListener.java (1.1 - initial revision)
ContextView.java (1.1 - initial revision)
MatchingObject.java (1.1 - initial revision)
Item.java (1.1 - initial revision)
IssuesPanel.java (1.1 - initial revision)
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)
next.png (1.1 - initial revision)
context24.gif (1.1 - initial revision)
context.gif (1.1 - initial revision)
prev.png (1.1 - initial revision)
TextCustomizer.form (deleted - last rev. 1.18)
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...
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
5. This came out:
Is it a problem with the replacing or somewhere else (to be expected in a
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.