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

[Dan Nicolaescu]

Adrian Robert <address@hidden> writes:

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

The problem is that this is generic functionality, not ns specific, so
it should not be in ns specific files.  The thing is if something makes
it into a released version of emacs it will have to be supported until
the end of time.  If some functionality gets implemented differently
later in the cross platform part of emacs, it will just add complexity
to the code.  And it will make the life of elisp writers more
complicated: they'd have to write (if (featurep 'ns) (foo) (bar)) or
(if (boundp 'ns-icon-type-alist) (foo) (bar)).  That is unclean and
better avoid it.

  > Someone took the effort to write it at some point, and I assume it
  > has been found useful.

Again, please don't try to force generic functionality in through
platform specific code.

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

IMVHO this is just an extra knob that almost nobody would use.  Did the
Carbon port have something similar?

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

Probably, please talk to Handa-san about that.

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

If this is a better interface to this functionality, then IMHO it would
be better make it available under a generic name, and then the other
platforms can catch up and use this name.  Stefan and Jason had opinions
about this in other replies, so you might want to talk to them about the
details.