unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Emanuel Berg <moasen@zoho.com>, help-gnu-emacs@gnu.org
Subject: RE: About how misspelled word are displayed
Date: Fri, 12 May 2017 10:32:36 -0700 (PDT)	[thread overview]
Message-ID: <8778c766-ce0a-4b42-939d-96b0f0b49a82@default> (raw)
In-Reply-To: <yw.86shkam469.fsf@zoho.com>

> > Just use a separate `custom-file'.
> > Customize does not _want_ to fiddle with your
> > init file, but if you do not tell it another
> > file to use instead (`C-h v custom-file')
> > then your init file wins.
> >
> > For simple stuff, yes, you can code such
> > customizations by hand. But why do that
> > (except to practice and learn more, which
> > can be a fine reason)?
> >
> > And for stuff that is not so simple, it is
> > better to rely on Customize. It knows the
> > customize code better than you/we do.
> 
> OK, so when it gets not so simple, one should
> not rely on Customize anymore. But if one
> cannot solve so simple things without relying
> on Customize, how can one be expected to solve
> things that are not so simple suddenly?

Perhaps you misread what I wrote?

1. I'm talking only about customizations that Customize
is for, not arbitrary Lisp code, key bindings, etc.

2. For user options and faces, which is what Customize
is for, it is precisely those whose definitions are _not_
so simple that it is especially helpful to use Customize
and not just hand-code assignments etc.

For both simple and complex defcustoms and deffaces you
_can_ rely on Customize.  It is for the complex ones
that it can be especially helpful to use Customize (or
its functions).

> Apart from the principle, Customize is not
> easier than to put a couple of lines of code
> into a text file. 

I didn't argue about what someone might find easier but
about what is more prudent (sure).

I don't find it hard to "put a couple of lines of code
into a text file."  But I also don't find it hard to use
the Customize UI.  (It's not the best UI, but I can use
it to get the job done - and reliably so.)

If you really want to set user options or faces with Lisp
then it is better to use the `custom*' functions designed
for that.  You can do everything by Lisp that the Customize
UI can do, in terms of setting preferences.  But not if you
just toss around setq and modify-face.

It is particularly options, not faces, that can be
problematic if you don't use the `custom*' functions,
because of defcustom :set and :initialize triggers,
as I mentioned.

> Customize is much more complicated and I don't want to
> ever rely on complicated stuff, and certainly not for
> doing simple things.

If you are not the one who defined a given defcustom,
and if that defcustom uses a keyword such as :set, then a
complicated beast has likely been created for you already.

If you try to tame that beast without taking its nature
into account (e.g., using just `setq') you can find
yourself surprised.

You can even get into trouble by not respecting the
defcustom :type.  Things might be OK in some contexts
but not in others, and you might well have trouble
figuring out just what is wrong.

Knowing this won't stop you from doing whatever you
want, of course. ;-)

But if you're really interested in using Lisp to set
options or faces then you might want to get to know
function `customize-set-variable' (or `custom-set-faces'
or `custom-set-variables'), if you are not already
familiar with it.  Or not.



  reply	other threads:[~2017-05-12 17:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-12  9:49 About how misspelled word are displayed Angelo Graziosi
2017-05-12 13:09 ` Kaushal Modi
2017-05-12 14:07   ` Angelo Graziosi
2017-05-12 14:14     ` tomas
2017-05-12 14:27       ` Emanuel Berg
2017-05-12 15:16         ` Drew Adams
2017-05-12 16:27           ` Emanuel Berg
2017-05-12 17:32             ` Drew Adams [this message]
2017-05-12 18:00               ` Emanuel Berg
2017-05-12 21:15                 ` tomas
2017-05-12 21:28               ` N. Raghavendra
2017-05-12 22:08                 ` Drew Adams
2017-05-13 14:15                   ` N. Raghavendra
2017-05-13 14:59                     ` Emanuel Berg
2017-05-13 15:07                       ` Emanuel Berg
2017-05-13 15:22                         ` Emanuel Berg
2017-05-13 15:34                       ` N. Raghavendra
2017-05-13 15:54                         ` Emanuel Berg
2017-05-13 17:59                     ` Drew Adams
2017-05-14 13:07               ` N. Raghavendra
2017-05-12 19:30   ` Angelo Graziosi
2017-05-12 20:34     ` Drew Adams
2017-05-12 20:41       ` Drew Adams
2017-05-12 22:14         ` Angelo Graziosi
2017-05-12 23:42           ` Emanuel Berg
2017-05-13  0:22             ` John Mastro
2017-05-13  9:53               ` Emanuel Berg
2017-05-12 21:07       ` Emanuel Berg
2017-05-12 19:57   ` Angelo Graziosi
2017-05-12 20:56     ` Emanuel Berg

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=8778c766-ce0a-4b42-939d-96b0f0b49a82@default \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=moasen@zoho.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.
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).