unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Sam Steingold <sds@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r99848: (compilation-save-buffers-predicate):
Date: Fri, 09 Apr 2010 12:18:54 -0400	[thread overview]
Message-ID: <4BBF536E.4090702@gnu.org> (raw)
In-Reply-To: <jwv7hoh8gqo.fsf-monnier+emacs@gnu.org>

Stefan Monnier wrote:
>>> - Please don't autoload defcustoms unless you have a *really* good
>>> reason to do it (and even then, ask permission first).
>> I autoloaded this one because its sibling compilation-ask-about-save
>> is autoloaded.
> 
> Thanks.  So we can remove this ;;;###autoload

done.

>>> - 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.
I can add a variable compile-default-directory which will be nil globally and 
bound to default-directory in compile and recompile; then the users will be 
able to set compilation-save-buffers-predicate to
(lambda ()
  (string-prefix-p
    (locate-dominating-file compile-default-directory "foo")
    (file-truename (buffer-file-name))))
so that only files located in the currently compiled project are saved.
here "foo" should identify the project root, it can be, e.g., "configure" or 
"COPYING" or "README" or "OMakeroot" or "ANNOUNCE".
we can also use "bzr root"/"hg root" instead of locate-dominating-file.
this, however, becomes more and more expensive.

> Part of the question is because Customize doesn't know how to set/handle
> defcustoms other than globally.

I think the above setting would be fine globally.
Note that the "foo" above is very project-dependent and should be tweaked by 
the user to the flavor of one's projects.

>>> Could you also explain why `compilation-directory' can't be
>>> used instead?
>> because if you are working on a project foo and compile in directory foo/src,
>> you do want to save buffers editing foo/headers/baz.h,
>> but it is not under compilation-directory, which is foo/src/.
> 
> Can you imagine a way to make it "work automatically", maybe assuming
> some particular convention that's followed half-often or that would be
> easy to adjust to?

we can add compile-root-directory in addition to compile-default-directory to 
save on locate-dominating-file / "bzr root" calls.
the reasonable heuristics are:
1. if the compilation directory or the one right above it (for those who build 
in separate directories) is under a VC system which supports the "root" 
command, use that. this fails for multiple projects in the same tree - although 
not catastrophically (i.e., we might save extra files, but we are not likely to 
miss saving when it is necessary).
2. if the compile-command invokes "omake", then (locate-dominating-file 
compile-default-directory "OMakeroot") should be good.
3. locate-dominating-file on "configure", "ANNOUNCE" and "INSTALL" should be 
good, although "README" probably not.




  reply	other threads:[~2010-04-09 16:18 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1NzYsW-0004b6-Iu@internal.in.savannah.gnu.org>
2010-04-07 19:00 ` [Emacs-diffs] /srv/bzr/emacs/trunk r99848: (compilation-save-buffers-predicate): New custom variable Stefan Monnier
2010-04-07 20:40   ` Sam Steingold
2010-04-09  3:13     ` [Emacs-diffs] /srv/bzr/emacs/trunk r99848: (compilation-save-buffers-predicate): Stefan Monnier
2010-04-09 16:18       ` Sam Steingold [this message]
2010-04-10  1:04         ` Stefan Monnier
2010-04-11 19:21           ` Sam Steingold
2010-04-11 20:28             ` Stefan Monnier
2010-04-12 20:02               ` Sam Steingold
2010-04-12 21:15                 ` Stefan Monnier
2010-04-12 21:47                   ` Sam Steingold
2010-04-13  0:04                     ` Stefan Monnier
2010-04-13 17:07               ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4BBF536E.4090702@gnu.org \
    --to=sds@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).