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

[Adrian Robert <adrian.b.robert@gmail.com>]

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

On Jul 27, 2008, at 4:12 PM, Dan Nicolaescu wrote:

> I noticed that this function in frame.el does not have a check for ns,
> shouldn't it?
>
> (defun face-set-after-frame-default (frame &optional parameters)
>  "Initialize the frame-local faces of FRAME.

Yes, thanks, added.  Note, most of these window-system checks  
throughout the lisp code simply check for every window system (x, w32,  
ns, and formerly, mac).  It might be good at some point to change all  
these to simply check whether a window system is being used.


> "x-create-frame" does not do a copy_alist at the beginning like the
> other ports to.  On Windows not having that resulted in some strange
> behavior.  It might be a good idea to sync that function with the X
> version again.

OK.


> What is the #ifdef HAVE_NS code in frame.c:x_get_frame used for?
> ...
>                                 if (!strcmp (SDATA (lower), "on")
> #ifdef HAVE_NS
>                    || !strcmp(SDATA(lower), "yes")
> #endif
>                    || !strcmp (SDATA (lower), "true"))
> ...
> Is "yes" and "no" something that some other program on the system can
> write? Or something that the user would write?  If the latter, then
> wouldn't it be better to just teach the users to use the values all
> other systems uses and avoid complications in code and docs?

"YES" and "NO" are the standard boolean values used in the NS defaults  
system.  A property list editor or a user could write them.  As far as  
teaching users, I would hope that the purpose of application software  
is to adapt computers to users rather than the other way around!  ;)


On Jul 27, 2008, at 6:18 PM, Dan Nicolaescu wrote:

> void
> syms_of_nsfns ()
>  ...
>  Qns_frame_parameter = intern ("ns-frame-parameter");
>  		      	^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> This seems unused, better get rid of it.

Done.



>  Qbuffered = intern ("bufferd");
>
> Did this ever work given the typo?  Is it something that people would
> care enough about to have an option?

I think it's just something I copied from an earlier version of x- 
create-frame in some other term.  I've replaced it with alpha.



>  Qfontsize = intern ("fontsize");
>  staticpro (&Qfontsize);
>
> This seems a generic facility, should it be here?  Can't the generic
> way of specifying fonts work on this platform too?

I'm not sure if there is a generic facility.  On X, font size is part  
of the XLFD strings.  These are not used except where absolutely  
necessary on NS, and I would like to get rid of these cases.



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



> void
> syms_of_nsselect (void)
> {
>
> /* 23: { */
>  DEFVAR_LISP ("selection-coding-system", &Vselection_coding_system,
> ...
> DEFVAR_LISP ("next-selection-coding-system",  
> &Vnext_selection_coding_system,
>
> These were removed from the X code:
>
> 2008-02-01  Kenichi Handa  <handa@m17n.org>
>
> 	    * xselect.c (Vselection_coding_system)
> 	    (Vnext_selection_coding_system): Delete them.
>
> are they still needed for ns?

These were not actually used in the NS code, so I've now dropped  
them.  However note they are still present in W32 and DOS.



> 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.  What recent modifier changes are you referring to?



>  DEFVAR_LISP ("ns-cursor-blink-mode", &ns_cursor_blink_mode,
>               "Internal variable -- use M-x blink-cursor-mode or  
> preferences\n\
> panel to control this setting.");
>
> Is this needed?  Can't the standard blink-cursor-mode be used?

That's the goal, but it's not trivial (http://thread.gmane.org/gmane.emacs.devel/101190/focus=101588 
).  Hopefully eventually.



>  DEFVAR_LISP ("ns-expand-space", &ns_expand_space,
>               "Amount by which spacing between lines is expanded  
> (positive)\n\
> or shrunk (negative).  Zero (the default) means standard line height. 
> \n\
> (This variable should only be read, never set.)");
>
> This is generic, better not make it ns specific.  Can this can be done
> in platform specific code without changes to redisplay?  It seems a
> bit strange anyway.

This might be the same as the lineSpacing frame parameter.  Can  
someone say whether it is?  ns-expand-space is as documented above, a  
way for the user to customize how close together or spread apart lines  
are vertically.  If so, we can hook up this code to that parameter.



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



>  DEFVAR_LISP ("ns-use-system-highlight-color",
>               &ns_use_system_highlight_color,
>               "Whether to use the system default (on OS X only) for  
> the highlight color.  Nil means to use standard emacs (prior to  
> version 21) 'grey'.");
>
> Is this the region color or something else?

Yes, the 'region' face.  I'll update the doc.



[-- Attachment #2: Type: text/html, Size: 9454 bytes --]