emacs-devel
[Top][All Lists]
Advanced

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

Re: ns-win.el [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make


From: Adrian Robert
Subject: Re: ns-win.el [was Re: [Emacs-diffs] /srv/bzr/emacs/trunk r102057: Make all 3 copies of x-select-enable-clipboard have the same doc.]
Date: Tue, 26 Oct 2010 08:07:58 +0300

On 2010/10/26, at 5:59, Glenn Morris wrote:

> 
>>> I haven't looked at the ns-win code in a while so I'm a little hesitant to
>>> attempt the cleanup now, but if someone wants to try I'm happy to answer
>>> questions about "why the heck is this thing in there?" etc. and test the
>>> resulting changes.
> 
> I made ns load common-win.

Thanks for tackling this.


> The [x,ns]-handle-* stuff is still to be addressed.

The 'nxopen' functions you removed fro ns-win are referenced from startup.el.  
The -NSOpen argument is neither needed nor current any longer under OS X, but I 
think it might still be used under GNUstep.



> 1. Are the 'ns specific menu adjustments that are now in menu-bar.el
> really necessary? They seem so trivial as to be pointless.
> 
> An extra "spell" menu "for platform consistency", renaming the "Paste
> from Kill Menu" item, etc.

They are minor, but make a significant difference in making the menus seem less 
alien on the platform.  On the other hand anything less minor would deviate too 
much from the common emacs UI and confuse users coming from other platforms.  
They are a compromise, but a reasonable one.

On the other hand, they were moved from menu-bar.el TO ns-win.el during the 
merge.  It was desired to keep these platform-specific things in the 
platform-specific file rather than cluttering up common files, and I've come to 
agree myself this is the best way.



> 2. Why all the wacky stuff in x-setup-function-keys? Why does the ns
> port need to define the f1 key etc in system-key-alist, when no other
> port does.

If you're talking about the systen-key-alist stuff, as I understand it that was 
there to define keys that existed on X platforms but not NeXT keyboards.  As 
such, some of it is obsolete.  Macs and GNUstep boxes have function keys now, 
so those can be removed.  Also the special ns- mappings that are no longer used 
can be removed.  This evening I will try removing as much as possible, and 
check the result in to trunk if it tests OK.



> 3. Why doesn't it define iso-lefttab in x-alternatives-map?

I don't have any opinion on this, but there was a recent related bug thread: 
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6616 .  I don't know enough to say 
if this is just something appropriate under X11 or if NS should use iso-lefttab 
as well.



> 4. Is the before-make-frame-hook in ns-win really necessary?
> Surely this is a window manager's job?

The result without doing that is making a new frame over the top one, because 
the left/top parameters default to those from the frame-alist.  This behavior 
is confusing to the user, so we put in this offset.



> 5. Does the ns port really need a special ns-print-buffer command?

It's a good idea to confirm a non-undoable action like printing beforehand.  
I'd rather recommend to add a print-buffer-with-confirm to common code, or 
change the existing one to confirm.



> 6. ns-ignore-2-arg seems unused?

You are right, it can be removed.



> 7. Can the 'mac- aliases be declared obsolete?

I'd prefer to do so, but they are there for compatibility with the earlier 
Carbon port, and presumably Yamamoto Mitsuharu's current ports which are used 
by some people.  The Aquamacs community also uses these heavily.



> 8. If running under GNUstep, rename "Help" to "Info". Is that really needed?
> More generally, can the remaining menu-bar fiddling be done more
> elegantly in menu-bar.el?

See above under (1).



thanks,
Adrian





reply via email to

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