unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Thien-Thi Nguyen <ttn@glug.org>
Subject: Re: customization; std vs. personal libraries
Date: Thu, 12 May 2005 01:12:20 +0200	[thread overview]
Message-ID: <7e64xpbbmz.fsf@ada2.unipv.it> (raw)
In-Reply-To: mailman.4670.1115825568.2819.help-gnu-emacs@gnu.org

ken <gebser@speakeasy.net> writes:

> If thought
> through sufficiently [...]

probably the result would be straight elisp or the customize facility.

> Would it be so difficult to parse a configuration file for values to
> plug into a function?

parsing is no big deal.  the difficulty lies in synchronization w/ the
other methods (straight elisp and customize facility), handling session
changes, handling syntax and/or semantic errors, providing useful help,
etc.  note that the customize facility has precisely the same problems
to overcome; another configuration format adds more hair w/o resolving
these and in fact compounds the problems.

> Finally, an ascii configuration file would also provide a listing of
> variables pertinent to the user, perhaps helping to maintain the
> separation, addressed by Drew, between standard libraries and personal
> startup libraries.

i think under the ideals of GNU (four freedoms), such a separation would
in time (over many years over many people (but obviously not all ;-))
diminish, by dint of source code being able to more easily flow from
"standard" to "personal" and back to "standard".  this ideal requires
questioning of authority, understanding of the mechanisms used by the
author, application of those mechanisms on a personal scale (becoming an
author in one's own right), and publishing the personalized methods (if
one is inclined to share).

the framework for this social process requires a language, and although
elisp is not perfect (by far) for the purpose of personalizing emacs'
behavior, it is superior to declarative languages (like config files),
which fail to satisfy deep personalization the way fashion fails to
satisfy deep personalization.

granted, there are those for whom fashion is enough, whose luxury is to
be satisfied w/ a choice of pre-fabbed, post-angst, artful artifact.  i
can understand that point of view, and suspect that many who would be
able to realize the config-file approach you advocate, can also see its
merit.  however, to realize it you have to hack elisp.  and once you've
started down that path (why are you fighting it, btw?), people and ideas
you find along the way may change your original intent and motivation.

thi

  parent reply	other threads:[~2005-05-11 23:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3763.1115399076.2819.help-gnu-emacs@gnu.org>
2005-05-06 17:38 ` defcustom: changing from defvar - order of execution Stefan Monnier
2005-05-06 18:19   ` Drew Adams
2005-05-10 16:14 ` Per Abrahamsen
2005-05-10 18:32   ` Drew Adams
2005-05-11 15:08     ` customization; std vs. personal libraries ken
     [not found]     ` <mailman.4670.1115825568.2819.help-gnu-emacs@gnu.org>
2005-05-11 23:12       ` Thien-Thi Nguyen [this message]
2005-05-19 15:22       ` Per Abrahamsen
2005-05-19 17:55         ` Kevin Rodgers

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=7e64xpbbmz.fsf@ada2.unipv.it \
    --to=ttn@glug.org \
    /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.
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).