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
next 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
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=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.
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).