From: Adrian Robert <Adrian.B.Robert@gmail.com>
To: emacs-devel@gnu.org
Subject: Re: NeXTStep port preferences
Date: Thu, 17 Jul 2008 17:32:13 +0000 (UTC) [thread overview]
Message-ID: <loom.20080717T170654-350@post.gmane.org> (raw)
In-Reply-To: 8966189D-F430-4224-80BA-FA3653642C01@gmail.com
David Reitter <david.reitter <at> gmail.com> writes:
> The new NeXTStep / Cocoa port contains a "Preferences" dialog.
>
> Is this wanted, or just a mistake when merging? It is inconsistent
> with all the other customizations, at least in terms of UI.
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.
> 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.
> A better preferences system would be much welcomed, but it should be
> compatible with existing customizations. The selection of preferences
> seems arbitrary; why the cursor type, or line spacing?
The preferences window controls surface aspects of the GUI that
were not already controlled by other GUI methods. Font, color,
frame dimensions, and toolbar presence are handled by mouse
actions or popup windows (at least, until the font and color
panels will be removed from Emacs.app). The modifier key
mappings were also added because they are a notorious point of
varying preferences among OS X users.
Anyway, the functioning of this facility is already broken by
recent checkins which override the system highlight color and
antialiasing selections. I suspect it will quickly be removed.
Unfortunately users will never be consulted. It is also not
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.
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. Otherwise, at least in this case, there's
no real reason not to just use the X11 version on OS X (and
GNUstep platforms). Apple has not said they will stop supporting X.
next prev parent reply other threads:[~2008-07-17 17:32 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-16 5:36 NeXTStep port preferences David Reitter
2008-07-17 17:32 ` Adrian Robert [this message]
2008-07-19 11:18 ` Benjamin Riefenstahl
2008-07-20 15:05 ` Adrian Robert
2008-07-20 16:53 ` Benjamin Riefenstahl
2008-07-21 15:04 ` Justin Bogner
2008-07-19 15:59 ` David Reitter
2008-07-19 16:01 ` David Reitter
2008-07-19 16:21 ` Adrian Robert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=loom.20080717T170654-350@post.gmane.org \
--to=adrian.b.robert@gmail.com \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.