emacs-devel
[Top][All Lists]
Advanced

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

Re: NeXTStep port preferences


From: David Reitter
Subject: Re: NeXTStep port preferences
Date: Sat, 19 Jul 2008 11:59:07 -0400

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: smime.p7s
Description: S/MIME cryptographic signature


reply via email to

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