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