On Thu, Jun 30, 2011 at 2:29 AM, Lex Trotman <elextr@gmail.com> wrote:

Personally I don't see the point, they are all subject to risk of
pointing to the wrong place if you move things, relative or absolute.
Basically the way the project file stores filenames is no concern of
the user,

It damned well is the user's concern when the behaviour causes the wrong files to be edited (that's called "data loss" where i come from). i edited/broke pages on a live/production web server because i checked out a second copy of the site's source tree on the site's machine and started editing that second copy (or what i thought was the second copy - geany was using the old paths).

so why confuse things with an option that is still always
possibly wrong, KISS leave it absolute.

i agree with that, but the current behaviour is dangerous.

Limiting to the project tree would be totally unacceptable, there are
always things outside the tree that you want to open, and have re-open
when you restart.

i've been programming professionally for going on 20 years now, and i have _never_ seen a source tree which has files from _outside_ the source tree managed by build/project files within the source tree. Not one single time. i challenge you to show me one high-profile (i.e. not only on your hard drive) project where such a constellation exist.

In my own software where i have had to deal with this problem, i took a very simple approach with which i never had any unexpected problems/behaviours:

a) The project file's directory (where we load it from) is the virtual root.

b) Paths to files under that root are stored relative.

c) Paths to outside that root are stored absolute.

This is easy to do in the project-file-writing code with a function call like (normalized=NormalizePath(theFilename)), and to un-do when loading the project file.