[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 ]
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 address@hidden
Tom> http://lists.gnu.org/mailman/listinfo/emacs-devel
--
Best Regards,
--raman
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
- Re: .emacs-settings.el, (continued)
- Re: .emacs-settings.el, Richard Stallman, 2007/09/07
- Re: .emacs-settings.el, Ted Zlatanov, 2007/09/07
- Re: .emacs-settings.el, Robert J. Chassell, 2007/09/06
- Re: .emacs-settings.el, Tom Tromey, 2007/09/06
- Re: .emacs-settings.el, Ted Zlatanov, 2007/09/06
- Re: .emacs-settings.el, Stefan Monnier, 2007/09/07
- Re: .emacs-settings.el, Tom Tromey, 2007/09/08
- Re: .emacs-settings.el,
T. V. Raman <=
- Re: .emacs-settings.el, Tom Tromey, 2007/09/08
- Re: .emacs-settings.el, Juri Linkov, 2007/09/08
- Re: .emacs-settings.el, Tom Tromey, 2007/09/08
- Re: .emacs-settings.el, T. V. Raman, 2007/09/08
- Re: .emacs-settings.el, David Kastrup, 2007/09/09
- Re: .emacs-settings.el, Davis Herring, 2007/09/10
- Re: .emacs-settings.el, Richard Stallman, 2007/09/08
- Re: .emacs-settings.el, Stefan Monnier, 2007/09/09
- Re: .emacs-settings.el, Ted Zlatanov, 2007/09/11
- Re: .emacs-settings.el, Richard Stallman, 2007/09/12