Re: byte compiling defcustom

[Dan Nicolaescu]

Luc Teirlinck <address@hidden> writes:

  > Richard already made a decision on this.  But just to help you explain
  > the decision:

IMVHO Richard made a decision based on incomplete data.

It might be too late now, but I wanted to state my position.

Again, I claim that if the user needs to see lisp for a defcustom, then
the defcustom is not designed well enough and is not very user
friendly. 

To me it seems that maintaining an infrastructure to access the original
lisp values for defcustom is just added complexity with no real benefit
to users, and with _very_ limited benefit for one or two hackers that
even know about this.

Defcustom now effectively hides the definition from the byte compiler,
and the byte compiler warnings are the easiest way to find some bugs.

But I admit, I might be wrong about this, so a simple counter example
should be convincing enough.


  >    This returns (2). And I would argue that this is the right thing to do
  >    for _this_ example
  > 
  > For _this_ example obviously yes, but see my response to Stefan.

I saw it, but I failed to see anything compelling there.

  >    Now, is there a situation where showing a lisp expression is the desired
  >    thing? Any examples in the emacs sources?
  > 
  > Plenty, but since a decision has already been made, I am not going to
  > spend time finding some of them among the even more numerous
  > defcustoms whose default values are booleans and such (for which it
  > does not make a difference).

Please give a single example, just claiming that it does exist not show
that it is indeed true.

  >    Without any examples I am inclined to believe that showing users lisp
  >    code defeats one of the purposes of defcustom: not having to write lisp
  >    to customize behavior.
  > 
  > It does not _serve_, but in no way _defeats_ either, _one_ of the
  > purposes of Custom.  (The Lisp only gets shown if the user _asks_ for
  > it).  But it serves several _other_ purposes of Custom, such as: use
  > as a convenient browser with possibility to conveniently edit the
  > standard value without having to grep through the source code, visit
  > .emacs, cut and paste and so on.  

True, but how is this relevant to the problem at hand?

  > Also, the possibility to conveniently manage the new value
  > afterwards.  In addition, it is a help to people who want to
  > gradually transition from just using straightforward customizations
  > to writing Lisp.  

Again, an example would be more useful than just stating this.