Using custom as a type checker:- ramble

Using custom as a type checker:- ramble

[Phillip Lord]

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

Re: Using custom as a type checker:- ramble

[Stefan Monnier]

>>>>> "Phillip" == Phillip Lord <p.lord@russet.org.uk> writes:
> 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."

What I would much rather have is a way to load a normal .emacs
and automatically have all the `setq's checked as above.  The
checking could also include obsolescence and things like that.

I.e. I don't want to change the .emacs code at all, but I'd like
to have a more-or-less generic way to add helpful analysis
of the code so as to give useful information to the user about
suspicious customizations.


        Stefan

Re: Using custom as a type checker:- ramble

[Phillip Lord]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

>>>>> "Phillip" == Phillip Lord <p.lord@russet.org.uk> writes:
  >> 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."

  Stefan> What I would much rather have is a way to load a normal
  Stefan> .emacs and automatically have all the `setq's checked as
  Stefan> above.  The checking could also include obsolescence and
  Stefan> things like that.

  Stefan> I.e. I don't want to change the .emacs code at all, but I'd
  Stefan> like to have a more-or-less generic way to add helpful
  Stefan> analysis of the code so as to give useful information to the
  Stefan> user about suspicious customizations.

Well I would agree that this would be preferable. 

What worries me, though, is the complexity of this task. I don't know
about you, but my .emacs (and other files that I call from .emacs) is
huge, and often complex, so interpreting this would be complex. Adding
a "custom-setq" function would potentially be very simple. 

Although I guess you would also need "custom-add-to-list". And then
"custom-add-hook". And so on. By which time I gets a lot less simple,
and would also require a lot of recoding of existing .emacs'.

Hmmm.

Phil

Re: Using custom as a type checker:- ramble

[Stefan Monnier]

> > What I would much rather have is a way to load a normal
> > .emacs and automatically have all the `setq's checked as
> > above.  The checking could also include obsolescence and
> > things like that.
> 
> > I.e. I don't want to change the .emacs code at all, but I'd
> > like to have a more-or-less generic way to add helpful
> > analysis of the code so as to give useful information to the
> > user about suspicious customizations.

> Well I would agree that this would be preferable. 

> What worries me, though, is the complexity of this task. I don't know
> about you, but my .emacs (and other files that I call from .emacs) is
> huge, and often complex, so interpreting this would be complex. Adding
> a "custom-setq" function would potentially be very simple. 

It should be possible to get the desired result without implementing
an elisp interpreter in elisp, but instead by temporarily rebinding
`setq' as a macro (and things like that).

Another alternative is to put the checking into the byte-compiler
(which already takes care of traversing elisp code) and then
byte-compile the .emacs file (not for speed but for sanity checks).
This might be the best option.


        Stefan

Re: Using custom as a type checker:- ramble

[Phillip Lord]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

  >> > I.e. I don't want to change the .emacs code at all, but I'd
  >> > like
  >> >to have a more-or-less generic way to add helpful analysis of
  >> >the code so as to give useful information to the user about
  >> >suspicious customizations.

  >> Well I would agree that this would be preferable.

  Stefan> It should be possible to get the desired result without
  Stefan> implementing an elisp interpreter in elisp, but instead by
  Stefan> temporarily rebinding `setq' as a macro (and things like
  Stefan> that).

I think that would be fairly hard! setq is such a basic function, and
to change it so that it worked correctly, but still failed at the
appropriate time. 

I presume you are still suggesting using the type information in
custom to make the determination as to whether an .emacs setq was
"type safe" or not? If this is the case, it would seem the two
approaches (a custom-setq, or augmented setq) would use a lot of
common code. 




  Stefan> Another alternative is to put the checking into the
  Stefan> byte-compiler (which already takes care of traversing elisp
  Stefan> code) and then byte-compile the .emacs file (not for speed
  Stefan> but for sanity checks).  This might be the best option.

That also sounds plausible, if somewhat beyond my elisp coding
skills. 


Cheers

Phil

Re: Using custom as a type checker:- ramble

[Stefan Monnier]

Stefan> It should be possible to get the desired result without
Stefan> implementing an elisp interpreter in elisp, but instead by
Stefan> temporarily rebinding `setq' as a macro (and things like
Stefan> that).
> I think that would be fairly hard! setq is such a basic function, and
> to change it so that it worked correctly, but still failed at the
> appropriate time. 

I don't intend it to fail any more than the plain `setq' does.
The only difference would be a bunch of warnings.

> I presume you are still suggesting using the type information in
> custom to make the determination as to whether an .emacs setq was
> "type safe" or not? If this is the case, it would seem the two
> approaches (a custom-setq, or augmented setq) would use a lot of
> common code.

Probably, but without making it visible at the source level and
without impacting the semantics of the code at all.


        Stefan

Re: Using custom as a type checker:- ramble

[Phillip Lord]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu.emacs.help/news/@flint.cs.yale.edu> writes:

  Stefan> It should be possible to get the desired result without
  Stefan> implementing an elisp interpreter in elisp, but instead by
  Stefan> temporarily rebinding `setq' as a macro (and things like
  Stefan> that).
  >> I think that would be fairly hard! setq is such a basic function,
  >> and to change it so that it worked correctly, but still failed at
  >> the appropriate time.

  Stefan> I don't intend it to fail any more than the plain `setq'
  Stefan> does.  The only difference would be a bunch of warnings.

Ah, okay. I was thinking of signalling errors, but warning is also
fine. 

Cheers

Phil