emacs-devel
[Top][All Lists]
Advanced

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

Re: NeXTStep port preferences


From: Adrian Robert
Subject: Re: NeXTStep port preferences
Date: Sun, 20 Jul 2008 15:05:59 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

Benjamin Riefenstahl <b.riefenstahl <at> turtle-trading.net> writes:

> I have been trying to work with that dialog some and have been mostly
> frustrated.   Some thoughts:
> 
> - Quick access to the options for default font and modifier keys are
>   usefull for first installation and probably for newbies.

Some users differ.  There are many use cases calling for frequent
font and/or modifier key changes.  We'd need a poll to get better
data.


> - The options to change the cursor are probably not important enough
>   to have here.

Again, see above.  I use different types of cursors for editing
different files (coding, text, etc.), and it's nice to switch
quickly.


>  [If I understand this right, there are new NextStep
>   specific cursor drawing routines in the port.  This is not good, I
>   think.  If the portable cursor routines are deficient they should be
>   updated for all platforms.  I may be missing something here.]

This has been in the TODO list for some years, but because it has
been working well enough and there have been higher-priority
issues (e.g., bugs) it has not gotten done.  It would be great if
someone could work on this.



> - I am missing the "Emacs.geometry" option in the defaults database.
>   For me "Emacs.font" and "Emacs.geometry" are the two options that I
>   need in the defaults database, everything else is better in
>   ".emacs".

'geometry' is split into Width, Height, Top, Left entries.  If
changing this to geometry and possibly using an X11-compatible
string would be better, a patch is welcome.


 
> - The font setting mechanism doesn't work unless an Emacs frame is
>   selected.  This used to be documented in the readme, but it is still
>   a bug.

Another long-standing TODO fallen victim to more urgent tasks.
Help is welcome.


 
> - The callbacks that the Cocoa dialogs call are not protected in a
>   catch block.  If they run into an error, Emacs aborts without a
>   visible error message.

I've never had a bug report on this, but if it's an easy fix we
should do it.


> > It is also not something easy to maintain outside of GNU Emacs
> > itself (e.g. in a distribution like Aquamacs)
> 
> It is not easy to be maintained anywhere.  As you notice, it is broken
> even now, and only part of that is bit-rot.

This is a bit harsh.  It has been part of Emacs.app for years and
has had few problems.


> > However, some concessions to platform convention and user
> > convenience ought to be tolerated on a case-bycase basis depending
> > on the user-benefit to obtrusiveness ratio.
> 
> I don't think that a buggy and old-fashioned looking dialog (IMO) is
> really an asset for anybody, certainly not Mac users.

Again, "buggy" is a little unfair.  If you search the Emacs.app
mailing list and bug database you find a lot of other bugs
reported, but very rarely anything with this.  Also you are the
first person to mention anything negative about the appearance.
On the other hand there have been many positive comments from
users.


> > Otherwise, at least in this case, there's no real reason not to just
> > use the X11 version on OS X
> 
> The inconvenience of having to start X11 to edit files or to read mail
> and probably missing features (e.g. does DnD work from Finder to
> Emacs?).

It would be far easier to add these features to Apple's X11 impl
than to port and maintain a separate interface to GNU Emacs.  And
they would provide wider benefit.







reply via email to

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