Sure, I had this in mind - but the patch is completely independent of where the project file is located. So for instance if you have:
~/foo.geany and project directory is in: ~/projects/foo then foo.geany refers to files as: ./projects/foo
But then how does it work when I move projects/foo somewhere, foo.geany is again disconnected. Thats why I suggested that the project file had to move with the project tree so the relative addresses kept working.
Yes, that's true. Clearly both ways of doing it have some advantages and some disadvantages. The disadvantage of your solution is that the thing like renaming the projects directory I mentioned in my last example wouldn't work. For me, relative paths are better (I can move the project to different accounts with different home directory and directory structure) but I can imagine that for someone who often moves the project file relatively to the project directory, absolute paths are better. But is the latter really common real-life use case scenario? If so, a configuration option should be introduced.
Maybe the paths in foo.geany should be relative to the project base directory, not the project file, then if you move the project you only have to correct the base directory and it will all work again.
Sure, can be done, but this won't do what you expect would happen. Why:
1. Move the project file so the paths become invalid. 2. Load the project (none of the files opens because the paths are invalid) 3. Edit the base directory. 4. Save the project file - this saves all the open documents but because there are none of them open, it just clears the list in the project file.
This would only work if you edit the project file manually before you open it.
Cheers,
Jiri
Cheers Lex
Another example:
the project directory is in: ~/projects/bar and the project file under: ~/project_files/baz/bar.geany then bar.geany refers to files as: ../../projects/bar
The only problem might be under Windows if you store the project file on different volume than the project directory - then you cannot construct the relative path but I think nobody would do that. And of course you should move project files so that the relative path against the project file and the project directory remains unchanged. This would work well if you have:
~/projects/foo.geany ~/projects/bar.geany ~/projects/baz.geany ~/projects/foo ~/projects/bar ~/projects/baz
which is something geany defaults to with having project file one directory above the project directory. (In this case without the patch if you rename "projects" to something else, all the paths get broken but they remain preserved with my patch applied.)
That said, I'm not against making this behavior optional - depends on what others think.
Cheers,
Jiri
I think this patch is a good idea, but only if the project file is in the tree, so maybe it needs to be dependent on that preference setting, or better still have its own preference setting so that the user has to choose to not be backward compatible.
Cheers Lex
Signed-off-by: Jiří Techet techet@gmail.com
src/keyfile.c | 39 ++++++++++++++++++++++++++++++++++----- src/keyfile.h | 2 +- src/project.c | 26 +++++++++++++++++++++++--- 3 files changed, 58 insertions(+), 9 deletions(-)
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel