Re: observations for ns*.m files (Re: Emacs.app merged)

[Adrian Robert]

On Jul 27, 2008, at 10:58 PM, Dan Nicolaescu wrote:

> >     DEFVAR_LISP ("ns-icon-type-alist", &Vns_icon_type_alist,
> >                  doc: /* Alist of elements (REGEXP . IMAGE) for  
> > images of
> >    icons associated to frames.
> >    ...
> >
> >    This looks like a generic thing, better not make it platform
> >    specific.  Is there a problem with the normal way of specifying  
> > icons?
> >
> >
> > What is the normal way?  I think this facility in the NS port  
> > probably dates
> > from before emacs itself had this feature, so certainly we should  
> > try to use
> > the generic code now.
>
> You can set a icon as a frame parameter.

This is a different approach.  ns-icon-type-alist allows all frames w/ 
titles matching a regexp to get a certain icon.  I'm not sure how  
widely used this is, but the code is there, it's working, there have  
been no complaints about it, I'd rather leave it.  Someone took the  
effort to write it at some point, and I assume it has been found useful.



> >    void
> >    syms_of_nsterm ()
> >    {
> >     DEFVAR_LISP ("ns-command-modifier", &ns_command_modifier,
> >                  "This variable describes the behavior of the  
> > command key.\n\
> >    Set to control, meta, alt, super, or hyper means it is taken to  
> > be that
> >    key.");
> >
> >     DEFVAR_LISP ("ns-control-modifier", &ns_control_modifier,
> >                  "This variable describes the behavior of the  
> > control key.\n\
> >    Set to control, meta, alt, super, or hyper means it is taken to  
> > be that
> >    key.");
> >
> >    These 2 look identical, are they both needed?  Are they needed  
> > at all
> >    after the recent modifier changes?
> >
> >
> > On Mac keyboards, Command and Control are separate keys, so both  
> > are needed.
>
> So you can change the meaning of Control?  That sounds strange.  Maybe
> Meta/Alt are sometime confused, but Control should be pretty well
> established.  Do users actually want this?

I'm not sure, they definitely want to map modifiers for alt and  
command keys.  It's more consistent to handle all modifiers the same  
way, and keeps the code simpler.  Furthermore, the control panel  
interface on OS X where modifiers can be remapped also shows all keys,  
so this is consistent with that.


> > What recent modifier changes are you referring to?
>
> where-is-preferred-modifier

OK, no that relates to a different issue.



> >     DEFVAR_LISP ("ns-antialias-text", &ns_antialias_text,
> >                  "Non-nil (the default) means to render text  
> > antialiased. Only
> >    has an effect on OS X Panther and above.");
> >
> >    Can the generic functionality be used instead of this?
> >
> >
> > Which generic functionality?
>
> There's support for antialiasing in X, I know no details about it as I
> don't use it.

Maybe there's a case for x-antialias-text now, applicable to all  
platforms, with caveat that it's ignored where not supported.



> One more thing:
>
> DEFUN ("ns-set-alpha", Fns_set_alpha, Sns_set_alpha, 2, 2, 0,
>       doc: /* Return a color equivalent to COLOR with alpha setting
>       ALPHA.
> The argument ALPHA should be a number between 0 and 1, where 0 is full
> transparency and 1 is opaque.  */)
>
> Not sure about the details, but can this functionality be replaced by
> an implementation of x_set_frame_alpha?

This is a utility function.  There's also ns-set-background-alpha.  I  
would like to replace it with the new alpha frame parameter, but the  
meaning is different.  For x_set_frame_alpha, the alpha of the entire  
window is intended (including the text).  ns-set-background-alpha  
changes only the background, which usually results in more readable  
text.  But I'm not sure that any other platform can support this right  
now.  Maybe drop ns-set-background-alpha and make a customized  
variable ns-frame-alpha-affects-only-background?