Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99848: (compilation-save-buffers-predicate):

[Sam Steingold <sds@gnu.org>]

Stefan Monnier wrote:
>>>>>> - I like where this is going, but I'm not sure this is enough.
>>>>>> Could you explain how you see it being used?
>>>>>> if you edit a huge file which is expensive to save, you do not want it
>>>>>> to be saved whenever you start a compilation elsewhere.
>>>>> ;-) that part I understand of course.
>>>>> But I mean what value do you expect users to use it with?
>>>>> Would they globally set it to save one particular directory of theirs?
>>>>> What if they have more than one project?
>>>> this is problematic because compile does not announce what it's working
>>>> directory is.
>>> Any reason why we can't fix that?
>> no, and here is a solution:
> 
> I don't understand.  You're saying there's no reason why we can't fix it
> and then you go ahead and point me to a workaround.  Maye we're not
> talking about the same thing.  By "announce what it's working dir is"
> I mean "make sure default-directory has the proper value".
> 
> Introducing `compile-default-directory' is not the end of the world, but
> to my naive eyes, if `default-directory' doesn't point to the right
> place, it's a bug to be fixed.

default-directory "Automatically becomes buffer-local when set in any fashion"
this means that it is useless in compilation-save-buffers-predicate because 
that is called inside the buffer to be saved and thus for it default-directory 
should be the directory where the buffer is located.

>>> How 'bout this:
>>> - we provide some way for the user to explain to compile.el how to find
>>> her projects's root directories (e.g. a list of tell-tale file names).
>> this is tricky: some files might be ordinary for some projects and the
>> tell-tale for others.
> 
> I know, that's a significant problem, but I can't think of a really good
> solution other than push it onto the user by providing a customizable
> variable.  My main goal here is to make sure that we can support the
> case where the user has several projects, which seems like a common
> enough case, especially for Free Software hackers.

I think this variable should be buffer-local (with an eye on being set in 
dir_locals).

>>> - and we can also provide an option to "cd to project's root before
>>> running the command".
>> I doubt the value of this.
> 
> I've used several build systems where this is necessary (e.g. a single
> Makefile at the root, or something equivalent).  I usually work around
> it with something like M-x compile RET cd ..; make RET, but if `compile'
> could insert the "cd .." for me when needed it would be even better.

this sounds like a case for yet another buffer-local variable - build-directory

 >
 >>> How does that sound?
 >> fine.
 >> gonna do it?
 >
 > ;-)
 >
 >
 >         Stefan
 >
 >
 > PS: We're talking here mostly about designing a good default value for
 > your new variable, right?  Or if not default, at least a value that can
 > be listed in the possible options so the end user doesn't have to write
 > her own predicate function.
 >
 >
 >