Re: ns-win.el

[Adrian Robert <adrian.b.robert@gmail.com>]

On 2010/10/26, at 9:45, Glenn Morris wrote:

> Adrian Robert wrote:
> 
>> The 'nxopen' functions you removed fro ns-win are referenced from
>> startup.el.
> 
> I didn't remove any nxopen functions?

My mistake -- I confused lines when reading the changelog.



>> 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.
> 
> Whoops. I have to say I disagree, since it is more work to change the
> menus after they are defined, and it means requiring easymenu in the
> dumped ns Emacs; and this means putting it in the DOC file for every
> platform. I also find it much easier to see all the menu definitions at
> one place rather than have them scattered over multiple files.

I don't feel strongly, but having it in ns-win.el makes it clearer what is done differently for that platform and keeps the clutter out for people reading the common code.  The code isn't that much "work" and it's limited to when the NS windowing system is actually used.  Does it really need to be in DOC file for all builds, or just builds that include NS?



>> 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.
> 
> BTW I kind of thought the point of Emacs was to look the same on all
> platforms; but I only use it on GNU/Linux.

I'd say the "point" of emacs is to provide second-to-none editing functionality, and a secondary point is to deliver it on as many platforms as possible with least overall friction for users.  If the port was remapping M-x or something like that, I'd see a problem.  This is much more "trivial" which interferes in no way with functionality but nonetheless helps the app feel more accessible and "at home" on the platform.



> See http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4517


It "bugged" this reporter, but how to compare to the hundreds / thousands who remained silent, or perhaps benefited from being able to find the menu entry easily?