I have used Allaire/Macromedia Homesite since it's beginning and am now at the point of making a change to a new IDE but it is a difficult change as I have been married to Homesite for so long.

I have spent about a month evaluating potential Editors/IDEs and have a collection of 34 potentials that I have thoroughly analyzed. NuSphere PhpED is in the top 3 however there are some very annoying issues which prevent it from being #1 in my opinion and thus prevent it from being my final choice.

The most prevalent issue and the only major issue which prevents me from changing to PhpED is as follows. I hope someone may be able to advise me of a workaround or that work is being done to eliminate the issue entirely. It is very likely that others may not consider this an issue...so I apologize if I make it sound as though it is detrimental...it is for my use.

When requiring/including function/class libraries (absolute reference) within the document I am working on; Code insight of functions/classes which reside in the included/required files will not work UNLESS I define both a workspace and a project and specify Code insight include directories containing these libraries.

If I wish to make some minor changes to a file or files and open them via the Explorer Tab, Code insight will not work unless I open the project these files are a part of. Many times (almost all the time) I simply wish to open a directory in the Explorer Tab and begin adding and editing files without having to define (or open) a project or workspace. I just want to get to work.

Is there some workaround to this? I don't want to create a workspace or project in order to utilize Code insight.

Thanks for any assistance anyone can provide.

-Dave

Right.
If you create project, IDE knows where your libraries are. To allow the IDE to work without projects, we would have to duplicate all the project settings in the global ones including path to the libraries, that would be specified somewhere so effectively you'd have to set the same settings anyway why not to do it for a project?

Regarding absolute references, I think they are not that good, especially if one day you decide to install your application onto a web with different disks/directory tries.

Even if we re-do the IDE and make it smart enough to recognize valid absolute references in include() statements, it would not help much, becase a) most of libraries I saw does not use absolute references and therefore we would not move further with resolving other files names b) in most cases it makes sense to build up CodeInsight database on all the files of the library and don't spend time with resolving particular include()s, so it's necessary to know library path anyway.

Ditto, however I found the migration very easy and it was actually a relief. The only thing I needed to change was the syntax colouring and I felt right at home.

Same here, although that's already long ago

PhpED (and every other IDE I know, btw) requires you to make a few things in a certain manner (setup, projects, file organization, development practises). In the beginning, this "feels" bad because it seems to be different from what you have done so far and you feel overly restricted.

However, I've seen (and others have reported this, too) that once you accept these - and not try to resist or work against it - things will work out very well. You get used to it and will no longer see it as a restriction at all.

Most of all, with PhpED you should get used to keeping all your projects in separate local folders, set up a project for each one, develop locally and deploy to your remote machine when you're done. If the SRV webserver is not powerful enough, maybe you even want to setup Apache+MySQL on your box for that (or use a shared "local development server" if you have several devs, mount the docroot using Samba).

This seems to be overkill at the first moment, but once you have established that, you will find that your whole approach becomes more professional:
- Clearly separates production from development
- You can use the debugger features, but don't need the dbg extension in production environments
- Working locally is more comfortable - no network latency, more speed
- Clearly separated projects; you will automatically find out which files are "libraries" (i. e. reused) and set these up as projects of their own
- Helps you to write code that is more position-independent (not using absolute paths or assume where everything is)
- The whole "everything separated and local"-approach is exactly what you will need once you decide to start keeping your projects in CVS
- Makes it much easier to install & test different versions (betas, release candidates) of PHP without breaking things on your production machine

Most of these are things you never thought about before, because you were only using an editor with fancy highlighting to edit remote files on a production machine via ftp... not really a "software development approach"