[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: .emacs-settings.el

From: T. V. Raman
Subject: Re: .emacs-settings.el
Date: Sat, 8 Sep 2007 12:19:50 -0700

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 <address@hidden> writes:
    >>>>>> "Stefan" == Stefan Monnier <address@hidden>
    >>>>>> writes:
    Tom> [ C-h v output ]
    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> 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> Emacs-devel mailing list address@hidden
    Tom> http://lists.gnu.org/mailman/listinfo/emacs-devel

Best Regards,

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]