Re: Aquamacs distro for OS X like behavior

Re: Aquamacs distro for OS X like behavior

[LENNART BORGMAN]

----- Original Message -----
From: David Reitter <david.reitter@gmail.com>
Date: Friday, April 8, 2005 11:50 am
Subject: Re: Aquamacs distro for OS X like behavior

> On 8 Apr 2005, at 10:17, Johan Vromans wrote:
> 
> > Also, I think the number of widgets that emacs will use is rather
> > limited.
> 
> Using a UI toolkit represents a long-term commitment. Given that 
> UI 
> toolkits seem to live in a fashion-driven biosphere, it might be 
> interesting to consider alternatives.

wxWidgets is said to be 12 years old.

Aquamacs distro for OS X like behavior

[David Reitter]

Hi,

I would like to announce a new distribution for OS X, which we call 
'Aquamacs'. It's a ready-to-run application for OS X that combines the 
Carbon Emacs (a CVS build) with a range of packages and customizations 
from a number of people that all try to make Emacs behave more like a 
normal OS X application.

This includes keyboard shortcuts, a one-file-one-frame paradigm and a 
good-looking default font, plus other well-known add-ons that we 
consider standard on OS X.

The user-oriented description is at

	http://www.wordtech-software.com/Aquamacs.html

  and slightly more technical and opinionated introduction is provided 
here:

http://www.davids-world.com/archives/2005/04/aquamacs_an_ema.html

At this point, we consider the distribution experimental (it's version 
0.9). Kevin Walzer and I welcome your feedback.
Depending on whether people use it, we would work towards a 1.0. Source 
is provided in the .app bundle, except for what's in the CVS anyways.

-- Dave

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> I would like to announce a new distribution for OS X, which we call
> Aquamacs'. It's a ready-to-run application for OS X that combines
> the Carbon Emacs (a CVS build) with a range of packages and
> customizations from a number of people that all try to make Emacs
> behave more like a normal OS X application.

For starters, you could put up information about what you actually do
and include.  None of the referenced web sites bother to mention any
of the included packages.

> The user-oriented description is at
>
> 	http://www.wordtech-software.com/Aquamacs.html
>
>   and slightly more technical and opinionated introduction is provided
>   here:
>
> http://www.davids-world.com/archives/2005/04/aquamacs_an_ema.html
>
> At this point, we consider the distribution experimental (it's version
> 0.9). Kevin Walzer and I welcome your feedback.
> Depending on whether people use it, we would work towards a
> 1.0. Source is provided in the .app bundle, except for what's in the
> CVS anyways.

You make a big point out of berating the Emacs development team for a
lack of cooperation.  However, changes in user interface take a lot of
persuasion and preparative work as you can easily see if you follow
emacs-devel even superficially.  Emacs has a much longer history than
all currently "modern" (and conflicting) user interface guidelines.
Should one make people abandon Emacs that have been using it for 20
years, so that a newcomer will take an hour instead of half an hour
before giving up on it?

In addition, catering to the idiosyncrasies of a specific platform
like MacOSX is a lot of work if you want to keep Emacs fully
functional and reasonably consistent (where appropriate) across
platforms.

Given the amount of work that is needed for implementing and
harmonizing a platform specific port of Emacs, I can't help but notice
that your rants about Emacs developers at least to me appear somewhat
disproportionate with the amount of involvement I seem to remember
from you on this list.  So I recommend that you replace them with
actually mentioning what packages you are including in your offering,
and maybe thinking about how you could constructively help Emacs user
interface design while keeping in mind that there are more platforms
than just MacOSX around: this means that one has to make good choices
about where and how to modularize design decisions for a platform.

For the sake of consistency, it might be an idea at some point of time
to have, at least for a limited time period, a single person being
responsible for user interface decisions.  But this person needs to be
at least acquainted with all major user interfaces, and it would need
to have reasonably good contacts with active developers for all of
them.  I have actually played with the thought of offering to do that,
but my style of communication is likely to cause more permanent damage
than good in a sensitive area, and I don't have the time available to
invest myself that would be required for somebody taking the lead in
some area, even if just for making him appear a mostly uncontentious
necessary evil.

Anyway: interface work is hard work, and "let us do everything the
Apple way" is not going to cut it for a number of other platforms, so
in the core Emacs development it is important to keep track of how to
make it possible to do things the Apple, Windows, GNOME, whatever way
reasonably well without losing sight of the Emacs way.

If you want to invest your time in that area cooperatively, it
certainly would be appreciated, and the results would probably be
beneficial to Emacs at large, but you have to realize that moving
Emacs as a whole, while the most effective way in the long run, can be
lots of hard work and frustrating at times.  Of course, it is easier
to rant about how hard it would be instead of trying, but it probably
does not lead anywhere much.

Anyway, for the sake of projects of mine, I am glad that there at last
seems to be a precompiled recent Aqua version of the CVS Emacs around
again.

Without any usefully available information about what packages and
detailed changes from where have gone into it, I still can't recommend
it or give out instructions about how software is probably going to
get installed there.  So I recommend that you fix at least that
deficiency.  All other OSX compilations, outdated as they may be, at
least mention what they include into the package.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[David Reitter]

Hi David,

thanks for your friendly comments.

You are of course very right in that we should list the packages that 
we include in the distribution. We haven't done so as we have included 
a lot of things from people's publicly available .emacs files in 
addition to a number of large customizations, e.g. those from Drew 
Adams. We will include a list pretty soon though.

Please note that I didn't complain a lot about a lack of cooperation or 
attack anyone, and I also didn't suggest to make the main-stream Emacs 
more OS X like ("let us do everything the Apple way").  If possible, I 
would very much like to see that Emacs /allows/ us to customize its UI 
for a particular environment.

We can certainly help if the friendly people handling the Mac port 
would like to pick up some of the UI elements, such as the keyboard 
shortcuts, which probably do not conflict with other functionality. I 
have submitted bug reports on other UI problems, such as the scrollbars 
(not fixed), or a little patch for the file selector (fixed) already.

Best
David

Re: Aquamacs distro for OS X like behavior

[Stefan Monnier]

> If possible, I would very much like to see that Emacs /allows/ us to
> customize its UI for a particular environment.

I think we all agree about it.

The mainstream Emacs will never be like the one you distribute because an
important consideration for it is that it should behave like Emacs
on other platforms, as opposed to your distribution which places more
emphasis on having it behave like other apps on Mac OS X.

But it's still a good goal to try and minimize the difference between
the two.  At least, to the point where your distribution is not a full
Emacs install but only an add-on.  An important consideration here is that
the same Emacs install should be able to accomodate users who want MacOSX
behavior and users who want Emacs behavior.


        Stefan

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> If possible, I would very much like to see that Emacs /allows/ us
>> to customize its UI for a particular environment.
>
> I think we all agree about it.
>
> The mainstream Emacs will never be like the one you distribute
> because an important consideration for it is that it should behave
> like Emacs on other platforms, as opposed to your distribution which
> places more emphasis on having it behave like other apps on Mac OS
> X.

There is considerable leeway in those goals.  For example, different
file selection dialogs and similar are quite common, and in fact, the
whole widgetry stuff (like customize and co) could be made to make use
of the native widgets where available.

Emacs already tends to blend quite better with its environment than
XEmacs does (which looks like, well, XEmacs everywhere), and this is
not a mistake, in my opinion.

> But it's still a good goal to try and minimize the difference
> between the two.  At least, to the point where your distribution is
> not a full Emacs install but only an add-on.  An important
> consideration here is that the same Emacs install should be able to
> accomodate users who want MacOSX behavior and users who want Emacs
> behavior.

Well, we do have something like customization themes IIRC, but I don't
know their extent and how they are used.  If a whole set of defaults
were to be changed by a single theme (and could be changed back at
will), then an out-of-the-box configuration that was different on
MacOSX would be quite tolerable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[David Reitter]

On 4 Apr 2005, at 18:47, David Kastrup wrote:

>
> There is considerable leeway in those goals.  For example, different
> file selection dialogs and similar are quite common, and in fact, the
> whole widgetry stuff (like customize and co) could be made to make use
> of the native widgets where available.

 From a UI and an OS X perspective, customization buffers should 
definitely go into proper dialogues with native widgets.

>
> Well, we do have something like customization themes IIRC, but I don't
> know their extent and how they are used.  If a whole set of defaults
> were to be changed by a single theme (and could be changed back at
> will), then an out-of-the-box configuration that was different on
> MacOSX would be quite tolerable.

I don't know if an out-of-the-box configuration for the default Emacs 
is needed - the idea of a distribution like what we demonstrate with 
Aquamacs might already do the job. People with other needs - a 
cross-platform compatible Emacs - will then be happy to use the 
'conservative' version instead.

I see a trend towards the first - UI integration - because it's more 
comfortable when you use a lot of applications (and people use more 
applications, not less), and there has been a great uptake on mobile 
devices: people use laptops much more than they used to (say, 7 years 
ago), and people don't switch from one system to another as often. Of 
course, individual mileage will vary!

Either way, merely using a 'theme' with the on-board means, for example 
to make customization buffers look different, will IMHO not tweak the 
application UI enough. A user interface is more than just pretty 
buttons and a choice of colors. If you look at the way themes work in 
GNOME / KDE, you'll find huge emphasis on the graphics, and only little 
theme-defined behavior and pretty much no theme-defined layout.

Successful OS X software pretty much always uses the native user 
interface. Even though OS X has superb Java integration (at least for 
not-quite-cutting-edge Java versions), we don't see many wide-spread 
Swing based applications. Similarly, the XUL based browser versions 
from Mozilla aren't as popular as Safari and Camino - even though they 
offer good or better functionality.

Consequently, I'm arguing for native widgets wherever possible. For a 
new project - or one with less tradition and less importance, there is 
stuff like wxWidgets. In this case, I would be grateful if someone 
would implement more Carbon (or Cocoa) based UI stuff, and if better 
internal interfaces existed, for example to handle scrollbars 
correctly. This is stuff only developers experienced with Emacs code - 
yes, you! - can implement.

- Dave

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

David Reitter <david.reitter@gmail.com> writes:

> On 4 Apr 2005, at 18:47, David Kastrup wrote:
>
>> There is considerable leeway in those goals.  For example,
>> different file selection dialogs and similar are quite common, and
>> in fact, the whole widgetry stuff (like customize and co) could be
>> made to make use of the native widgets where available.
>
>  From a UI and an OS X perspective, customization buffers should
>  definitely go into proper dialogues with native widgets.

I don't think this is OS X specific.  Mapping hierarchical widgets to
native constructs would be a lot of work.  Right now only atomic
widgets like the file selection dialog are, if at all, available.  I
think that some consensus, even if I can't remember this being
discussed before, could be achieved that this would be generally
desirable at least where the actions were mouse-induced: present
people with familiar interfaces.  There are drawbacks, like not being
able to use the power of Emacs' keyboard commands to manipulate
entries, but for people annoyed by that, there would always be the
possibility to configure the Emacs text widgets as default.

>> Well, we do have something like customization themes IIRC, but I
>> don't know their extent and how they are used.  If a whole set of
>> defaults were to be changed by a single theme (and could be changed
>> back at will), then an out-of-the-box configuration that was
>> different on MacOSX would be quite tolerable.
>
> I don't know if an out-of-the-box configuration for the default
> Emacs is needed - the idea of a distribution like what we
> demonstrate with Aquamacs might already do the job.

If you change options with setq, it becomes more troublesome to
customize them than if a theme was available.  Also it has the problem
that people used to NTEmacs can't easily get the same behavior from
Aquamacs and the other way round.  Shipping all Emacs versions with
both an NTEmacs and an Aquamacs customization theme would mean that
you get something set up to match your platform best as delivered, but
if you are already acquainted to the defaults of a different platform,
a single customization will turn your NTEmacs into an Aquamacs and the
other way round.

> Either way, merely using a 'theme' with the on-board means, for
> example to make customization buffers look different, will IMHO not
> tweak the application UI enough. A user interface is more than just
> pretty buttons and a choice of colors.

Customization themes in Emacs have nothing to do with pretty buttons
and choice of colors.  They are simply a single name for a complete
set of customized variable defaults.

[Other ramplings about "theme" removed]

> Consequently, I'm arguing for native widgets wherever possible. For
> a new project - or one with less tradition and less importance,
> there is stuff like wxWidgets. In this case, I would be grateful if
> someone would implement more Carbon (or Cocoa) based UI stuff, and
> if better internal interfaces existed, for example to handle
> scrollbars correctly. This is stuff only developers experienced with
> Emacs code - yes, you! - can implement.

This is stuff only developers experienced with the native scrollbars -
yes, you! - can implement.

Basically this needs knowledge of both the native widgets as well as
Emacs.  Your point of view is that other Emacs developers should be
forced to learn the details of the widgets of your platform.  Are you
going to buy me a Mac and developer information for that?  My point of
view is that it makes more sense if the Mac developers learn the
details of Emacs.  At least, both code and documentation for Emacs are
freely available, so you need not stumble around in the dark.  And you
can actually test what you are playing with, having a Macintosh
available.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[Stefan Monnier]

> I don't know if an out-of-the-box configuration for the default Emacs is
> needed - the idea of a distribution like what we demonstrate with Aquamacs
> might already do the job.  People with other needs - a cross-platform
> compatible Emacs - will then be happy to use the 'conservative'
> version instead.

It does the job, but it's more work for you.  And having two slightly
different distributions is a pain in the rear.  Better to have one
distribution plus an add-on.  You can bundle them of course, but the point
is that I want to be able to install your Aquamacs (for other people) and
still use it as a "normal Emacs" myself.

> I see a trend towards the first - UI integration - because it's more

We're in favor of UI integration as well, mind you.  We just don't have the
manpower/experience/time/will to do more of it ourselves.  Note that UI
integration is different from issues such a default keybindings, etc...

> Either way, merely using a 'theme' with the on-board means, for example to
> make customization buffers look different, will IMHO not tweak the
> application UI enough.

You're confused about what is meant by "theme" in the context of Custom.
It's new in Emacs-CVS and is still very poorly supported/documented, but the
basic idea is that you can take your .emacs and say "here is my
DavidReitterTheme".

> Consequently, I'm arguing for native widgets wherever possible.

You're preaching to the choir.  We're using native menus, native scrollbars,
native tooltips, ...

> In this case, I would be grateful if someone would implement
> more Carbon (or Cocoa) based UI stuff, and if better internal interfaces
> existed,

So would we.

> for example to handle scrollbars correctly.

Please report any complaint you have against the scrollbar with
M-x report-emacs-bug.


        Stefan

Re: Aquamacs distro for OS X like behavior

[David Reitter]

[-- Attachment #1.1: Type: text/plain, Size: 1180 bytes --]


> You're confused about what is meant by "theme" in the context of  
> Custom.
> It's new in Emacs-CVS and is still very poorly supported/documented,  
> but the
> basic idea is that you can take your .emacs and say "here is my
> DavidReitterTheme".

Oh, then I see - well that's exactly what I would want. That would  
allow us to integrate something like an OS X theme without mandating  
it.  If such a theme would be supplied with a main version and switched  
on by default on OS X, I suppose one would want it to be well-tested.  
Even though the collection has been around for a while, I feel that we  
need some more feedback from users. We're getting this now - with some  
problems being genuinely due to our distribution.

>> for example to handle scrollbars correctly.
>
> Please report any complaint you have against the scrollbar with
> M-x report-emacs-bug.

I have reported this in various places, for example on  
emacs-pretest-bugs here:

http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/ 
msg00110.html

and Steven Tamm and Yamamoto Mitsuharu have been made aware of it a  
while ago.
I have no plans to report the same problem again :-)

-- Dave



[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2400 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Aquamacs distro for OS X like behavior

[Stefan Monnier]

>>> for example to handle scrollbars correctly.
>> Please report any complaint you have against the scrollbar with
>> M-x report-emacs-bug.
> I have reported this in various places, for example on
> emacs-pretest-bugs here:

> http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-03/ msg00110.html

> and Steven Tamm and Yamamoto Mitsuharu have been made aware of it a  while
> ago.  I have no plans to report the same problem again :-)

Sorry I missed it.  I have no knowledge of Carbon Emacs, but I do have a lot
of experience trying to get non-Xaw scrollbars to work with Emacs.
So I can answer some of the issues you raise in your post:

> Under OS X, Emacs behaves very strangely with regard to the scrollbars and
> sliders. When you just click on a slider without moving it (after you've
> scrolled to the middle of the document), you will see that the text
> scrolls right away, often far beyond the document.  Intended behavior
> would be not to do anything.

The description of the behavior is not sufficiently precise for me to be
sure, but it looks like a genuine bug.  I'm not sure what you mean by "far
beyond the document", tho.

> When the slider is moved, scrolling looks fine at first.  However, I can
> then move beyond the document.

You mean you can scroll til the point where the very end of the document is
at the very top of the window.  That's normal Emacs behavior.  And there are
sound technical reasons why it's done this way.

> Good behavior under OS X would be to stop scrolling just when one line
> after the document is located at the bottom end of the screen
> (i.e. frame).

Other than being slightly different, in what case is it a problem?

The behavior you want is a behavior I find inconvenient in many cases
(e.g. I find it unpleasant to type text on the very last line of a window,
and I sometimes like to move the text higher up in the window (even if it's
at the bottom of the buffer) so I can align it on screen with some other
window's text).

I sometimes actually even wish the same would hold for the beginning of the
buffer (being able to place (point-min) at the bottom of the window).

> Also, during scrolling, the size of the slider changes. That should never
> be, as the size indicates the length of the document in relation to the size
> of the whole scrollbar.

That's exactly what it represent: the ratio slider/total is the same as the
ratio shownchars/buffercharsize.  But depending on where you are in the
buffer the window will not always show the same number of chars, so the size
of the slider changes accordingly.

In order for the slider to have a fixed size independent from the position
in the buffer it would have to show "shownpixels/bufferpixelsize".
Problem is that bufferpixelsize is very costly to compute so we currently
can't do that.

> That's an old paradigm! Consequently, the size of the slider only changes
> if the document size changes.

"Old paradigm" is not an argument I care about.  I still haven't heard of
any scenario where the current behavior causes an actual problem.  The worst
I've heard is that users are surprised and then go on with their life.
I've never heard of any user actually getting confused by it.

I'm not claiming that the current behavior is a feature, but I'm just saying
that the cost of a fix is just too high compared to the very minor
improvement it would bring.  Maybe the situation will be different ten years
from now, but before then I don't see things changing on this front.

BTW, in Emacs-CVS you can actually "try it out" by calling
`count-screen-lines'.  On reasonably large buffers, it takes a while.
Also the bufferpixelsize can be changed by font-lock fontification, so we'd
have to throw away jit-lock and go back to plain font-lock.

> Furthermore, clicking on one of the little arrows doesn't result in an
> immediate scroll action (one line). It only scrolls when the mouse button is
> released. Good behavior would be to scroll as soon as the button is down,
> and then scroll again (line by line, but continuously), after a short
> delay -- just like pressing a key will repeat that letter on and on after
> a delay.

That looks like a genuine bug.


        Stefan

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

     From a UI and an OS X perspective, customization buffers should 
    definitely go into proper dialogues with native widgets.

Most cases, perhaps nearly all, would be easily handled with those
native widgets.  But it might be hard to make this support everything
that Emacs customizations actually do.

Meanwhile, we could afford to maintain this for one set of widgets,
such as GTK.  But if the idea were to use the native widget set of
every system, you're talking about a tremendous amount of work.

    Successful OS X software pretty much always uses the native user 
    interface.

The purpose of Emacs is to enhance the GNU operating system of which
it is part, and thus to contribute to the liberation of computer users
from non-free software.

Mac OS is a non-free operating system.  Viewed amorally, as mere
technology, it may be useful; but it is fundamentally unethical.
Our goal is to replace it with free software, not to enhance it.
To produce "successful OS X software" is a distraction from the goal.

Re: Aquamacs distro for OS X like behavior

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>

> Meanwhile, we could afford to maintain this for one set of widgets,
> such as GTK.  But if the idea were to use the native widget set of
> every system, you're talking about a tremendous amount of work.

What about wxwidgets?

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    What about wxwidgets?

I don't know anything about them technically, but if they make
the job easier and they are free software, there is no theoretical
reason we could not use them.

However, our priority should be GTK, I think.

Re: Aquamacs distro for OS X like behavior

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     What about wxwidgets?
>
> I don't know anything about them technically, but if they make
> the job easier and they are free software, there is no theoretical
> reason we could not use them.
>
> However, our priority should be GTK, I think.

wxwidgets take GTK+ as one of their backends, so one does not exclude
the other.  However, AFAICS wxwidgets supports just C++.  I don't
think that it would make sense to move Emacs to C++.

Also they are third-party software.  Basing Emacs ports to rely on
them in favor of other approaches would seem like a strategical risk
to me.  Such a commitment, I think, would require some securities.

Anyway, given the C++ problem, I don't think that we need to think
about that.

If somebody wants to invest time taking a look how to combine Emacs
with xwidgets without having to replace our build and memory
allocation infra structure, that's fine.  But I can't see it as a
viable porting path at the moment.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    wxwidgets take GTK+ as one of their backends, so one does not exclude
    the other.  However, AFAICS wxwidgets supports just C++.  I don't
    think that it would make sense to move Emacs to C++.

Yes, that is a pretty severe drawback.  Thanks for analyzing the issue.

Re: Aquamacs distro for OS X like behavior

[Lennart Borgman]

----- Original Message ----- 
From: "Richard Stallman" <rms@gnu.org>
To: "David Kastrup" <dak@gnu.org>
Cc: <lennart.borgman.073@student.lu.se>; <monnier@iro.umontreal.ca>;
<david.reitter@gmail.com>; <emacs-devel@gnu.org>
Sent: Thursday, April 07, 2005 8:27 PM
Subject: Re: Aquamacs distro for OS X like behavior


>     wxwidgets take GTK+ as one of their backends, so one does not exclude
>     the other.  However, AFAICS wxwidgets supports just C++.  I don't
>     think that it would make sense to move Emacs to C++.
>
> Yes, that is a pretty severe drawback.  Thanks for analyzing the issue.

I wrote to wx-users@lists.wxwidgets.org and asked and got this promising
answer (and some other too):

> Can wxWidgets be used from C?

You might want to have a look at wx.NET (the C# bindings
for wxWidgets) which have (or at least used to have)
intermediate C-bindings.

  mvh,

   Robert Roebling

Re: Aquamacs distro for OS X like behavior

[Johan Vromans]

"Lennart Borgman" <lennart.borgman.073@student.lu.se> writes:

>> Yes, that is a pretty severe drawback.  Thanks for analyzing the issue.
>
> I wrote to wx-users@lists.wxwidgets.org and asked and got this promising
> answer (and some other too):

Also, I think the number of widgets that emacs will use is rather
limited.

-- Johan

Re: Aquamacs distro for OS X like behavior

[David Reitter]

On 8 Apr 2005, at 10:17, Johan Vromans wrote:

> Also, I think the number of widgets that emacs will use is rather
> limited.

Using a UI toolkit represents a long-term commitment. Given that UI 
toolkits seem to live in a fashion-driven biosphere, it might be 
interesting to consider alternatives.

How about documenting interfaces for the most commonly used functions, 
starting with tasks where a good GUI would be helpful? For example, one 
could define a structured language to serialize customization settings, 
which could then be parsed by little external modules - written by the 
community or the port people in order to implement system-native 
behavior. This would not preclude the use of the default behavior, i.e. 
customization buffers. I understand (and I know very little about the 
technical side of emacs!) that custom options have such an API anyways 
- it would come down to defining a serialization (to write stuff into a 
file and read it out again) and an update protocol.

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    How about documenting interfaces for the most commonly used functions, 
    starting with tasks where a good GUI would be helpful? For example, one 
    could define a structured language to serialize customization settings, 
    which could then be parsed by little external modules - written by the 
    community or the port people in order to implement system-native 
    behavior. This would not preclude the use of the default behavior,

This sounds like a research project to me.  It might be an interesting
research project, for whoever is minded to do research in this area.

Re: Aquamacs distro for OS X like behavior

[Richard Stallman]

    Emacs already tends to blend quite better with its environment than
    XEmacs does (which looks like, well, XEmacs everywhere), and this is
    not a mistake, in my opinion.

To the extent that we can make Emacs fit the general GUI environment
without altering the core features of Emacs, it is a usually good
thing to do so.  I would be against altering keyboard keys, except
in very narrow was such as swapping DEL and BS.  And changing the main
mouse commands such as Mouse-1 between systems seems like a bad idea too.

Re: Aquamacs distro for OS X like behavior

[Aidan Kehoe]

 Ar an ceathrú lá de mí Aibréan, scríobh David Kastrup: 

 > [...] Should one make people abandon Emacs that have been using it for 20
 > years, so that a newcomer will take an hour instead of half an hour
 > before giving up on it?

That’s a false dichotomy; people who have been using some form of Emacs for
twenty years are informed enough to be able to configure their way around
the new defaults. New users, very much less so.

 > In addition, catering to the idiosyncrasies of a specific platform like
 > MacOSX is a lot of work if you want to keep Emacs fully functional and
 > reasonably consistent (where appropriate) across platforms.

Certainly, but most of the work should be up-front--assuming stuff like
cua-mode keeps respecting the Apple key--and they’re volunteering to do
it. And, given that Andrew Choi is gone, and the Carbon port is very much
alive, it seems there is and will be a decent userbase prepared to
support GNU Emacs on that platform. 

 > [snipping stuff on the GUI development of GNU Emacs and the package list
 > of this package, neither of which I have much interest in.]

-- 
“I, for instance, am gung-ho about open source because my family is being
held hostage in Rob Malda’s basement. But who fact-checks me, or Enderle,
when we say something in public? No-one!” -- Danny O’Brien

Re: Aquamacs distro for OS X like behavior

[Eli Zaretskii]

> From: Aidan Kehoe <kehoea@parhasard.net>
> Date: Mon, 4 Apr 2005 20:25:20 +0200
> Cc: David Reitter <david.reitter@gmail.com>, emacs-devel@gnu.org
> 
>  > [...] Should one make people abandon Emacs that have been using it for 20
>  > years, so that a newcomer will take an hour instead of half an hour
>  > before giving up on it?
> 
> That's a false dichotomy; people who have been using some form of Emacs for
> twenty years are informed enough to be able to configure their way around
> the new defaults.

That depends on the amount of configuring around the defaults.  If
that amount gets too large, I, for one, would be very unpleased.  I
use Emacs for productivity, not for the dubious pleasure of wasting my
time hunting down new defaults that make Emacs behave contrary to my
expectations.

Please also don't forget that quite a few veteran Emacs users
routinely work with several different Emacs versions on different
machines, so having too many differences between versions means those
Emacs veterans will have hard time crafting customizations that work
with all of the versions.