My company uses subversion for SCM, so naturally I decided to add ".svn" to my ignored files list in phpEd.

If I right-click on the project and Search in Files, the progress dialog very distinctly lists all of the files contained in .svn as it searches. This not only doubles the search time, but it also polutes the search output.

You can easily avoid this if you list needed file extensions in "File Masks" input, for example *.php;*.inc;*.html

Apparently you've never used subversion.

Svn keeps a mirror copy of your checked out version of code in the .svn directories. It makes diffs nearly instantaneous, unlike CVS.

That's not a valid answer, say, if I don't know what file extension the search string might appear in.

I do have to say that I'm getting increasingly turned off by the "support" offered on this board when reporting bugs with the product. I was reporting a bug, not asking for a half-assed workaround that doesn't even apply.

These are things that need to be fixed, but from my point of view, they're clearly being ignored.

Actually, I also haven't used Subversion yet. I probably don't know how it works. Shame on me.

If you would read this board for some more time you would notice that the support Nusphere provides (with their lead developers being really active here) is far above the level I'm accustomed to from other companies. Be sure they care for what you say .

As always, when communiating, expect that your counterpart does not understand you; be prepared to explain in more detail what you need. But most of all: say it in a polite manner .

E. g.

"It would be nice if it would be possible to specify the file mask in the 'find in files' dialog not only as a 'white' list, but also the other way round - to specify file/directory masks to be excluded from the search."

I'm sure that one can make it into the next 4.1 release (4.0 is said to be released pretty soon).

You might consider it as a bug if documentation said that Find in Files will not try to find in "hidden" directories.


This list has no effect on Find in Files functionality.


It's rather rare case. Say if you're looking for an HTML tag, it could be found in HTML and PHP files and you always know the extensions.
I can hardly imagine if you use more than 10-20 file extensions for all your web development. I mean the web tree, of course. And even 10 is too much

He's got a point, using Subversion means that being able to ignore .svn directories. Is there any reason _not_ to exclude ignored directories?

FWIW, I like the support here...

Wait. Re-read what you wrote. "Find in Files will not try to find in hidden directories" ... that means it should do exactly what I expect it to do. Not find files in ignored/hidden directories.



Obviously, which is why I reported it as a bug, clearly marked in the title of the post. The files aren't "ignored" if they're only ignored in one portion of the product.



Wouldn't it be nice if you designed the layout and file extensions for all of the products which have used phpEd. I've worked on projects, and for companies, who mapped virtually anything and everything to the PHP handler in Apache. If it has an extension, it'll parse, for all intents and purposes. Whether I like that, or not, it doesn't matter. The point is that you, as a/the developer, don't end up deciding how your customers use your product in their development process, as frustrating as that may be. (Which I'm well aware of, having worked for several of the top-10 hardware and software companies in the world.)

However, when something that's clearly a bug is reported as such by a user, "then don't do that" isn't a valid answer. The only place that answer belongs is as the punchline to the old "Doctor, Doctor!" joke.

I've read the boards fairly extensively in the last year+ that I've been using phpEd. The fact that developers do hands on support is to be applauded, but being a developer who does the same, I don't necessarily find it impressive by itself.



I'd have said that, if that were the bug I was reporting. The bug is simply that "ignored" files are not as ignored as they're suggested to be. That's it.

ok. Suppose it's a bug and it's been fixed by your request.
Now suppose you have 5 projects. Suppose each one has its own list of ignored directories. Suppose you clicked on Edit->Find, selected find in files and entered whatsoever directory to find in. What project's list of hidden files (directories) should be used in this case?

There are two answers to this; one 'acceptable', and one 'good'.

The acceptable answer is "the active project."

The good answer is "whichever project the searched directory applies to." Example:

Projects:
/1
/2
/3 (active)
/4

Find in files:
/4/foo

Use project /4's ignores.

Realistically, something like this, in semi-pseudocode.



This would allow ignores to work, accurately, even if you specified "/" as the search path (using the projects noted above). Each directory change would intitute a check to see which set of ignores were to be used.

a) when I said "whatsoever directory" I meant that you might want to search in any directory out of the projects at all.
b) project directories can be overlapped. So one physical directory can correspond to zero, one, two or more projects.
c) you can start searching in some levels higher than the project's root, so the settings could be applied later when the Find engine reaches the root.

So a) it's not always possible to find project corresponding to the directory the Find engine is looking in b) Corresponding project may vary depending on the directory the Find engine is working in.

From the documentation point of view, isn't it too hard to explain why some certain files were looked for searching phrase while some others were not?

I'd assume that "good" IDE should apply project's hidden directory setting only when "Search in" is set to "Active project". Using the project settings is rather expected behavior then

As long as the active params are applied, that makes me happy. I've never been one to put multiple projects into a single workspace, as I find it really kind of clumsy and bug-causing (in the "two projects have the same filename and similar code, which file am I working on" sense)