GNU bug report logs - #2532
NS: ns-expand-space / slider in Preferences dialog not functional

Previous Next

Full log

View this message in rfc822 format

From: Adrian Robert <adrian.b.robert <at> gmail.com>
To: David Reitter <david.reitter <at> gmail.com>
Cc: 2532 <at> debbugs.gnu.org, Emacs-Devel devel <emacs-devel <at> gnu.org>
Subject: bug#2532: NS: ns-expand-space / slider in Preferences dialog not functional
Date: Fri, 6 Mar 2009 21:20:13 +0200

On Mar 5, 2009, at 5:39 AM, David Reitter wrote:

> The `ns-set-resource' Elisp interface is better than none on the  
> Elisp side, but what happened to Emacs customization variables?
>
> As said before on this list, introducing another way (beyond .emacs  
> and customization/custom-file) creates a new failure point for  
> people's configurations.  This is bad in two respects: they won't  
> be able to reset Emacs to a vanilla state, or troubleshoot a faulty  
> configuration.
> ...
> All of these things make it harder to support users.  "emacs -q" is  
> helpful, but at the end of the day, people want to run "emacs".   
> Especially seasoned users will complain that they have to find and  
> delete ~/Library/Preferences/org.gnu.emacs.plist.

This is no longer true -- running -q or -Q now ignores the plist --  
though not X resources, I believe.  The one difference between the NS  
defaults and X resources is that the defaults system is read/write,  
whereas X resources are for some strange reason read-only by design.   
After various discussion here, I now believe this difference is  
fundamental, and that the NS defaults system should therefore be used  
in Emacs only internally for parameters that are specific to NS and  
not set by users.  This includes reading existing system settings  
like anti-aliasing threshold, as well as storing previous directories  
and window locations for file open/save dialogs.  Completely behind- 
the-scenes stuff.

I would advocate transitioning all of the ns-xxx lisp variables that  
are not stored in defaults to the customization system.

I am not sure if it is appropriate to do this under pretest,  
however.  It would be a user-visible change and potentially cause  
unexpected side effects.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.