[Geany] relative paths in project files: is there an option?

Stephan Beal sgbeal at xxxxx
Thu Jun 30 10:00:17 UTC 2011


On Thu, Jun 30, 2011 at 11:40 AM, Lex Trotman <elextr at gmail.com> wrote:

> I'm sure you had a very embarrassing interview with someone about why
> you broke the production server and are very annoyed with yourself,


i didn't actually - the marketing people who complained got the generic
technical explanation that a software bug caused it.


> especially as the full file path shows in the title bar ('aint I a
>

Nobody who works with a document-editing tool reads the titlebar on a
regular basis.

shtinker rubbing it in...:-) but my point is that no matter how we
> store filenames they may point to unexpected places when you move
> stuff, and relative files doesn't fix that.


It does if one does NOT use .. in the path names: use names in the form
a/b/c or /a/b/c. i have implemented this in my own software and know it to
be reliable. Storing relative paths ".." in them is just downright
dangerous.

[...]

> 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.
>
> Well I top your experience by at least 10 years and I have seen many
> project layouts which are forests not single trees, as I noted in a
> previous post.  It is a perfectly normal thing for builds to manage.
>

But such forests are (A) managed under a single common root or (B) they are
are not managed via a single project file (i.e. not by IDEs).


> The problem here is simply the session records rather than anything else.
>

Right.


> 1. session files which are the concern of the individual programmer and
> 2. project data which does go with the project tree.
>

Amen.


> As Matthew pointed out there is a use-case (and a common one from past
> user input) where project files don't go in the tree, they live in the
> users ~/projects. In this case the sources are probably not under your
> project file so relative is irrelevant, its back to absolute.
>

And i believe that such a use-case lies in the realm of gnome-text-editor
instead of an IDE. IDEs are (traditionally) designed to manage specific
source-based projects, not OS-wide collections of arbitrary trees.


> Its actually we big system people who tend to have the need to keep
> project data in the vcs, and who have the control over the projects to
> be able to do it.  Can you imagine approaching Linus asking to put a
> Geany project file in the Linux vcs? or any GNU project? or ...  so in
> all these cases the project file is user local outside the tree.
>

If i was hacking the /usr/src/linux i would drop (or symlink) my .geany file
into that directory. Problem solved. With the current behaviour, my project
file will be invalid the next time i upgrade and get /usr/src/linux-X.Y.Z+1.

i'm not convinced that having the project file outside the repo provides any
benefit or any safety against path-related errors. Not only that, but it
challenges common conventions (unsuccessfully, it turns out).

And when the project file is outside the tree then absolute makes sense.
>

Then store those as /a/b/c instead of a/b/c. Problem solved.

On Thu, Jun 30, 2011 at 11:51 AM, Lex Trotman <elextr at gmail.com> wrote:

> On 30 June 2011 19:21, Joerg Desch <jd.vvd at web.de> wrote:
> > On Thu, 30 Jun 2011 10:42:02 +0200
> > Stephan Beal <sgbeal at googlemail.com> wrote:
> >
> >> i've been programming professionally for going on 20 years now, and i
> ...
> > Same here... ;-)
>
> Sigh, another young 'un..
>

But hobby-wise going on 30 years - since 25 December, 1983 :). My first line
of code was something like:

CALL CLEAR

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/users/attachments/20110630/53ed39e3/attachment.html>


More information about the Users mailing list