.emacs-settings.el

.emacs-settings.el

[Robert J. Chassell]

I cannot remember what you said earlier.  How is ~/.emacs-settings.el
different from the long-used settings file ~/.emacs?  How is it
different from site-start.el or default.el, if those files exist?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: .emacs-settings.el

[Davis Herring]

> I cannot remember what you said earlier.  How is ~/.emacs-settings.el
> different from the long-used settings file ~/.emacs?  How is it
> different from site-start.el or default.el, if those files exist?

.emacs-settings.el can go in other directories than ~; it affects files
found anywhere in the directory tree that contains it.  Moreover, it is
not a file of arbitrary Lisp, but rather contains a set of buffer-local
variables to set in the buffers visiting files it affects, subject to the
normal risk-checking.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: .emacs-settings.el

[Juri Linkov]

>> I cannot remember what you said earlier.  How is ~/.emacs-settings.el
>> different from the long-used settings file ~/.emacs?  How is it
>> different from site-start.el or default.el, if those files exist?
>
> .emacs-settings.el can go in other directories than ~; it affects files
> found anywhere in the directory tree that contains it.  Moreover, it is
> not a file of arbitrary Lisp, but rather contains a set of buffer-local
> variables to set in the buffers visiting files it affects, subject to the
> normal risk-checking.

Since .emacs-settings.el is a confusing file name, what about a more
appropriate and shorter file name like .dir-vars.el or .dir-locals.el
or .project.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .emacs-settings.el

[Robert J. Chassell]

   Since .emacs-settings.el is a confusing file name, what about a
   more appropriate and shorter file name like .dir-vars.el or
   .dir-locals.el or .project.el.

That is an excellent idea!  How about .project.el?

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 6 Sep 2007 15:23:54 +0000 (UTC) "Robert J. Chassell" <bob@rattlesnake.com> wrote: 

RJC>    Since .emacs-settings.el is a confusing file name, what about a
RJC>    more appropriate and shorter file name like .dir-vars.el or
RJC>    .dir-locals.el or .project.el.

RJC> That is an excellent idea!  How about .project.el?

I would not make it hidden, to avoid surprises: project.el

Also, C-h v and customize-variable should say that project.el has
overridden a variable, so the user doesn't have to wonder.  There should
also be a user-visible message when project.el is detected and used.

Ted

Re: .emacs-settings.el

[Michaël Cadilhac]

[-- Attachment #1.1: Type: text/plain, Size: 931 bytes --]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 6 Sep 2007 15:23:54 +0000 (UTC) "Robert J. Chassell" <bob@rattlesnake.com> wrote: 
>
> RJC>    Since .emacs-settings.el is a confusing file name, what about a
> RJC>    more appropriate and shorter file name like .dir-vars.el or
> RJC>    .dir-locals.el or .project.el.
>
> RJC> That is an excellent idea!  How about .project.el?
>
> I would not make it hidden, to avoid surprises: project.el

So sad the features of project.el will not be usable in the lisp/
directory of Emacs, then :-)

FWIW, I'm for .dir-locals.el or dir-locals.el.

-- 
 |   Michaël `Micha' Cadilhac       |  Would someone please DTRT with this,  |
 |   http://michael.cadilhac.name   |        then ACK?                       |
 |   JID/MSN:                       |          -- Richard Stallman           |
 `----  michael.cadilhac@gmail.com  |                                   -  --'

[-- Attachment #1.2: Type: application/pgp-signature, Size: 188 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 06 Sep 2007 18:04:30 +0200 michael@cadilhac.name (Michaël Cadilhac) wrote: 

MC> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I would not make it hidden, to avoid surprises: project.el

MC> So sad the features of project.el will not be usable in the lisp/
MC> directory of Emacs, then :-)

I think surprising the user is a bad thing, so I'd rather not have a
hidden file.  The penalty of name conflicts is not as bad as using
hidden data to influence an application's behavior.

I'm ok with dir-locals.el or any other name, but in general it should
not be an .el file, right?  It's just some settings that will not be
actual Lisp code.  Maybe dir-locals.elp for "emacs lisp properties"?

Ted

Re: .emacs-settings.el

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Sep 2007 18:04:30 +0200 michael@cadilhac.name (Michaël Cadilhac) wrote: 
>
> MC> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> I would not make it hidden, to avoid surprises: project.el
>
> MC> So sad the features of project.el will not be usable in the lisp/
> MC> directory of Emacs, then :-)
>
> I think surprising the user is a bad thing, so I'd rather not have a
> hidden file.  The penalty of name conflicts is not as bad as using
> hidden data to influence an application's behavior.

Uh, you are arguing against _any_ file with a .* name right now: all
of them are used to influence an application's behavior without
cluttering directory listings.

So I don't buy this argument.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 06 Sep 2007 21:34:32 +0200 David Kastrup <dak@gnu.org> wrote: 

DK> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Thu, 06 Sep 2007 18:04:30 +0200 michael@cadilhac.name (Michaël Cadilhac) wrote: 
>> 
MC> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>> I would not make it hidden, to avoid surprises: project.el
>> 
MC> So sad the features of project.el will not be usable in the lisp/
MC> directory of Emacs, then :-)
>> 
>> I think surprising the user is a bad thing, so I'd rather not have a
>> hidden file.  The penalty of name conflicts is not as bad as using
>> hidden data to influence an application's behavior.

DK> Uh, you are arguing against _any_ file with a .* name right now: all
DK> of them are used to influence an application's behavior without
DK> cluttering directory listings.

DK> So I don't buy this argument.

I think you've missed the difference between a hidden file anywhere in
the directory tree and in a well-known location.  We're talking about a
{project,dir-locals}.el file that in /a, /a/b, /a/b/c, or /a/b/c/d could
affect the settings for /a/b/c/d/* and every file under that.  You'd
have to do a `find` to get all the hidden files (or some equivalent
shell game).  That's what I mean by "suprising" and "hidden."  Only a
few applications put such hidden settings files outside the home
directory, I can think only of the CVS .cvsignore and Subversion .svn
directories at the moment.  Emacs doesn't do that AFAIK, so it would be
at least a little surprising to current users.  I personally think it
would be a bad design decision.

Files like .emacs, .profile, etc. are in a single, well-known location,
so they are easy to find.  This compensates for their invisibility
(whether that's a good design decision is another discussion that's not
pertinent).

Ted

Re: .emacs-settings.el

[Juri Linkov]

> I think you've missed the difference between a hidden file anywhere in
> the directory tree and in a well-known location.  We're talking about a
> {project,dir-locals}.el file that in /a, /a/b, /a/b/c, or /a/b/c/d could
> affect the settings for /a/b/c/d/* and every file under that.  You'd
> have to do a `find` to get all the hidden files (or some equivalent
> shell game).  That's what I mean by "suprising" and "hidden."  Only a
> few applications put such hidden settings files outside the home
> directory, I can think only of the CVS .cvsignore and Subversion .svn
> directories at the moment.  Emacs doesn't do that AFAIK, so it would be
> at least a little surprising to current users.  I personally think it
> would be a bad design decision.

I think this problem can be completely mitigated exactly with the same
solution you already proposed, i.e. C-h v and customize-variable should
say that the variable's value is overridden by .project.el or .settings.el
(like C-h f says that the function is advised).

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .emacs-settings.el

[Ted Zlatanov]

On Fri, 07 Sep 2007 00:07:50 +0300 Juri Linkov <juri@jurta.org> wrote: 

>> I think you've missed the difference between a hidden file anywhere in
>> the directory tree and in a well-known location.  We're talking about a
>> {project,dir-locals}.el file that in /a, /a/b, /a/b/c, or /a/b/c/d could
>> affect the settings for /a/b/c/d/* and every file under that.  You'd
>> have to do a `find` to get all the hidden files (or some equivalent
>> shell game).  That's what I mean by "suprising" and "hidden."  Only a
>> few applications put such hidden settings files outside the home
>> directory, I can think only of the CVS .cvsignore and Subversion .svn
>> directories at the moment.  Emacs doesn't do that AFAIK, so it would be
>> at least a little surprising to current users.  I personally think it
>> would be a bad design decision.

JL> I think this problem can be completely mitigated exactly with the same
JL> solution you already proposed, i.e. C-h v and customize-variable should
JL> say that the variable's value is overridden by .project.el or .settings.el
JL> (like C-h f says that the function is advised).

That would be fine with me.  A user-visible message would also be very
useful.  I'm really just trying to avoid the debugging sessions I can
imagine ensuing from a hidden file that overrides a few local settings.
With these two safeguards (C-h v/customize-variable plus decent
messaging) I think the risk is much smaller.

Ted

Re: .emacs-settings.el

[Stefan Monnier]

> I think you've missed the difference between a hidden file anywhere in
> the directory tree and in a well-known location.  We're talking about a
> {project,dir-locals}.el file that in /a, /a/b, /a/b/c, or /a/b/c/d could
> affect the settings for /a/b/c/d/* and every file under that.  You'd
> have to do a `find` to get all the hidden files (or some equivalent
> shell game).  That's what I mean by "suprising" and "hidden."  Only a
> few applications put such hidden settings files outside the home
> directory, I can think only of the CVS .cvsignore and Subversion .svn
> directories at the moment.

There are many more: .arch-inventory, .arch-ids, .bzr, .hg.  Some use _darcs
or _MTN but other than CVS (which was often considered as a mistake) most
distinguish their name either with a leading . or a leading _.


        Stefan

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 06 Sep 2007 19:55:36 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I think you've missed the difference between a hidden file anywhere in
>> the directory tree and in a well-known location.  We're talking about a
>> {project,dir-locals}.el file that in /a, /a/b, /a/b/c, or /a/b/c/d could
>> affect the settings for /a/b/c/d/* and every file under that.  You'd
>> have to do a `find` to get all the hidden files (or some equivalent
>> shell game).  That's what I mean by "suprising" and "hidden."  Only a
>> few applications put such hidden settings files outside the home
>> directory, I can think only of the CVS .cvsignore and Subversion .svn
>> directories at the moment.

SM> There are many more: .arch-inventory, .arch-ids, .bzr, .hg.  Some use _darcs
SM> or _MTN but other than CVS (which was often considered as a mistake) most
SM> distinguish their name either with a leading . or a leading _.

Other than Eclipse, these are all VCS software packages, which is
interesting.  I've also seen hidden files used by MacOS for file
metadata and I remember .xvpics which was used for caching thumbnails.
Hidden files do tend to accumulate mostly under ~ though.

As I said in another followup, however, I'm OK with making these
override files hidden as long as messaging and C-h v/customize-variable
report their usage.  So please don't let my comments delay this very
useful functionality from making an appearance.

Ted

Re: .emacs-settings.el

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> Emacs doesn't do that AFAIK, so it would be
> at least a little surprising to current users.  I personally think it
> would be a bad design decision.

It should be a user decision.  Just as you might not like "hidden"
files, I do not like random crap cluttering my directory listings.

Thus Emacs should probably look for both ".foo.el" and "asdfasdf.el".

(we have to be much more careful with the non-hidden name though,
because it has a much higher chance of conflicting with the directory
content)

-Miles

-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

Re: .emacs-settings.el

[Stefan Monnier]

> It should be a user decision.  Just as you might not like "hidden"
> files, I do not like random crap cluttering my directory listings.

> Thus Emacs should probably look for both ".foo.el" and "asdfasdf.el".

No need for that.  Users who don't like those files to be hidden can just
add a symlink from ThisDirectoryHasEmacsLocalSettings.el to .emacs-settings.


        Stefan

Re: .emacs-settings.el

[Ted Zlatanov]

On Fri, 07 Sep 2007 11:54:18 +0900 Miles Bader <miles.bader@necel.com> wrote: 

MB> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Emacs doesn't do that AFAIK, so it would be at least a little
>> surprising to current users.  I personally think it would be a bad
>> design decision.

MB> It should be a user decision.  Just as you might not like "hidden"
MB> files, I do not like random crap cluttering my directory listings.

We agree on both of those things.  My issue was with the default that
Emacs will offer users who have not customized things.

MB> Thus Emacs should probably look for both ".foo.el" and "asdfasdf.el".

MB> (we have to be much more careful with the non-hidden name though,
MB> because it has a much higher chance of conflicting with the directory
MB> content)

That doesn't solve the issue I raised, which is that .foo.el will
*surprise* a user who didn't put it there (or forgot it) when it
overrides some setting.  As I said previously, I'm OK with just using a
dot-filename since it's the majority's opinion that it's a fine option.

Ted

Re: .emacs-settings.el

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Sep 2007 21:34:32 +0200 David Kastrup <dak@gnu.org> wrote: 
>
> DK> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> On Thu, 06 Sep 2007 18:04:30 +0200 michael@cadilhac.name (Michaël Cadilhac) wrote: 
>>> 
> MC> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>>> I would not make it hidden, to avoid surprises: project.el
>>> 
> MC> So sad the features of project.el will not be usable in the lisp/
> MC> directory of Emacs, then :-)
>>> 
>>> I think surprising the user is a bad thing, so I'd rather not have a
>>> hidden file.  The penalty of name conflicts is not as bad as using
>>> hidden data to influence an application's behavior.
>
> DK> Uh, you are arguing against _any_ file with a .* name right now: all
> DK> of them are used to influence an application's behavior without
> DK> cluttering directory listings.
>
> DK> So I don't buy this argument.
>
> I think you've missed the difference between a hidden file anywhere in
> the directory tree and in a well-known location.

In a well-known location there is no reason to hide files, since the
well-known location need not hold other files.

So no, I am not missing anything, and it is not polite of you to
presume that anybody not agreeing with you must be stupid.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: .emacs-settings.el

[Ted Zlatanov]

On Fri, 07 Sep 2007 08:19:00 +0200 David Kastrup <dak@gnu.org> wrote: 

DK> Ted Zlatanov <tzz@lifelogs.com> writes:
>> I think you've missed the difference between a hidden file anywhere in
>> the directory tree and in a well-known location.

DK> In a well-known location there is no reason to hide files, since the
DK> well-known location need not hold other files.

~/.profile is hidden and well-known for example.  The reason to hide it
(visual decluttering, exclusion from '*' in shell operations) is
separate from the reason to have it in a well-known location (standard
configuration interface through a specific filename).

DK> So no, I am not missing anything, and it is not polite of you to
DK> presume that anybody not agreeing with you must be stupid.

I meant that you had missed distinguishing between a hidden file
anywhere and in a well-known location *in your post*.  Sometimes I write
English a little bit differently from native speakers since it's my
fourth language; sorry if that sounded offensive to you.

Ted

Re: .emacs-settings.el

[Davis Herring]

> In a well-known location there is no reason to hide files, since the
> well-known location need not hold other files.

Unless that well-known location must for some reason hold files of
interest to the user.  $HOME is an example; the root of a project's
directory tree is another.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: .emacs-settings.el

[Robert J. Chassell]

    I'm ok with dir-locals.el or any other name, but in general it should
    not be an .el file, right?  It's just some settings that will not be
    actual Lisp code.  Maybe dir-locals.elp for "emacs lisp properties"?

My understanding is that an Emacs Lisp file is specified to end with
.el

herring@lanl.gov says the file in question is in Emacs Lisp, albeit
`not a file of arbitrary Lisp':

    ... it is not a file of arbitrary Lisp, but rather contains a set
    of buffer-local variables to set in the buffers visiting files it
    affects, subject to the normal risk-checking.

My understanding is that when he says `not a file of arbitrary Lisp
... a set of buffer-local variables to set in the buffers visiting
files', he means no defuns.  Only setq's are permitted.

I could easily be wrong.

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 6 Sep 2007 20:39:48 +0000 (UTC) "Robert J. Chassell" <bob@rattlesnake.com> wrote: 

RJC>     I'm ok with dir-locals.el or any other name, but in general it should
RJC>     not be an .el file, right?  It's just some settings that will not be
RJC>     actual Lisp code.  Maybe dir-locals.elp for "emacs lisp properties"?

RJC> My understanding is that an Emacs Lisp file is specified to end with
RJC> .el

Sure.

RJC> herring@lanl.gov says the file in question is in Emacs Lisp, albeit
RJC> `not a file of arbitrary Lisp':

RJC>     ... it is not a file of arbitrary Lisp, but rather contains a set
RJC>     of buffer-local variables to set in the buffers visiting files it
RJC>     affects, subject to the normal risk-checking.

RJC> My understanding is that when he says `not a file of arbitrary Lisp
RJC> ... a set of buffer-local variables to set in the buffers visiting
RJC> files', he means no defuns.  Only setq's are permitted.

I thought it would look more like the file-local specification :)  If
it's not Lisp, we can give it pretty much any extension, but .elp would
probably be least surprising and shortest.

Ted

Re: .emacs-settings.el

[Richard Stallman]

    I think surprising the user is a bad thing, so I'd rather not have a
    hidden file.  The penalty of name conflicts is not as bad as using
    hidden data to influence an application's behavior.

I prefer a dotfile.  It will ensure no conflicts with the user's files.
Dotfies are easy to see in dired.

Re: .emacs-settings.el

[Ted Zlatanov]

On Fri, 07 Sep 2007 02:31:32 -0400 Richard Stallman <rms@gnu.org> wrote: 

RS>     I think surprising the user is a bad thing, so I'd rather not have a
RS>     hidden file.  The penalty of name conflicts is not as bad as using
RS>     hidden data to influence an application's behavior.

RS> I prefer a dotfile.  It will ensure no conflicts with the user's files.
RS> Dotfies are easy to see in dired.

As I said previously, I'm OK with just using a dot-filename since it's
the majority's opinion that it's a fine option.  Let's just make sure
that there's a message when the file is used, and that 
C-h v/customize-variable note the file was used as needed.

Ted

Re: .emacs-settings.el

[Robert J. Chassell]

    FWIW, I'm for .dir-locals.el or dir-locals.el.

I don't mind what name is used so long as it is not confusing.  Juri
is right!

-- 
    Robert J. Chassell                          GnuPG Key ID: 004B4AC8
    bob@rattlesnake.com                         bob@gnu.org
    http://www.rattlesnake.com                  http://www.teak.cc

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:

Ted> Also, C-h v and customize-variable should say that project.el has
Ted> overridden a variable, so the user doesn't have to wonder.  There should
Ted> also be a user-visible message when project.el is detected and used.

Do we do these things for file-local variables?

I don't mind the latter, though I imagine I would consider it noise.

I'd rather not do the former.  But if I must, I may need help here.
Offhand I don't know how I'd implement it.

Tom

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 06 Sep 2007 14:10:41 -0600 Tom Tromey <tromey@redhat.com> wrote: 

>>>>>> "Ted" == Ted Zlatanov <tzz@lifelogs.com> writes:
Ted> Also, C-h v and customize-variable should say that project.el has
Ted> overridden a variable, so the user doesn't have to wonder.  There should
Ted> also be a user-visible message when project.el is detected and used.

Tom> Do we do these things for file-local variables?

I don't believe so.  But those variables are right in the file you're
editing, while emacs-settings.el lives outside the buffer, so it's not
as visible to the user.  That's the difference in scope that made me
think hiding the file would be a bad idea.

Tom> I don't mind the latter, though I imagine I would consider it noise.

Sure, as long as it's possible to filter it out :)

Ted

Re: .emacs-settings.el

[Stefan Monnier]

Ted> Also, C-h v and customize-variable should say that project.el has
Ted> overridden a variable, so the user doesn't have to wonder.  There should
Ted> also be a user-visible message when project.el is detected and used.

> Do we do these things for file-local variables?

No.  But it would be nice for C-h v to tell the user where the buffer-local
setting comes from (e.g. from the file-local section, with a hyperlink to
it).

> I don't mind the latter, though I imagine I would consider it noise.

Agreed.

> I'd rather not do the former.  But if I must, I may need help here.
> Offhand I don't know how I'd implement it.

I don't think it's a necessary feature, but it would be a nice addition (for
for file-local and dir-local settings).  I'm not sure how to implement it
either, but I guess we could change hack-local-variables to maintain a new
(buffer-local) variable `file-local-settings' and in C-h v we check this var
to see if the variable displayed is among the ones that were set
file-locally.


        Stefan

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

[ C-h v output ]

Stefan> I don't think it's a necessary feature, but it would be a nice
Stefan> addition (for for file-local and dir-local settings).  I'm not
Stefan> sure how to implement it either, but I guess we could change
Stefan> hack-local-variables to maintain a new (buffer-local) variable
Stefan> `file-local-settings' and in C-h v we check this var to see if
Stefan> the variable displayed is among the ones that were set
Stefan> file-locally.

I was thinking about this, and it occurred to me that we could have
"false positives".  E.g., project.el might set the variable and add it
to file-local-settings, but then some later hook might setq the
variable as well.  In this situation C-h v would incorrectly say that
the variable had a project setting -- unless every setq manipulated
file-local-settings.  The reason this is bad is that the point of
mentioning this in C-h v is to avoid confusion resulting variables
magically being set -- but in this situation you would be just as
confused trying (mistakenly) to debug your .emacs-settings.el.

Tom

Re: .emacs-settings.el

[T. V. Raman]

while we  think of project specific settings, it would also be
nice to see if we could create the ability to export a set of
related options from custom.

The new custom-themes support is nice, but it's still difficult
to do the following:

0) once you have customized a complex package, say JDEE or org,
   it's difficult to export out   settings for just that package
   into a theme that you might then take to another machine.

2) With the custom file getting large, it's increasingly creating
a single point of failure, 
  and I've also noticed that once in a while some settings get
  inexplicably lost.

As we do project specific settings, it would be really nice  to
be first able to refactor a large custom file into a set of
package-specific files,
this will make tracking down sources of multiple settings much easier.

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
    >>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca>
    >>>>>> writes:
    Tom> [ C-h v output ]
    Tom> 
    Stefan> I don't think it's a necessary feature, but it would
    Stefan> be a nice addition (for for file-local and dir-local
    Stefan> settings).  I'm not sure how to implement it either,
    Stefan> but I guess we could change hack-local-variables to
    Stefan> maintain a new (buffer-local) variable
    Stefan> `file-local-settings' and in C-h v we check this var
    Stefan> to see if the variable displayed is among the ones
    Stefan> that were set file-locally.
    Tom> 
    Tom> I was thinking about this, and it occurred to me that we
    Tom> could have "false positives".  E.g., project.el might
    Tom> set the variable and add it to file-local-settings, but
    Tom> then some later hook might setq the variable as well.
    Tom> In this situation C-h v would incorrectly say that the
    Tom> variable had a project setting -- unless every setq
    Tom> manipulated file-local-settings.  The reason this is bad
    Tom> is that the point of mentioning this in C-h v is to
    Tom> avoid confusion resulting variables magically being set
    Tom> -- but in this situation you would be just as confused
    Tom> trying (mistakenly) to debug your .emacs-settings.el.
    Tom> 
    Tom> Tom
    Tom> 
    Tom> 
    Tom> _______________________________________________
    Tom> Emacs-devel mailing list Emacs-devel@gnu.org
    Tom> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "tvr" == T V Raman <raman@users.sourceforge.net> writes:

tvr> while we  think of project specific settings, it would also be
tvr> nice to see if we could create the ability to export a set of
tvr> related options from custom.

Yeah, that's on the project.el wish-list.

Also, it would be nice if some "project-centric" things like
compile-history, gdb command lines, and the tags buffer were made
per-project; and if desktop.el understood that and saved them as such.

For me TAGS in particular comes up quite a bit, as I often edit
different branches of GCC at the same time, and if I forget to switch
TAGS files I will occasionally editing the wrong copy of a file.

I haven't gotten around to experimenting with this stuff yet.  My
Emacs wish-list is pretty long and time is limited.  Adding useful IDE
features to Emacs is one of the bigger things on the list... I love
Emacs but recent experience with Eclipse has shown me some ways that
Emacs has fallen behind.

Tom

Re: .emacs-settings.el

[Juri Linkov]

> Also, it would be nice if some "project-centric" things like
> compile-history, gdb command lines, and the tags buffer were made
> per-project; and if desktop.el understood that and saved them as such.

Isn't this possible by setting `compile-history', `tags-file-name'
in the common file like .dirvars.el in the project's root directory?

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:

>> Also, it would be nice if some "project-centric" things like
>> compile-history, gdb command lines, and the tags buffer were made
>> per-project; and if desktop.el understood that and saved them as such.

Juri> Isn't this possible by setting `compile-history', `tags-file-name'
Juri> in the common file like .dirvars.el in the project's root directory?

My idea for how this feature would be used is that a project
maintainer would check in the settings file.  Then if you check out
the project and edit it, you will automatically get the correct
settings.

In this mode, it is important not to check in settings which are
things that the user might want to modify.  So, for instance, it would
be appropriate to set indentation in this file (that is a property of
the project) but not, say, c-mode's electric key settings (since that
is a preference of the user's).

Anyway ... for compile or gud, IME the settings change from time to
time and the nicest thing is to save them automatically.  I
experimented for a while with editing these in my .emacs, but that is
too heavy-weight.

Tom

Re: .emacs-settings.el

[T. V. Raman]

the closest I've come across in  the emacs world is JDEE
management of  project specific settings, and I agree that emacs
could go a lot furher. 



I finally convinced myself to cut over to custom starting about 6
years ago,
and in the interim my .emacs has become more manageable --  I let
custom save its settings in a different .customie fle.
However the .custom file is now a dumping ground that brings back
nightmarish memories of the Windows registry 

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
    >>>>>> "tvr" == T V Raman <raman@users.sourceforge.net>
    >>>>>> writes:
    tvr> while we think of project specific settings, it would
    tvr> also be nice to see if we could create the ability to
    tvr> export a set of related options from custom.
    Tom> 
    Tom> Yeah, that's on the project.el wish-list.
    Tom> 
    Tom> Also, it would be nice if some "project-centric" things
    Tom> like compile-history, gdb command lines, and the tags
    Tom> buffer were made per-project; and if desktop.el
    Tom> understood that and saved them as such.
    Tom> 
    Tom> For me TAGS in particular comes up quite a bit, as I
    Tom> often edit different branches of GCC at the same time,
    Tom> and if I forget to switch TAGS files I will occasionally
    Tom> editing the wrong copy of a file.
    Tom> 
    Tom> I haven't gotten around to experimenting with this stuff
    Tom> yet.  My Emacs wish-list is pretty long and time is
    Tom> limited.  Adding useful IDE features to Emacs is one of
    Tom> the bigger things on the list... I love Emacs but recent
    Tom> experience with Eclipse has shown me some ways that
    Tom> Emacs has fallen behind.
    Tom> 
    Tom> Tom
    Tom> 
    Tom> 
    Tom> _______________________________________________
    Tom> Emacs-devel mailing list Emacs-devel@gnu.org
    Tom> http://lists.gnu.org/mailman/listinfo/emacs-devel

-- 
Best Regards,
--raman

      
Email:  raman@users.sf.net
WWW:    http://emacspeak.sf.net/raman/
AIM:    emacspeak       GTalk: tv.raman.tv@gmail.com
PGP:    http://emacspeak.sf.net/raman/raman-almaden.asc
Google: tv+raman 
IRC:    irc://irc.freenode.net/#emacs

Re: .emacs-settings.el

[David Kastrup]

Tom Tromey <tromey@redhat.com> writes:

>>>>>> "tvr" == T V Raman <raman@users.sourceforge.net> writes:
>
> tvr> while we  think of project specific settings, it would also be
> tvr> nice to see if we could create the ability to export a set of
> tvr> related options from custom.
>
> Yeah, that's on the project.el wish-list.
>
> Also, it would be nice if some "project-centric" things like
> compile-history, gdb command lines, and the tags buffer were made
> per-project; and if desktop.el understood that and saved them as
> such.

One thing that certainly is project specific is the setting of
c-indentation-style.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: .emacs-settings.el

[Davis Herring]

> Also, it would be nice if some "project-centric" things like
> compile-history, gdb command lines, and the tags buffer were made
> per-project; and if desktop.el understood that and saved them as such.

desktop.el isn't supposed to save semipermanent user settings, but rather
the otherwise-ephemeral global and buffer-specific state of an editing
session.  Perhaps what you want is some sort of Custom theme-like
arrangement where the values of variables are saved back to the files from
which they were read?

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: .emacs-settings.el

[Stefan Monnier]

Stefan> I don't think it's a necessary feature, but it would be a nice
Stefan> addition (for for file-local and dir-local settings).  I'm not
Stefan> sure how to implement it either, but I guess we could change
Stefan> hack-local-variables to maintain a new (buffer-local) variable
Stefan> `file-local-settings' and in C-h v we check this var to see if
Stefan> the variable displayed is among the ones that were set
Stefan> file-locally.

> I was thinking about this, and it occurred to me that we could have
> "false positives".  E.g., project.el might set the variable and add it

Of course.  The obvious solution is to record to value set, so if the value
is still the same, you can reasonably presume that there's still
a relationship between the setting and the variable's current value.

Of course, maybe there isn't, but most likely if the setting is a problem,
the user will see "this setting comes from ...", it will go there, remove
the file-local or project-local setting and try again and will then see that
the same problem is still present but without the "this setting comes from
..." at which it'll know that there's something more to it.


        Stefan

Re: .emacs-settings.el

[Ted Zlatanov]

On Sun, 09 Sep 2007 16:06:14 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

Stefan> I don't think it's a necessary feature, but it would be a nice
Stefan> addition (for for file-local and dir-local settings).  I'm not
Stefan> sure how to implement it either, but I guess we could change
Stefan> hack-local-variables to maintain a new (buffer-local) variable
Stefan> `file-local-settings' and in C-h v we check this var to see if
Stefan> the variable displayed is among the ones that were set
Stefan> file-locally.

>> I was thinking about this, and it occurred to me that we could have
>> "false positives".  E.g., project.el might set the variable and add it

SM> Of course.  The obvious solution is to record to value set, so if the value
SM> is still the same, you can reasonably presume that there's still
SM> a relationship between the setting and the variable's current value.

SM> Of course, maybe there isn't, but most likely if the setting is a problem,
SM> the user will see "this setting comes from ...", it will go there, remove
SM> the file-local or project-local setting and try again and will then see that
SM> the same problem is still present but without the "this setting comes from
SM> ..." at which it'll know that there's something more to it.

What about recording a stack of modifications, e.g.

this variable was created in x.el line 300
it was modified by Customize in y.el line 400
it was overridden by a buffer-local version in z.el line 500
(file and line are not always available)

I don't know how hard it is to implement this, but it would be great for
general debugging too.  If the new value of the variable could be
recorded as well (optionally), this would be even more useful.

Ted

Re: .emacs-settings.el

[Richard Stallman]

    What about recording a stack of modifications, e.g.

    this variable was created in x.el line 300
    it was modified by Customize in y.el line 400
    it was overridden by a buffer-local version in z.el line 500
    (file and line are not always available)

I think that would be hard to implement
because the necessary data is not known.

Re: .emacs-settings.el

[Richard Stallman]

    Ted> Also, C-h v and customize-variable should say that project.el has
    Ted> overridden a variable, so the user doesn't have to wonder.  There should
    Ted> also be a user-visible message when project.el is detected and used.

    Do we do these things for file-local variables?

C-h v does say if the variable is buffer-local.

If you think it would be useful to give more details,
please implement that.

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "Juri" == Juri Linkov <juri@jurta.org> writes:

Juri> Since .emacs-settings.el is a confusing file name, what about a more
Juri> appropriate and shorter file name like .dir-vars.el or .dir-locals.el
Juri> or .project.el.

Could you say what you think is confusing about it?
Obviously I don't find it confusing.  

Ted> That's what I mean by "suprising" and "hidden."  Only a few
Ted> applications put such hidden settings files outside the home
Ted> directory, I can think only of the CVS .cvsignore and Subversion
Ted> .svn directories at the moment.

Yeah, it is intentionally supposed to be similar to .cvsignore or
.svn.  The hidden-ness, in my view, is a feature; some projects don't
like to "clutter" their top-level directories with things like this.
FWIW my precedent here is Eclipse, which makes .project and .settings
directories.

Tom

Re: .emacs-settings.el

[Juri Linkov]

> Juri> Since .emacs-settings.el is a confusing file name, what about a more
> Juri> appropriate and shorter file name like .dir-vars.el or .dir-locals.el
> Juri> or .project.el.
>
> Could you say what you think is confusing about it?

Exactly what you can see in the message that started this thread,
i.e. when users first encounter the file .emacs-settings.el, the first
reaction is that it somehow related to general Emacs settings in .emacs.

> FWIW my precedent here is Eclipse, which makes .project and .settings
> directories.

Then why don't use similar names in Emacs?  If the package name will
remain project.el, then name the data file .project.el (the extension .el
says that this data file is for Emacs, and the leading dot says that
it's a configuration file).  If the package will be renamed to settings.el,
then name the data file .settings.el.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .emacs-settings.el

[Stefan Monnier]

>> FWIW my precedent here is Eclipse, which makes .project and .settings
>> directories.

This kind of "all the world is Eclipse users and screw the rest"
attitude sucks.  I see no need to adopt it.


        Stefan

Re: .emacs-settings.el

[Richard Stallman]

    Then why don't use similar names in Emacs?  If the package name will
    remain project.el, then name the data file .project.el (the extension .el
    says that this data file is for Emacs, and the leading dot says that
    it's a configuration file).  If the package will be renamed to settings.el,
    then name the data file .settings.el.

If you're talking about the file name in which the code for this feature
will be installed, that will be `files.el'.

But that's irrelevant to the question at hand.  We don't choose user
interface details based on internal implementation details.

I want to use a dotfile, to keep the directory uncluttered
and to avoid constraining names of source files.  (That is the
usual purpose of dotfiles.)  If the file name ends in `.el',
then there is no need to say `emacs' in it too.  So I think
`.dirvars.el' is a good name.

I do not want to use a non-dotfile name
because that could conflict with the user's own files.

If you want to make that file more visible, make a symlink to it
with a non-hidden name.

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "rms" == Richard Stallman <rms@gnu.org> writes:

rms> I want to use a dotfile, to keep the directory uncluttered
rms> and to avoid constraining names of source files.  (That is the
rms> usual purpose of dotfiles.)  If the file name ends in `.el',
rms> then there is no need to say `emacs' in it too.  So I think
rms> `.dirvars.el' is a good name.

FWIW -- I purposely did not choose the name "dirvars", to avoid
confusion with the existing dirvars.el and dir-locals.el packages.

However, if you feel strongly about this, I will change the name in
the next revision of the patch.

Since you're deciding stuff, would you mind weighing in on the other
proposals in this thread?  From memory this includes messaging the
user when the settings are used, modifying the C-h v output to mention
project settings, and letting the user interactively agree to risky
settings.

I'd rather not do any of these -- KISS is more my style.  Also I am a
bit lazy :-)

Tom

Re: .emacs-settings.el

[Ted Zlatanov]

On Thu, 06 Sep 2007 14:08:00 -0600 Tom Tromey <tromey@redhat.com> wrote: 

Ted> That's what I mean by "suprising" and "hidden."  Only a few
Ted> applications put such hidden settings files outside the home
Ted> directory, I can think only of the CVS .cvsignore and Subversion
Ted> .svn directories at the moment.

Tom> Yeah, it is intentionally supposed to be similar to .cvsignore or
Tom> .svn.  The hidden-ness, in my view, is a feature; some projects don't
Tom> like to "clutter" their top-level directories with things like this.
Tom> FWIW my precedent here is Eclipse, which makes .project and .settings
Tom> directories.

I think Emacs should not default to getting default settings from a
hidden file in the path, personally, but it should be possible via
customization to choose that behavior.  I wouldn't expect Emacs to do
that by default, that's all.

Ted

Re: .emacs-settings.el

[Miles Bader]

Ted Zlatanov <tzz@lifelogs.com> writes:
> I think Emacs should not default to getting default settings from a
> hidden file in the path, personally, but it should be possible via
> customization to choose that behavior.

No, it should do so by default, because if we add such a feature, many
projects will start to use such "hidden settings files", and expect that
Emacs users of that project will see the resulting effects.  Of course
it should be possible to disable it if you don't like that.

-Miles

-- 
My spirit felt washed.  With blood.  [Eli Shin, on "The Passion of the Christ"]

Re: .emacs-settings.el

[David Kastrup]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Sep 2007 14:08:00 -0600 Tom Tromey <tromey@redhat.com> wrote: 
>
> Ted> That's what I mean by "suprising" and "hidden."  Only a few
> Ted> applications put such hidden settings files outside the home
> Ted> directory, I can think only of the CVS .cvsignore and Subversion
> Ted> .svn directories at the moment.
>
> Tom> Yeah, it is intentionally supposed to be similar to .cvsignore or
> Tom> .svn.  The hidden-ness, in my view, is a feature; some projects don't
> Tom> like to "clutter" their top-level directories with things like this.
> Tom> FWIW my precedent here is Eclipse, which makes .project and .settings
> Tom> directories.
>
> I think Emacs should not default to getting default settings from a
> hidden file in the path, personally, but it should be possible via
> customization to choose that behavior.  I wouldn't expect Emacs to
> do that by default, that's all.

I strongly disagree.  The file won't be there without the user having
taken some action to put it there, and if there is changed behavior,
the first place I would look for would be in a local hidden file.
That's what I do with other utilities as well that have local
dicrectory-relevant behavior.  If it is not there, then it becomes a
RPIT searching for the location where the stuff actually sits.  Files
starting with . are supposed to be auxiliary data, not content, and
this is _exactly_ what the scheme .* has been designed for.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: .emacs-settings.el

[Jason Rumney]

David Kastrup wrote:
> I strongly disagree.  The file won't be there without the user having
> taken some action to put it there

s/the user/a user/

On multi-user systems this could be a security risk, so it should be
disabled by default.

Re: .emacs-settings.el

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> I strongly disagree.  The file won't be there without the user having
>> taken some action to put it there
>
> s/the user/a user/
>
> On multi-user systems this could be a security risk, so it should be
> disabled by default.

If we think it a security risk, we can ignore such files unless
written by the current user.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: .emacs-settings.el

[Ted Zlatanov]

On Fri, 07 Sep 2007 09:18:29 +0200 David Kastrup <dak@gnu.org> wrote: 

DK> Jason Rumney <jasonr@gnu.org> writes:
>> David Kastrup wrote:
>>> I strongly disagree.  The file won't be there without the user having
>>> taken some action to put it there
>> 
>> s/the user/a user/
>> 
>> On multi-user systems this could be a security risk, so it should be
>> disabled by default.

DK> If we think it a security risk, we can ignore such files unless
DK> written by the current user.

That would make the feature much less useful.  Better to interpret the
file safely and notify the user both when it happens and after the fact
as I commented previously.  It would be extremely useful to have a
shared directory on a multi-user system with standardized code
indentation settings, for instance, through this mechanism.

Ted

Re: .emacs-settings.el

[Davis Herring]

>> I strongly disagree.  The file won't be there without the user having
>> taken some action to put it there
>
> s/the user/a user/
>
> On multi-user systems this could be a security risk, so it should be
> disabled by default.

That's why the file only can contain variable settings, and why they are
run through the usual risky/unsafe variable check.  Which is good: telling
the user "here's a nice feature, but it's unsafe to use it" means that the
feature isn't so nice.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

Re: .emacs-settings.el

[Richard Stallman]

    On multi-user systems this could be a security risk, so it should be
    disabled by default.

Better to limit it to setting safe variables.

    If we think it a security risk, we can ignore such files unless
    written by the current user.

That would make it far less useful.  If we limit this to setting safe
variables, there is no risk, so there's no reason to care who wrote
the file.

Re: .emacs-settings.el

[Stefan Monnier]

>>> I cannot remember what you said earlier.  How is ~/.emacs-settings.el
>>> different from the long-used settings file ~/.emacs?  How is it
>>> different from site-start.el or default.el, if those files exist?
>> 
>> .emacs-settings.el can go in other directories than ~; it affects files
>> found anywhere in the directory tree that contains it.  Moreover, it is
>> not a file of arbitrary Lisp, but rather contains a set of buffer-local
>> variables to set in the buffers visiting files it affects, subject to the
>> normal risk-checking.

> Since .emacs-settings.el is a confusing file name, what about a more
> appropriate and shorter file name like .dir-vars.el or .dir-locals.el
> or .project.el.

Please go re-read the thread that ended up with "emacs-settings".


        Stefan

Re: .emacs-settings.el

[Juri Linkov]

>> Since .emacs-settings.el is a confusing file name, what about a more
>> appropriate and shorter file name like .dir-vars.el or .dir-locals.el
>> or .project.el.
>
> Please go re-read the thread that ended up with "emacs-settings".

I can find the following conversation:

Stefan> How 'bout "dir-local-settings" instead?
Stefan> I'm also tempted to add "emacs" in the name, but I guess that
Stefan> the ".el" extension can be considered sufficient information
Stefan> (and after all, we don't use the "Emacs" name in the "Local
Stefan> Variables" section cookies either).
Tom> Mentioning Emacs wouldn't be too bad.  "dir-local-settings" is too
Tom> long for my taste.
Tom> How about ".emacs-settings"?
Vagn> Good choice. It also follows "tradition" because dirvars.el uses
Vagn> .emacs-dirvars and dir-locals.el uses .emacs-locals.

I agree that it's a good tradition to use the same file names for
a package and its data files (dirvars.el -> .emacs-dirvars,
dir-locals.el -> .emacs-locals), but I don't see how this tradition
applies to package.el: package.el -> .emacs-settings.el?
This is confusing.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .emacs-settings.el

[Stefan Monnier]

> I agree that it's a good tradition to use the same file names for
> a package and its data files (dirvars.el -> .emacs-dirvars,
> dir-locals.el -> .emacs-locals), but I don't see how this tradition
> applies to package.el: package.el -> .emacs-settings.el?
> This is confusing.

In my opinion, package.el is itself a poor name, since it hints at other
features such as CL packages or XEmacs packages.


        Stefan

Re: .emacs-settings.el

[Tom Tromey]

>>>>> "Stefan" == Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> I agree that it's a good tradition to use the same file names for
>> a package and its data files (dirvars.el -> .emacs-dirvars,
>> dir-locals.el -> .emacs-locals), but I don't see how this tradition
>> applies to package.el: package.el -> .emacs-settings.el?
>> This is confusing.

Stefan> In my opinion, package.el is itself a poor name, since it
Stefan> hints at other features such as CL packages or XEmacs
Stefan> packages.

FWIW -- it is "project.el"; "package.el" is that other thing I wrote
that we all argue about :-)

RMS already asked that I just put the code into files.el.  So all that
will be left are the symbol names starting with "project-".

Perhaps even "project" is a misnomer.  It is hard to say.  I do think
the best use for this feature is project-specific settings.

Tom

Re: .emacs-settings.el

[Juri Linkov]

>>> I agree that it's a good tradition to use the same file names for
>>> a package and its data files (dirvars.el -> .emacs-dirvars,
>>> dir-locals.el -> .emacs-locals), but I don't see how this tradition
>>> applies to package.el: package.el -> .emacs-settings.el?
>>> This is confusing.
>
> Stefan> In my opinion, package.el is itself a poor name, since it
> Stefan> hints at other features such as CL packages or XEmacs
> Stefan> packages.
>
> FWIW -- it is "project.el"; "package.el" is that other thing I wrote
> that we all argue about :-)

Oops, perhaps I mistyped the package name because you are the author of
both packages.

> RMS already asked that I just put the code into files.el.  So all that
> will be left are the symbol names starting with "project-".

Hmm, in this case the package name is irrelevant for naming data files.

> Perhaps even "project" is a misnomer.  It is hard to say.  I do think
> the best use for this feature is project-specific settings.

I agree, "project" is a misnomer.  It can be used for project-specific
settings, but not necessarily limited to this.

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: .emacs-settings.el

[Johannes Weiner]

[-- Attachment #1.1: Type: text/plain, Size: 1966 bytes --]

Hi,

On Wed, Sep 05, 2007 at 07:27:21AM -0700, Davis Herring wrote:
> .emacs-settings.el can go in other directories than ~; it affects files
> found anywhere in the directory tree that contains it.  Moreover, it is
> not a file of arbitrary Lisp, but rather contains a set of buffer-local
> variables to set in the buffers visiting files it affects, subject to the
> normal risk-checking.

I would really dislike such files. Imagine every editor has a project-specific
configuration file in the project root and you have 10 hackers working on this
project with 10 different editors.

And I would dislike to have a limited set of configuration options within such
a file.

Configuration is .emacs' concern, so how about the following:

(defmacro add-project-locals (directory-action-alist)
  `(add-hook 'find-file-hook
             (lambda ()
               ,@(mapcar (lambda (dapair)
                           `(when (string-match (concat "^" ,(car dapair))
                                                (buffer-file-name))
                              ,(cdr dapair)))
                         directory-action-alist))))

Then you have

	(add-project-locals
	  (("lisp/" . (message "This is a lisp project"))
	   ("src/emacs-cvs/" . (progn
	                         ;; do some emacs code specific stuff here))))

expand to

	(add-hook 'find-file-hook
	          (lambda ()
	            (when (string-match (concat "^" "lisp/"))
	                                (buffer-file-name)
	              (message "This is a lisp project"))
	            (when (string-match (concat "^" "src/emacs-cvs/")
	                                (buffer-file-name))
	              (progn
	                ;; do some emacs code specific stuff here))))

Of course, this is just a kludgy hack, but I think the approach itself is not
as bad as having emacs-specific setup-files spread all over several
project-directories.
	
	Hannes

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: .emacs-settings.el

[Davis Herring]

> I would really dislike such files. Imagine every editor has a
> project-specific
> configuration file in the project root and you have 10 hackers working on
> this
> project with 10 different editors.

Surely a project with 10 hackers has much more than 10 files, so that
adding one project-settings file per editor does not dwarf the real work
of the project?  I don't imagine that the settings files would need to be
synchronized or anything, since the different editors will have very
different support for the preferences of the project.

> And I would dislike to have a limited set of configuration options within
> such
> a file.

Having a (safe) local variable `project-settings-library' which would be
loaded (with confirmation) by M-x load-project-settings ("load" in its
name to emphasize that it's executing real, unconstrained Lisp) would be
an easy way to allow other configuration in a per-project way with
reasonable security; just put a setting for that variable in the
variables-only project file we're discussing now.  The only trick would be
that the filename would need to be absolute if it were specified for any
non-trivial directory tree, since one cannot run `expand-file-name' in a
local variable setting.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: .emacs-settings.el

[Drew Adams]

I haven't followed this thread closely. Could someone please summarize the
need for which the solutions are being discussed?

If this is about users defining their preferred settings for something, and
you want such settings to be persistent, then why not use Customize instead
of adding separate preference files?

IIUC, the separate preference files proposed would control stuff in the
directories (or perhaps in the child or parent directories?) where they are
found. If so, wouldn't it be appropriate to do all of that using a single
user option that specified the directories and the preferences for the files
in those directories?

Or is the problem that these preference files are supposed to affect
multiple users, so that they cannot be in a single user's preference file?

Sorry for not following this, but I suspect others too might have lost the
thread of this thread. A brief summary of the need could help us understand
better.

If this is about a need to share preferences among multiple users, then
perhaps we could have an "import" or "include" feature for Customize that
allows sharing of some preferences. Importing would reference the imported
custom files, rather than making explicit copies of their data, so that
changes to the imported file would be reflected in the importing files.
(Perhaps this possibility of sharing preferences has been discussed before?)

Re: .emacs-settings.el

[joakim]

"Drew Adams" <drew.adams@oracle.com> writes:


> I haven't followed this thread closely. Could someone please summarize the
> need for which the solutions are being discussed?
>
> If this is about users defining their preferred settings for something, and
> you want such settings to be persistent, then why not use Customize instead
> of adding separate preference files?

This is, kind of, how the JDEE (java development environment for
emacs) works. There is a project.el file which is managed by custom in
some way. I dont quite remember the details, but I think the Eieio
emacs CLOS implementation is involved also somehow.

> IIUC, the separate preference files proposed would control stuff in the
> directories (or perhaps in the child or parent directories?) where they are
> found. If so, wouldn't it be appropriate to do all of that using a single
> user option that specified the directories and the preferences for the files
> in those directories?
>
> Or is the problem that these preference files are supposed to affect
> multiple users, so that they cannot be in a single user's preference file?
>
> Sorry for not following this, but I suspect others too might have lost the
> thread of this thread. A brief summary of the need could help us understand
> better.
>
> If this is about a need to share preferences among multiple users, then
> perhaps we could have an "import" or "include" feature for Customize that
> allows sharing of some preferences. Importing would reference the imported
> custom files, rather than making explicit copies of their data, so that
> changes to the imported file would be reflected in the importing files.
> (Perhaps this possibility of sharing preferences has been discussed before?)

-- 
Joakim Verona

Re: .emacs-settings.el

[Richard Stallman]

    I haven't followed this thread closely. Could someone please summarize the
    need for which the solutions are being discussed?

Could you please take this off the list?  I've announced the decision
about what we will do for this, so further discussion is just a
distraction.

Re: .emacs-settings.el

[Richard Stallman]

I've already announced the decision about this question,
so continuing to discuss it here is not useful.