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.

Re: 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 --]

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

Re: 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

[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 --]

Re: 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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Adrian Robert]

On Mar 7, 2009, at 3:09 AM, YAMAMOTO Mitsuharu wrote:

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

The semantics are different.  line-spacing can only be used to  
increase line spacing (i.e. add padding between lines).  ns-expand- 
space can be used to expand or shrink.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 7 Mar 2009 04:15:05 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

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

> The semantics are different.  line-spacing can only be used to
> increase line spacing (i.e. add padding between lines).  ns-expand-
> space can be used to expand or shrink.

If shrinking is useful, that should be added in a platform-independent
manner rather than introducing platform-specific variable.

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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Adrian Robert]

On Mar 7, 2009, at 5:33 AM, YAMAMOTO Mitsuharu wrote:
>
> If shrinking is useful, that should be added in a platform-independent
> manner rather than introducing platform-specific variable.

I find it nice for viewing more lines of code in a window in some  
fonts that seem to space fairly generously.  If others like it,  
perhaps it could be considered for a future version of emacs, using  
the existing line-spacing impl as a starting point.


On Mar 7, 2009, at 6:27 AM, David Reitter wrote:

> Is there a reason why the default (and ns-expand-space set to 1.0)  
> results in wider line spacing than with Emacs 22?

I'm not sure about Emacs 22 but the original goal was to display  
fonts spaced identically to other apps (e.g. TextEdit) on OS X and  
GNUstep.  This was the case for a while, but testing now, it seems to  
be slightly taller.  I'm not sure when the regression happened, or of  
its cause, but I suspect it may have gotten out of sync late last  
summer when the final major round of changes for integrating the new  
font backend framework occurred.  The relevant (faulty) calculations  
are in nsfont_open.


> Also, note that the cursor position isn't right when the line- 
> spacing frame parameter is used.

That looks bad.  I can't recall any reports on this before, so I'm  
not sure also if it's a recent regression or something that never  
worked (but was never discovered).  Anyway, it should be fixed.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 7 Mar 2009 11:28:28 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

>> If shrinking is useful, that should be added in a
>> platform-independent manner rather than introducing
>> platform-specific variable.

> I find it nice for viewing more lines of code in a window in some
> fonts that seem to space fairly generously.  If others like it,
> perhaps it could be considered for a future version of emacs, using
> the existing line-spacing impl as a starting point.

So, you agree that extending line-spacing is the right direction and
to remove ns-expand-space now?  Otherwise it conflicts/duplicates with
line-spacing with respect to expansion even now.

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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Adrian Robert]

On Mar 8, 2009, at 3:17 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Sat, 7 Mar 2009 11:28:28 +0200, Adrian Robert  
>>>>>> <adrian.b.robert@gmail.com> said:
>
>>> If shrinking is useful, that should be added in a
>>> platform-independent manner rather than introducing
>>> platform-specific variable.
>
>> I find it nice for viewing more lines of code in a window in some
>> fonts that seem to space fairly generously.  If others like it,
>> perhaps it could be considered for a future version of emacs, using
>> the existing line-spacing impl as a starting point.
>
> So, you agree that extending line-spacing is the right direction and
> to remove ns-expand-space now?  Otherwise it conflicts/duplicates with
> line-spacing with respect to expansion even now.

I feel the bug with support for line-spacing under NS should be fixed  
ASAP, and that eventually, after 23.1, if people try the ns-expand- 
space feature under NS and end up liking it / wishing it was present  
on other platforms, line-spacing might be extended and expand-space  
removed.

I don't see a benefit to removing the latter right now during  
pretest, and it would hurt existing users as well as the opportunity  
for others to try it out and judge whether it is a feature worth  
having in core emacs.  There is no conflict with line-spacing -- the  
effects can be additive.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 8 Mar 2009 19:41:59 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

>> So, you agree that extending line-spacing is the right direction
>> and to remove ns-expand-space now?  Otherwise it
>> conflicts/duplicates with line-spacing with respect to expansion
>> even now.

> I feel the bug with support for line-spacing under NS should be
> fixed ASAP, and that eventually, after 23.1, if people try the
> ns-expand- space feature under NS and end up liking it / wishing it
> was present on other platforms, line-spacing might be extended and
> expand-space removed.

> I don't see a benefit to removing the latter right now during
> pretest, and it would hurt existing users as well as the opportunity
> for others to try it out and judge whether it is a feature worth
> having in core emacs.  There is no conflict with line-spacing -- the
> effects can be additive.

I don't understand what is the justification of introducing an
NS-specific variable that overlaps with an existing
platform-independent feature.  Aren't you still in the mood that you
are making a private distribution?

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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Miles Bader]

Adrian Robert <adrian.b.robert@gmail.com> writes:
> I feel the bug with support for line-spacing under NS should be fixed
> ASAP, and that eventually, after 23.1, if people try the ns-expand- 
> space feature under NS and end up liking it / wishing it was present on
> other platforms, line-spacing might be extended and expand-space
> removed.

It's kind of a bad idea to introduce new features in a release, if you
think they'll soon be obsoleted.  Why not try to get things right for
this release, and avoid later compatibility headaches?

-Miles

-- 
Rational, adj. Devoid of all delusions save those of observation, experience
and reflection.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Adrian Robert]

On Mar 9, 2009, at 2:17 AM, YAMAMOTO Mitsuharu wrote:

> I don't understand what is the justification of introducing an
> NS-specific variable that overlaps with an existing
> platform-independent feature.  Aren't you still in the mood that you
> are making a private distribution?

On Mar 9, 2009, at 4:46 AM, Miles Bader wrote:

> It's kind of a bad idea to introduce new features in a release, if you
> think they'll soon be obsoleted.  Why not try to get things right for
> this release, and avoid later compatibility headaches?

I don't have any personal agenda here except that I like the feature  
as a user.  The "expand-space" feature has been in the NS code for 10  
or more years.  I didn't introduce it.  For the past few years that  
I've maintained it on sourceforge, I have however enjoyed the feature  
greatly myself.  I never knew about line-spacing in core emacs or if  
I did it was not of interest to me because I'm usually interested in  
shrinking not expanding lines.  I wish it were available for the  
times I use emacs on X or W32.

But now that the situation is what it is I stand by what I say above:  
it doesn't interfere with anything in core emacs (as it is / should  
be additive with line-spacing), users benefit from it, and others can  
use it to try and see whether it's something that would be worth  
having on X and W32.  There's no benefit to removing it.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 9 Mar 2009 09:53:35 +0200, Adrian Robert <adrian.b.robert@gmail.com> said:

> I don't have any personal agenda here except that I like the feature
> as a user.  The "expand-space" feature has been in the NS code for
> 10 or more years.  I didn't introduce it.

I said "introduce" because the NS code hasn't been a part of the
official Emacs distribution.  To become a part of it, the
Cocoa/GNUstep port has to have enough quality such as proper C-g
handling that the port hasn't had for 10 or more years, and reorganize
duplicated/overlapped features.

> For the past few years that I've maintained it on sourceforge, I
> have however enjoyed the feature greatly myself.  I never knew about
> line-spacing in core emacs or if I did it was not of interest to me
> because I'm usually interested in shrinking not expanding lines.  I
> wish it were available for the times I use emacs on X or W32.

> But now that the situation is what it is I stand by what I say
> above: it doesn't interfere with anything in core emacs (as it is /
> should be additive with line-spacing), users benefit from it, and
> others can use it to try and see whether it's something that would
> be worth having on X and W32.  There's no benefit to removing it.

The benefit of removal is apparent: if it is kept, it will introduce
inconsistent multiple interfaces for the same feature when the right
thing is done in a platform-independent way in future.  (I think even
the current situation is problematic with respect to expanding.)
That's why we should avoid introducing platform-specific interfaces
for features that are not inherently specific to the platform.  I
think the developers of the official Emacs (in contrast to those of
private distributions) should keep that in mind.

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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Miles Bader]

Adrian Robert <adrian.b.robert@gmail.com> writes:
> But now that the situation is what it is I stand by what I say above: it
> doesn't interfere with anything in core emacs (as it is / should  be
> additive with line-spacing), users benefit from it, and others can  use
> it to try and see whether it's something that would be worth  having on
> X and W32.  There's no benefit to removing it.

We do not want to have to keep supporting multiple redundant interfaces
if we can help it, especially system-dependent ones.

If we don't _remove_ it, but it appears likely that it will merged with
the generic emacs interface (and it that certainly appears like the best
option to me), then at least we shouldn't _advertise_ it (and should
instead put in the doc "don't depend on this, it will go away in the
future").

-Miles

-- 
Genealogy, n. An account of one's descent from an ancestor who did not
particularly care to trace his own.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Stefan Monnier]

> But now that the situation is what it is I stand by what I say above: it
> doesn't interfere with anything in core emacs (as it is / should be
> additive with line-spacing), users benefit from it, and others can use it
> to try and see whether it's something that would be worth having on X and
> W32.  There's no benefit to removing it.

This would encourage the use of MacOSX to try the feature.  As long as
MacOSX is not Free Software, this goes against our goals.  Also I think
it's pretty clear that the `line-spacing' feature can be expanded to
cover the featureset of `ns-expand-space' and that it would be good
since it would remove a redundant setting, and bring that feature to
all architectures.

So we should remove ns-expand-space right now.  If we can come up with
a clean enough patch to extend line-spacing's semantics, we might be
able to consider it for inclusion in Emacs-23.1, otherwise it'll have to
wait for Emacs-23.2.


        Stefan

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Adrian Robert]

On Mar 9, 2009, at 3:19 PM, Stefan Monnier wrote:

>> But now that the situation is what it is I stand by what I say  
>> above: it
>> doesn't interfere with anything in core emacs (as it is / should be
>> additive with line-spacing), users benefit from it, and others can  
>> use it
>> to try and see whether it's something that would be worth having  
>> on X and
>> W32.  There's no benefit to removing it.
>
> This would encourage the use of MacOSX to try the feature.  As long as
> MacOSX is not Free Software, this goes against our goals.  Also I  
> think
> it's pretty clear that the `line-spacing' feature can be expanded to
> cover the featureset of `ns-expand-space' and that it would be good
> since it would remove a redundant setting, and bring that feature to
> all architectures.
>
> So we should remove ns-expand-space right now.  If we can come up with
> a clean enough patch to extend line-spacing's semantics, we might be
> able to consider it for inclusion in Emacs-23.1, otherwise it'll  
> have to
> wait for Emacs-23.2.

OK.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[David Reitter]

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

On Mar 9, 2009, at 4:50 PM, Adrian Robert wrote:
>>
>> So we should remove ns-expand-space right now.  If we can come up  
>> with
>> a clean enough patch to extend line-spacing's semantics, we might be
>> able to consider it for inclusion in Emacs-23.1, otherwise it'll  
>> have to
>> wait for Emacs-23.2.
>
> OK.

I'm working on a patch for this issue.

- David


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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Dan Nicolaescu]

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

  > > But now that the situation is what it is I stand by what I say above: it
  > > doesn't interfere with anything in core emacs (as it is / should be
  > > additive with line-spacing), users benefit from it, and others can use it
  > > to try and see whether it's something that would be worth having on X and
  > > W32.  There's no benefit to removing it.
  > 
  > This would encourage the use of MacOSX to try the feature.  As long as
  > MacOSX is not Free Software, this goes against our goals.  Also I think
  > it's pretty clear that the `line-spacing' feature can be expanded to
  > cover the featureset of `ns-expand-space' and that it would be good
  > since it would remove a redundant setting, and bring that feature to
  > all architectures.
  > 
  > So we should remove ns-expand-space right now.  If we can come up with
  > a clean enough patch to extend line-spacing's semantics, we might be
  > able to consider it for inclusion in Emacs-23.1, otherwise it'll have to
  > wait for Emacs-23.2.

How about similar features that are in the ns specific files, but should
be generic (if they should be included at all).  

When the ns support was included, I sent a few messages with reviews,
and found quite a few such things.

The ones that  I remember right away are in nsfns.m 

  /* FIXME: Because of the typo below, Qbuffered probably never did
     anything useful, so it might as well be removed. */
  Qbuffered = intern ("bufferd");
  staticpro (&Qbuffered);

??? Whis is this kept around? 


  Qfontsize = intern ("fontsize");
  staticpro (&Qfontsize);

What about this one?


  DEFVAR_LISP ("ns-icon-type-alist", &Vns_icon_type_alist,
               doc: /* Alist of elements (REGEXP . IMAGE) for images of icons associated to frames.
If the title of a frame matches REGEXP, then IMAGE.tiff is
selected as the image of the icon representing the frame when it's
miniaturized.  If an element is t, then Emacs tries to select an icon
based on the filetype of the visited file.

The images have to be installed in a folder called English.lproj in the
Emacs folder.  You have to restart Emacs after installing new icons.

Example: Install an icon Gnus.tiff and execute the following code

  (setq ns-icon-type-alist
        (append ns-icon-type-alist
                '((\"^\\\\*\\\\(Group\\\\*$\\\\|Summary \\\\|Article\\\\*$\\\\)\"
                   . \"Gnus\"))))

When you miniaturize a Group, Summary or Article frame, Gnus.tiff will
be used as the image of the icon representing the frame.  */);
  Vns_icon_type_alist = Fcons (Qt, Qnil);

This definitely looks like it should be generic, or not included at all.

There are a few more in ns-win.el.  Like redefining the standard menu structure, but there are more.

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Dan Nicolaescu]

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

  > >   /* FIXME: Because of the typo below, Qbuffered probably never did
  > >      anything useful, so it might as well be removed. */
  > >   Qbuffered = intern ("bufferd");
  > >   staticpro (&Qbuffered);
  > > ??? Whis is this kept around? 
  > 
  > Feel free to remove such dead code.
  > 
  > >   Qfontsize = intern ("fontsize");
  > >   staticpro (&Qfontsize);
  > > What about this one?
  > 
  > What about it?

Isn't dealing with font sizes supposed to be cross-platform?
font.c: font_open_for_lface
[snip]
#ifdef HAVE_NS
      if (size == 0)
        {
          Lisp_Object ffsize = get_frame_param(f, Qfontsize);
          size = NUMBERP (ffsize) ? POINT_TO_PIXEL (XINT (ffsize), f->resy) : 0;
        }
#endif

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Stefan Monnier]

>> >   /* FIXME: Because of the typo below, Qbuffered probably never did
>> >      anything useful, so it might as well be removed. */
>> >   Qbuffered = intern ("bufferd");
>> >   staticpro (&Qbuffered);
>> > ??? Whis is this kept around? 
>> 
>> Feel free to remove such dead code.
>> 
>> >   Qfontsize = intern ("fontsize");
>> >   staticpro (&Qfontsize);
>> > What about this one?
>> 
>> What about it?

> Isn't dealing with font sizes supposed to be cross-platform?
> font.c: font_open_for_lface
> [snip]
> #ifdef HAVE_NS
>       if (size == 0)
>         {
>           Lisp_Object ffsize = get_frame_param(f, Qfontsize);
>           size = NUMBERP (ffsize) ? POINT_TO_PIXEL (XINT (ffsize), f->resy) : 0;
>         }
> #endif

Yes, but I don't know what this piece of code is supposed to do.  It can
probably be removed.


        Stefan

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 09 Mar 2009 09:19:43 -0400, Stefan Monnier <monnier@iro.umontreal.ca> said:

> This would encourage the use of MacOSX to try the feature.  As long
> as MacOSX is not Free Software, this goes against our goals.

In this respect, the group 3 in
http://lists.gnu.org/archive/html/emacs-devel/2009-03/msg00123.html
is also a target of immediate removal, assuming that these features
are not added to the other platforms at this timing.

3. NS-only implementation for features that are not inherently specific to NS.

  a. preferences panel
  b. alpha-component in color specification
  c. color image for stipple (cf. tiling patch by Miles Bader)

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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[Miles Bader]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:
>   a. preferences panel
>   b. alpha-component in color specification
>   c. color image for stipple (cf. tiling patch by Miles Bader)

Wouldn't we want some of these for non-NS systems?

[Especially the alpha component]

Perhaps some NS features should be merged into the core; even if
currently they lack good backend support, much of the code is probably
in non-backend places, and existing NS support would help keep it from
bit-rotting.

-Miles

-- 
`The suburb is an obsolete and contradictory form of human settlement'

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 10 Mar 2009 12:16:58 +0900, Miles Bader <miles@gnu.org> said:

>> a. preferences panel
>> b. alpha-component in color specification
>> c. color image for stipple (cf. tiling patch by Miles Bader)

> Wouldn't we want some of these for non-NS systems?

> [Especially the alpha component]

Yes.  I'd encourage to make a uniform specification/interface toward
Emacs 23.2 or later, in order to avoid compatibility problems in
future.  The current alpha-comonent spec in NS is incompatible with
that of XRenderParseColor for example, and such things happen if
platform-independence is not in mind from the beginning.

Even with the uniform spec, there are some glitches in the NS
implementation as reported to the Emacs.app devel list.  So, it's a
good chance to defer the bug fixes for the alpha-component support by
dropping it so as to allocate more time for more important fixes at
this timing.

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

Re: NS: ns-expand-space / slider in Preferences dialog not functional

[David Reitter]

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

On 6 Mar 2009, at 21:15, Adrian Robert wrote:
>> Emacs already has the line-spacing setting as frame parameter,
>> buffer-local variable, and text property.  So, ns-expand-space
>> can/should be removed.
>
> The semantics are different.  line-spacing can only be used to  
> increase line spacing (i.e. add padding between lines).  ns-expand- 
> space can be used to expand or shrink.

Is there a reason why the default (and ns-expand-space set to 1.0)  
results in wider line spacing than with Emacs 22?

Also, note that the cursor position isn't right when the line-spacing  
frame parameter is used.


[-- Attachment #1.2: pastedGraphic.png --]
[-- Type: image/png, Size: 78186 bytes --]

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




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

[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: 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 --]