all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Phillip Lord <p.lord@russet.org.uk>
Subject: Using custom as a type checker:- ramble
Date: 25 Mar 2003 18:22:54 +0000	[thread overview]
Message-ID: <vfr88vpapt.fsf@rpc71.cs.man.ac.uk> (raw)




One of the really nice things about custom is that it provides a
degree of type checking for lisp variables. This is particularly nice
for settings variables, as these are often easy to get wrong, if you
do not know the underlying code base. Should you have a int? Or a
string? Or a list? Or what. Custom gets around these problems by
constraining the user at the time they change the value. 

More over custom is quite clever about this. If you set the variable
up elsewhere, or a variable changes its type, custom displays
"mismatch" in the custom window. 

However, custom has some disadvantages over the old "type lots of
(setq) forms into your .emacs". It's harder to comment settings 

So for instance....

;;this variable controls completion. i never want to edit
;;.class files so i may as well ignore them
(add-to-list 'completion-ignored-extensions ".class" )


Also I can look at a package, and see just those variables I have need
to change. I can grep for the changes I have made. I can version my
changes more easily, by sticking my .emacs into cvs. 

And finally I can do fairly complex conditional logic, so ....

if I am using emacs over X, onto a small screen, set
compilation-window-height to 4, else make it big.

All hard to do in custom. 


Now what I would want to do is combine the two. So have something like


(custom-setq compilation-window-height)

Where custom-setq would use the custom mechanism to set a variable. If
it was of the wrong type (so would display "mismatch" in the dialog),
then at this point an error would be signalled. This way I would have
most of the advantages of both systems. I could do conditional logic,
I could comment, I could grep, and so on. But I would also get good
"type safety."

Now I realise that this is not what custom was intended for, but a lot
of the information that its necessary for it to work has already been
put into all the emacs packages. It seems to me that this could be
very useful indeed. 

Does this make any sense?

Cheers

Phil

             reply	other threads:[~2003-03-25 18:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-25 18:22 Phillip Lord [this message]
2003-03-26 16:17 ` Using custom as a type checker:- ramble Stefan Monnier
2003-03-26 16:59   ` Phillip Lord
2003-03-26 19:14     ` Stefan Monnier
2003-03-27 10:25       ` Phillip Lord
2003-03-27 16:32         ` Stefan Monnier
2003-03-27 17:11           ` Phillip Lord

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

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

  git send-email \
    --in-reply-to=vfr88vpapt.fsf@rpc71.cs.man.ac.uk \
    --to=p.lord@russet.org.uk \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.