From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Sam Steingold Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99848: (compilation-save-buffers-predicate): Date: Mon, 12 Apr 2010 17:47:28 -0400 Message-ID: References: <4BBF536E.4090702@gnu.org> <87r5ml3icx.fsf@gnu.org> <4BC37C58.1030306@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1271108878 24755 80.91.229.12 (12 Apr 2010 21:47:58 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Apr 2010 21:47:58 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 12 23:47:57 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O1RU3-0000vd-D4 for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 23:47:56 +0200 Original-Received: from localhost ([127.0.0.1]:53954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1RU2-00062t-Vo for ged-emacs-devel@m.gmane.org; Mon, 12 Apr 2010 17:47:55 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1RTi-0005vg-Ow for emacs-devel@gnu.org; Mon, 12 Apr 2010 17:47:34 -0400 Original-Received: from [140.186.70.92] (port=41835 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1RTg-0005uo-CM for emacs-devel@gnu.org; Mon, 12 Apr 2010 17:47:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1RTe-0005ci-FO for emacs-devel@gnu.org; Mon, 12 Apr 2010 17:47:32 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:48633) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1RTe-0005ca-CY for emacs-devel@gnu.org; Mon, 12 Apr 2010 17:47:30 -0400 Original-Received: by gwb15 with SMTP id 15so4038416gwb.0 for ; Mon, 12 Apr 2010 14:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:received:message-id:subject :from:to:cc:content-type; bh=Caq9kYVoDPIkOK98KFwqDKGE9mOJ2d4ck9pEuTO9egU=; b=WuTqUDgaGvQ6F/90prs4VcSGxGEPiseuA0PhImNwzmzPVaw71VTjzhBl0d67WrUE9w YcETmXP+19InVAcqxszVOshrJCfS0aJ1pvVHzJe/LRajHu8IEPTFhmxCFqmzxkEPNjQ2 xjqaWNTr1EM5g8JsEzG+eHuwEvFtlx4/cmujY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rQB52j764U1Dmj1SmaAhJ9cbGhIHWuulsBG0XrxU2N/PLaRHbSGlD0G5W915/nKbrg Vj0wQE3nrV2O+b+TI0WrEBqI/O0BjonCaQd2TMd7NxHjGfaxQKXO/OW202WRNCA2kyva gW7FPlgjtjEculjYhs1lu3XN9cQaB3gpqwRc8= Original-Received: by 10.150.157.12 with HTTP; Mon, 12 Apr 2010 14:47:28 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: c59d1aac510d646a Original-Received: by 10.151.94.1 with SMTP id w1mr4479266ybl.72.1271108848920; Mon, 12 Apr 2010 14:47:28 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:123547 Archived-At: On 4/12/10, Stefan Monnier wrote: > >> 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. > > Ah, yes, that would be a good reason, sorry for being so dense. sorry about being unclear on this. > >>>> 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). > > > Ah! Thanks for finally answering my original question "Could you > explain how you see it being used?" ;-) > > My first answer would have been: in that case it probably shouldn't be > a defcustom. But by now, I think we *can* give it a good global default > value (and justify it being a defcustom). > > This default value will depend on Emacs being able to figure out what is > "the current project", which is something where Emacs needs to improve > anyway, so it's a good direction. ok. > >>>> - 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 > > > Could be. In my case this build-dir has always been the same as the > project's root, but indeed there may be cases where something else > is needed. We'll cross that bridge when we get there. actually, in my case, the build directory is different from the root, so I think that bridge is already there. note also that the build directory can easily be _not_ under root, but somewhere far far away, on a separate partition. -- Sam Steingold