emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Adrian Robert
Subject: Re: observations for ns*.m files (Re: Emacs.app merged)
Date: Sun, 27 Jul 2008 21:54:50 -0400

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  <address@hidden>

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]