Re: NeXTStep port preferences

[David Reitter <david.reitter@gmail.com>]

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

Adrian,

On 17 Jul 2008, at 13:32, Adrian Robert wrote:
>
> The logic is similar to the "Options" menu, which itself
> is "inconsistent with all other customizations": put a few of the
> most frequently desired quick changes in a convenient place.

How did you evaluate or estimate what customizations are frequent?
For instance, how frequently would people want to use a highlight  
color in Emacs that is different from the rest of the system?  Or use  
ugly, non-antialiased fonts and even choose special (deprecated)  
"quickdraw" rendering?
How come the cursor blink rate is considered a frequently used setting?

>>
>> Where are these preferences stored?
>
> They are stored using the NS equivalent to X resources, as has
> been discussed previously on this list and various OS X emacs
> lists.

Why are those settings stored in org.gnu.Emacs.plist, while others  
(from the Options menu) are stored in the custom-file?
This makes it harder for people to troubleshoot their settings.

I for instance have trouble with the antialiasing (can't turn it on in  
the current build). There's now an extra file location to know and to  
check for possible adverse settings.


>
> The preferences window controls surface aspects of the GUI that
> were not already controlled by other GUI methods.

Yes, but customization buffers control GUI aspects, too.  (Besides,  
your statement is inconsistent with the paragraph I quoted first,  
above.)

I am under the impression that this special dialog contains settings  
that are specific to the Cocoa port.  I believe that the technical  
layer or revision at which a setting was introduced should not  
influence the UI.

> The modifier key
> mappings were also added because they are a notorious point of
> varying preferences among OS X users.

I'll buy that for the Meta/Option/Command key assignment.  This could  
be handled via the Options menu.

> Anyway, the functioning of this facility is already broken by
> recent checkins which override the system highlight color and
> antialiasing selections.

Antialiasing doesn't work any longer for me, the fonts look horrible.
How does one turn it back on?
How do I find out the system's highlight color via Lisp?


>  something easy to maintain outside of GNU Emacs itself (e.g. in a
> distribution like Aquamacs) because it involves integrated
> Objective C code and additional files going into the bundle.

I'm happy to write ObjC code - happier actually than writing Carbon  
code in C--.

One thing I am annoyed with is that the Apple Events map has gone -  
this was an elegant way to integrate events with the standard Emacs  
event map system.
This was important for the Preferences / About Emacs menu items, but  
also for external interfaces (ODOC events, e.g.)

> The desire to keep all GUI interfaces to Emacs similar to one
> another is a reasonable one.  However, some concessions to
> platform convention and user convenience ought to be tolerated on
> a case-by- case basis depending on the user-benefit to
> obtrusiveness ratio.

I was arguing for that 3 or 4 years ago, but the events since have  
convinced me that we need to cater to two distinct user groups, with  
two different packages.

- D

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