unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
Subject: RE: theming
Date: Thu, 7 Jul 2005 10:36:10 -0700	[thread overview]
Message-ID: <DNEMKBNJBGPAOPIJOOICCEGHCKAA.drew.adams@oracle.com> (raw)
In-Reply-To: <f7ccd24b05070706313a1c314a@mail.gmail.com>

    Much as I like the idea of prepackaged distributions for normal,
    non-developer users, the problem I see with many "big" Emacs projects
    (like TinyTools, CEDET, JDEE, etc) is that they are much of an
    all-or-nothing. You install one of them, you are no longer in Emacs,
    but someone's pet idea of what Emacs should look like (yeah, even if
    they have a ton or two of customization options). Nothing bat per se,
    but I already have my pet Emacs and we've learnt to live with each
    other, thanks ;-)

    Being themeable is necessary. Being non-monolithic is fundamental

I agree 100%. This is something that would really, really help Emacs - well
after the release.

I'm guilty, myself, of having come up with such monolithic customization
packages (with and without using "Custom"). I try to update those libraries
now (when I have time), so that the result is less monolithic and plays
better with, for instance, Custom.

(One problem is, I think, that there is a natural evolution from a set of
individual .emacs settings toward a library that others can use flexibly.
I've mentioned this before. A set of guidelines for moving from the one to
the other would help.)

Anyway, I think that a general mechanism for themes that also promotes
modularity (vs monoliths) would be a great thing to have. The current Custom
facility is essentially geared toward the individual user (it updates his
custom-file), whereas what we're talking about here are packages that
customize a lot of things at once for any set of users.

And people are right to point out that "the solution" should speak not only
to Customization stuff (variables & faces), but to key bindings too. And it
might need to provide for loading and unloading redefinitions of standard
functions, as well as dealing with advice flexibly.

I don't think the task would be easy to come up with a good, general set of
theming constructs that would let people write modular, non-monolithic
custom versions of Emacs. But it would be great if it existed.

  parent reply	other threads:[~2005-07-07 17:36 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-06 23:58 Sorting of directories in dired Lennart Borgman
2005-07-07  0:13 ` Juanma Barranquero
2005-07-07  6:49   ` Lennart Borgman
2005-07-07  8:02     ` Juanma Barranquero
2005-07-07  8:28       ` Edward O'Connor
2005-07-07 10:11         ` Juanma Barranquero
2005-07-07 12:24           ` David Kastrup
2005-07-07 10:53         ` theming (was: Sorting of directories in dired) John S. Yates, Jr.
2005-07-07 12:17           ` theming Lennart Borgman
2005-07-07 13:31             ` theming Juanma Barranquero
2005-07-07 13:50               ` theming Lennart Borgman
2005-07-07 14:00                 ` theming Juanma Barranquero
2005-07-07 14:24                   ` theming Lennart Borgman
2005-07-07 17:36               ` Drew Adams [this message]
2005-07-08  4:36               ` theming Richard M. Stallman
2005-07-08 11:05             ` theming John S. Yates, Jr.
2005-07-07 12:22           ` theming (was: Sorting of directories in dired) David Reitter
2005-07-07 14:20             ` theming David Kastrup
2005-07-08 12:38               ` theming David Reitter
2005-07-08 14:27                 ` theming Stefan Monnier
2005-07-08 22:01                   ` theming Richard M. Stallman
     [not found]             ` <m1DqbHY-0004RAC@rattlesnake.com>
2005-07-07 18:59               ` theming (was: Sorting of directories in dired) David Reitter
2005-07-07 19:11             ` David Reitter
2005-07-10  5:19             ` Richard M. Stallman
2005-07-10  5:19           ` Richard M. Stallman
2005-07-07 20:37         ` Sorting of directories in dired Eli Zaretskii
2005-07-08  1:12         ` Bill Wohler
2005-07-07 16:43     ` Drew Adams
2005-07-07 21:08       ` Eli Zaretskii
2005-07-07 20:35         ` Drew Adams
2005-07-07 22:41           ` Eli Zaretskii
2005-07-07 22:53             ` Drew Adams
2005-07-08 10:58               ` Eli Zaretskii
2005-07-08 17:40             ` Richard M. Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DNEMKBNJBGPAOPIJOOICCEGHCKAA.drew.adams@oracle.com \
    --to=drew.adams@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).