Platform-specific symbols in cus-start.el

Platform-specific symbols in cus-start.el

[Eli Zaretskii]

This change:

    2009-03-21  David Reitter <david.reitter@gmail.com>

	    * cus-start.el (all): add
	    `ns-{control|command|alternate|function}-modifier',
	    `ns-antialias-text' and `ns-use-qd-smoothing'

was incomplete.  You cannot just add platform-specific symbols to
cus-start.el, because building Emacs will then output warning
messages, like this:

    Loading cus-start...
    Note, built-in variable `ns-control-modifier' not bound
    Note, built-in variable `ns-command-modifier' not bound
    Note, built-in variable `ns-alternate-modifier' not bound
    Note, built-in variable `ns-function-modifier' not bound
    Note, built-in variable `ns-antialias-text' not bound
    Note, built-in variable `ns-use-qd-smoothing' not bound

You need to add something to the code that avoids warnings for symbols
that are native to specific platforms.  See the change I committed; I
have no way of testing that on NextStep, so please see that I didn't
break anything.

Also, please don't use regexp-like shorthands in ChangeLog entries, as
this is against GNU coding standards (it defeats searching for changes
using grep).  Please always state the full names of functions,
variables, files, etc.

Re: Platform-specific symbols in cus-start.el

[David Reitter]

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

On Mar 21, 2009, at 5:48 AM, Eli Zaretskii wrote:
> was incomplete.  You cannot just add platform-specific symbols to
> cus-start.el, because building Emacs will then output warning
> messages, like this:

I see, thank you.  There's a couple more things that need to be done  
as well (such as defining the Nextstep group).

> You need to add something to the code that avoids warnings for symbols
> that are native to specific platforms.  See the change I committed; I
> have no way of testing that on NextStep, so please see that I didn't
> break anything.

Yes, this works.

Related to this, is the kludge below found in nsterm.m appropriate, or  
should cus-start be fixed?


   /* these are unsupported but we need the declarations to avoid  
whining
      messages from cus-start.el */
   DEFVAR_BOOL ("x-use-underline-position-properties",
	       &x_use_underline_position_properties,
      doc: /* NOT SUPPORTED UNDER NS.
*Non-nil means make use of UNDERLINE_POSITION font properties.
A value of nil means ignore them.  If you encounter fonts with bogus
UNDERLINE_POSITION font properties, for example 7x13 on XFree prior
to 4.1, set this to nil.

NOTE: Not supported on Mac yet.  */);
   x_use_underline_position_properties = 0;


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

Re: Platform-specific symbols in cus-start.el

[Stefan Monnier]

> Related to this, is the kludge below found in nsterm.m appropriate, or
> should cus-start be fixed?

Not sure if it's the best solution, but since it reproduces what's done
in w32term.c, it's no worse than what we already have.


        Stefan

Re: Platform-specific symbols in cus-start.el

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: David Reitter <david.reitter@gmail.com>
> Date: Sat, 21 Mar 2009 08:53:54 -0400
> 
> Related to this, is the kludge below found in nsterm.m appropriate, or  
> should cus-start be fixed?
> 
> 
>    /* these are unsupported but we need the declarations to avoid whining
>       messages from cus-start.el */
>    DEFVAR_BOOL ("x-use-underline-position-properties",
> 	       &x_use_underline_position_properties,
>       doc: /* NOT SUPPORTED UNDER NS.
> *Non-nil means make use of UNDERLINE_POSITION font properties.
> A value of nil means ignore them.  If you encounter fonts with bogus
> UNDERLINE_POSITION font properties, for example 7x13 on XFree prior
> to 4.1, set this to nil.
> 
> NOTE: Not supported on Mac yet.  */);
>    x_use_underline_position_properties = 0;

We could add an extra `cond' clause where it filters out symbols
native to other platforms, and then you could remove this DEFVAR_BOOL.
But, as Stefan points out, it's probably not worth the hassle to do
that for the sake of a single obscure variable, unless we think users
might be fooled to think that the existence of the variable means the
feature is supported.

Re: Platform-specific symbols in cus-start.el

[YAMAMOTO Mitsuharu]

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

>> Related to this, is the kludge below found in nsterm.m appropriate,
>> or should cus-start be fixed?

> Not sure if it's the best solution, but since it reproduces what's
> done in w32term.c, it's no worse than what we already have.

An alternative solution is to use this variable
(x-use-underline-position-properties) in a meaningful way.  NSFont has
a method to extract the underline position defined by the font, but
the current implementation of the Cocoa/GNUstep port unconditionally
ignores that value.

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