Re: theming

[David Kastrup <dak@gnu.org>]

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

> I have implemented the single frame behavior (it takes more than
> OneonOne to do that), for example.
> And if I understand correctly what themes are supposed to do, I
> cannot but agree with you that the currently planned collections of
> customization settings won't do the job for efforts to change the
> user interface (point 2 below). Themes make some headway though
> (point 1):
>
> 1. Aquamacs changes a lot of default customization settings, and it
>    also ensures that the user's actual customizations are noted as
>    such  and saved - by setting the 'standard-value property whenever
>    a  customization variable is set. That way we ensure that the user
>    can  still customize whatever - it's just the defaults that are
>    changed. A  lot of hooks are used, but they could be handled as
>    customization  variables.
> Making this process a bit easier, making it easier for the user to
> undo some of these new 'defaults'  by defining groups of
> customizations in themes would certainly be desirable.
>
> 2. However, over the last two or three months or so, Aquamacs has
>    come to do much more than that. It blatantly redefines and advises
>    functions, something which can only be undone by means of extra
>    customization variables that are checked by the new functions.

Those customization variables can have a default value that lets them
cause different behavior only when under the Aquamacs theme.

So I don't see this as a principal problem once themes work properly.

> In addition to that, we patch the c core and one or two of the .el
> files in order to either implement needed additional functionality
> or (on the Carbon port side) to modify functionality. In addition to
> that, several support files in the original package are modified,
> others added (converted manuals). [I make an effort to contribute
> changes, in particular bugfixes, where I see fit - it's not a
> competing fork.]

It is a competing fork in the manner that users are not able to make
it work like standard Emacs with minimal effort.  That means that the
Aquamacs distribution is only useful for people that don't prefer
standard Emacs behavior.

That's not a good state of affairs.  If Aquamacs were
theme-controlled, one could easily fold the whole kaboodle back into
the main core, and thus people, say, used to Aquamacs could get the
same behavior under Windows, and there would be no reason to
distribute competing binaries for MacOSX.

> CONCLUSION:
> We cannot realize your points with collections of customization
> settings. The changes are much more profound.

I still don't see what would prohibit those changes from being folded
back into Emacs once they are properly controlled by a theme.

> Therefore, there is another consideration that becomes more
> important: Makers of a distribution like Aquamacs would really need
> a stable, relatively bug-free release. We're shooting at a moving
> target otherwise.

With regard to theme support, fixing the target right now seems
incompatible with both stable (as it would need to get changed
afterwards, anyway) and relatively bug-free.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum