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

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

[Adrian Robert]

> Setting `ns-expand-space' doesn't work, and neither does changing its
> value via the slider the the preferences panel.
>
> Also, the doc string of the above variable says that one shouldn't set
> it directly - if so, how is one supposed to (programmatically) set  
> this?
> Studying the source code (nsterm.m:setValuesFromPanel), it seems to me
> that setting the value should work just fine (I even tried calling ns-
> save-preferences).

Emacs must be restarted, unfortunately.  It mentions this in the  
manual.  The variable doc string should be updated.

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 4588 bytes --]

On 4 Mar 2009, at 16:35, Adrian Robert wrote:

>> Setting `ns-expand-space' doesn't work, and neither does changing its
>> value via the slider the the preferences panel.
>>
>> Also, the doc string of the above variable says that one shouldn't  
>> set
>> it directly - if so, how is one supposed to (programmatically) set  
>> this?
>> Studying the source code (nsterm.m:setValuesFromPanel), it seems to  
>> me
>> that setting the value should work just fine (I even tried calling  
>> ns-
>> save-preferences).
>
> Emacs must be restarted, unfortunately.  It mentions this in the  
> manual.  The variable doc string should be updated.
>

The UI does not reflect that.  Users need some indication that they  
need to restart Emacs for this to work.

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.  And, second, it is going to be harder on us to  
troubleshoot people's problems.  Right now, with GNU Emacs 22, we have  
~/.emacs and ~/.emacs.d (IIRC), and maybe a few site-lisp files.  I  
speak from experience - in Aquamacs, youthful optimism led me to add  
eight further locations for a version of .emacs called Preferences.el  
- two would have done the job to satisfy my goal of Mac  
compatibility.  In addition to that, we split custom-file from .emacs  
(a good choice, per se).  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.

In anticipation of one pro-resource argument: X Resources are much  
more limited than the NS parameters system.  Why recreate it on NS?

What follows is an excerpt from ns-win.el that shows how many of these  
"NS resources" are set.



   (ns-set-resource nil "AlternateModifier" (symbol-name ns-alternate- 
modifier))
   (ns-set-resource nil "CommandModifier" (symbol-name ns-command- 
modifier))
   (ns-set-resource nil "ControlModifier" (symbol-name ns-control- 
modifier))
   (ns-set-resource nil "FunctionModifier" (symbol-name ns-function- 
modifier))
   (ns-set-resource nil "ExpandSpace"
                    (if ns-expand-space
                        (number-to-string ns-expand-space)
                      "NO"))
   (ns-set-resource nil "GSFontAntiAlias" (if ns-antialias-text "YES"  
"NO"))
   (ns-set-resource nil "UseQuickdrawSmoothing"
		   (if ns-use-qd-smoothing "YES" "NO"))
   (ns-set-resource nil "UseSystemHighlightColor"
		   (if ns-use-system-highlight-color "YES" "NO"))
   (ns-set-resource nil "ConfirmQuit"
		   (if ns-confirm-quit "YES" "NO"))
   ;; Default frame parameters
   (let ((p (frame-parameters))
	v)
     (if (setq v (assq 'font p))
	(ns-set-resource nil "Font" (ns-font-name (cdr v))))
     (if (setq v (assq 'fontsize p))

...

  (let ((fl (face-list)))
     (while (consp fl)
       (or (eq 'default (car fl))
           ;; dont save Default* since it causes all created faces to
           ;; inherit its values.  The properties of the default face
           ;; have already been saved from the frame-parameters anyway.
           (let* ((name (symbol-name (car fl)))
                  (font (face-font (car fl)))
                  ;; (fontsize (face-fontsize (car fl)))
                  (foreground (face-foreground (car fl)))
                  (background (face-background (car fl)))
                  (underline (face-underline-p (car fl)))
                  (italic (face-italic-p (car fl)))
                  (bold (face-bold-p (car fl)))
                  (stipple (face-stipple (car fl))))
             ;; (ns-set-resource nil (concat name ".attributeFont")
             ;;                  (if font font nil))
             ;; (ns-set-resource nil (concat name ".attributeFontSize")
             ;;                  (if fontsize (number-to-string  
fontsize) nil))
             (ns-set-resource nil (concat name ".attributeForeground")
                              (if foreground foreground nil))
             (ns-set-resource nil (concat name ".attributeBackground")
                              (if background background nil))
             (ns-set-resource nil (concat name ".attributeUnderline")


...





[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

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

[Adrian Robert]

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.

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 1630 bytes --]

On 6 Mar 2009, at 14:20, Adrian Robert wrote:

> 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.

Yes, I agree.  It's great that there is now a way to access the NS  
defaults system.

I would advocate, however, to only use the NS prefs systems for  
variables that cannot be implemented with the customization system,  
i.e. stuff that needs to be initialized on startup, because user files  
are read.

> 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.

Up to the maintainers to decide:
Is "user-visibility" the right criterion?  (Bug fixes are user-visible!)
Shouldn't it be "dangerous" vs. not, and "bug fixes" vs. "features",  
and "recent regressions" vs. not?


--
http://aquamacs.org -- Aquamacs: Emacs on Mac OS X
http://aquamacs.org/donate -- Could we help you? Return the favor and  
support the Aquamacs Project!


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]

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

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 6 Mar 2009 21:20:13 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

> 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.

Emacs already has the line-spacing setting as frame parameter,
buffer-local variable, and text property.  So, ns-expand-space
can/should be removed.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

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

[David Reitter]

[-- Attachment #1: Type: text/plain, Size: 484 bytes --]

Setting `ns-expand-space' doesn't work, and neither does changing its  
value via the slider the the preferences panel.

Also, the doc string of the above variable says that one shouldn't set  
it directly - if so, how is one supposed to (programmatically) set this?
Studying the source code (nsterm.m:setValuesFromPanel), it seems to me  
that setting the value should work just fine (I even tried calling ns- 
save-preferences).

This is with a vanilla 23/NS build from today's CVS.

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2193 bytes --]