byte compiling defcustom

byte compiling defcustom

[Dan Nicolaescu]

These 2 forms:

(defvar foo     (if (featurep 'xemacs) 'bar 'baz) "doc")
(defcustom foo1 (if (featurep 'xemacs) 'bar 'baz) "doc")


Are compiled to:

(defvar foo 'baz (#$ . 543))
(custom-declare-variable 'foo1 '(if (featurep 'xemacs) 'bar 'baz) '(#$ . 581))


Wouldn't it be better if the value of `foo1' was also optimized at
compile time?

Re: byte compiling defcustom

[Richard Stallman]

    (defvar foo     (if (featurep 'xemacs) 'bar 'baz) "doc")
    (defcustom foo1 (if (featurep 'xemacs) 'bar 'baz) "doc")


    Are compiled to:

    (defvar foo 'baz (#$ . 543))
    (custom-declare-variable 'foo1 '(if (featurep 'xemacs) 'bar 'baz) '(#$ . 581))

The initial value expression for defcustom is saved and gets
recalculated later in some cases.  So it cannot in general be
optimized.

This particular simplification could be done even in defcustom, since
(featurep 'xemacs) is effectively a constant.  But why bother
to implement that optimization?  It works fine as it is now.

Re: byte compiling defcustom

[Stefan Monnier]

>     (defvar foo     (if (featurep 'xemacs) 'bar 'baz) "doc")
>     (defcustom foo1 (if (featurep 'xemacs) 'bar 'baz) "doc")


>     Are compiled to:

>     (defvar foo 'baz (#$ . 543))
>     (custom-declare-variable 'foo1 '(if (featurep 'xemacs) 'bar 'baz) '(#$ . 581))

> The initial value expression for defcustom is saved and gets
> recalculated later in some cases.  So it cannot in general be
> optimized.

He probably meant "compiled" as much as "optimized".
The same holds of keyword arguments to custom-declare-variable, by the way.

> This particular simplification could be done even in defcustom, since
> (featurep 'xemacs) is effectively a constant.  But why bother
> to implement that optimization?  It works fine as it is now.

The patch below implements the desired feature: it byte-compiles the
default-value-expression (first part of the hunk) as well as any
keyword arguments (second part of the hunk).  Notice that the second
part actually simplifies the code.

To me the main benefit is not so much efficiency as better warnings.


        Stefan


PS: While fiddling with it, I discovered that (defvar foo 1 "haha") is
byte compiled into itself (more or less), whereas (defvar foo 1)
gets "open coded" as
(byte-code "..." [current-load-list foo default-boundp set-default 1] 3)
so it won't call Fdefvar and will hence circumvent the check added to
defvar to detect when defvar is used within a `let' binding:

	{ /* Check if there is really a global binding rather than just a let
	     binding that shadows the global unboundness of the var.  */
	  struct specbinding *pdl = specpdl_ptr;
	  while (--pdl >= specpdl)
	    {
	      if (EQ (pdl->symbol, sym) && !pdl->func
		  && EQ (pdl->old_value, Qunbound))
		{
		  message_with_string ("Warning: defvar ignored because %s is let-bound",
				       SYMBOL_NAME (sym), 1);
		  break;
		}
	    }
	}

Maybe those defvars shouldn't be open-coded?


--- orig/lisp/emacs-lisp/bytecomp.el
+++ mod/lisp/emacs-lisp/bytecomp.el
@@ -2309,18 +2309,16 @@
   ;;   (byte-compile-nogroup-warn form))
   (when (byte-compile-warning-enabled-p 'free-vars)
     (push (nth 1 (nth 1 form)) byte-compile-special-variables))
+  (when (eq (car-safe (nth 2 form)) 'quote)
+    ;; (nth 2 form) is meant to evaluate to an expression, so if we have the
+    ;; final value already, we can byte-compile it.
+    (setcar (cdr (nth 2 form))
+            (byte-compile-top-level (cadr (nth 2 form)) nil 'file)))
   (let ((tail (nthcdr 4 form)))
     (while tail
-      ;; If there are any (function (lambda ...)) expressions, compile
-      ;; those functions.
-      (if (and (consp (car tail))
-	       (eq (car (car tail)) 'function)
-	       (consp (nth 1 (car tail))))
-	  (setcar tail (byte-compile-lambda (nth 1 (car tail))))
-	;; Likewise for a bare lambda.
-	(if (and (consp (car tail))
-		 (eq (car (car tail)) 'lambda))
-	    (setcar tail (byte-compile-lambda (car tail)))))
+      (unless (keywordp (car tail))      ;No point optimizing keywords.
+        ;; Compile the keyword arguments.
+        (setcar tail (byte-compile-top-level (car tail) nil 'file)))
       (setq tail (cdr tail))))
   form)

Re: byte compiling defcustom

[Richard Stallman]

    The patch below implements the desired feature: it byte-compiles the
    default-value-expression (first part of the hunk) as well as any
    keyword arguments (second part of the hunk).  Notice that the second
    part actually simplifies the code.

I don't see any particular benefit in compiling these, but I don't
object to trying this in the trunk.

Can you make sure that very simple default values do not get compiled?

Re: byte compiling defcustom

[Richard Stallman]

    Maybe those defvars shouldn't be open-coded?

Maybe you are right.  If they are not open-coded, what would the
compiler output for them?  Should it put a call to `eval' into the
bytecode?  Break the sequence of bytecode and put them into the .elc
file as defvar forms?

Re: byte compiling defcustom

[Dan Nicolaescu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

  > >     (defvar foo     (if (featurep 'xemacs) 'bar 'baz) "doc")
  > >     (defcustom foo1 (if (featurep 'xemacs) 'bar 'baz) "doc")
  > 
  > 
  > >     Are compiled to:
  > 
  > >     (defvar foo 'baz (#$ . 543))
  > >     (custom-declare-variable 'foo1 '(if (featurep 'xemacs) 'bar 'baz) '(#$ . 581))
  > 
  > > The initial value expression for defcustom is saved and gets
  > > recalculated later in some cases.  So it cannot in general be
  > > optimized.
  > 
  > He probably meant "compiled" as much as "optimized".
  > The same holds of keyword arguments to custom-declare-variable, by the way.
  > 
  > > This particular simplification could be done even in defcustom, since
  > > (featurep 'xemacs) is effectively a constant.  But why bother
  > > to implement that optimization?  It works fine as it is now.
  > 
  > The patch below implements the desired feature: it byte-compiles the
  > default-value-expression (first part of the hunk) as well as any
  > keyword arguments (second part of the hunk).  Notice that the second
  > part actually simplifies the code.

FWIW the size of a tar file containing all the elc files in emacs went
from 29511680 to 29491200 after this patch.  Not the best metric, but it
shows that the patch has some impact. So I'd vote for checking it in.

Re: byte compiling defcustom

[Luc Teirlinck]

Stefan Monnier wrote:

   The patch below implements the desired feature: it byte-compiles the
   default-value-expression (first part of the hunk) as well as any
   keyword arguments (second part of the hunk)

I did not try the patch, but I can not see how this would _not_ ruin
the "Show Saved Lisp Expression" feature in the State buttons in
Custom buffers by showing byte code instead of Lisp code that the user
can edit.  Does it not?

   FWIW the size of a tar file containing all the elc files in emacs went
   from 29511680 to 29491200 after this patch.  Not the best metric, but it
   shows that the patch has some impact.

I do not know whether the "some impact" above was meant seriously or
ironically, but the "impact" is less than 0.07 percent, that is, for
all practical purposes inexistent.  Definitely not worth ruining a
feature for.

Sincerely,

Luc Teirlinck.

Re: byte compiling defcustom

[Dan Nicolaescu]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

  > Stefan Monnier wrote:
  > 
  >    The patch below implements the desired feature: it byte-compiles the
  >    default-value-expression (first part of the hunk) as well as any
  >    keyword arguments (second part of the hunk)
  > 
  > I did not try the patch, but I can not see how this would _not_ ruin
  > the "Show Saved Lisp Expression" feature in the State buttons in
  > Custom buffers by showing byte code instead of Lisp code that the user
  > can edit.  Does it not?

I wouldn't want to speculate, how can one check for that? I don't know
how to use "Show Saved Lisp Expression", and it seems that the "Custom"
menu in a customize buffer does not work, it disappears after touching
the customize value, the same happens in 22.1...

  >    FWIW the size of a tar file containing all the elc files in emacs went
  >    from 29511680 to 29491200 after this patch.  Not the best metric, but it
  >    shows that the patch has some impact.
  > 
  > I do not know whether the "some impact" above was meant seriously or
  > ironically, but the "impact" is less than 0.07 percent, that is, for
  > all practical purposes inexistent.  Definitely not worth ruining a
  > feature for.

Looking at the percentage of total space does not look like a valid
comparison for this optimization that applies to a _very_ small subset
of the whole codebase.

Re: byte compiling defcustom

[Luc Teirlinck]

Dan Nicolaescu wrote:

   I wouldn't want to speculate, how can one check for that.

Load in compiled version:

 (defcustom silly (if show-trailing-whitespace
		      (lambda (if t (+ 3 9)))
				    (lambda (if t (- 3 9))))
				     "Silly doc")

Then do `M-x customize-option RET silly'.

The value shown should be the lambda expression, not some byte code or
other stuff.  But I guess that should work out OK.  I am more afraid of the
following:

Click on the "State button" and select "Show Saved Lisp Expression".

What should appear as value is:

(if show-trailing-whitespace
		      (lambda (if t (+ 3 9)))
				    (lambda (if t (- 3 9))))

and not some byte code or other stuff.

Sincerely,

Luc Teirlinck.

Re: byte compiling defcustom

[Luc Teirlinck]

In a previous message I forgot to attribute the following quote to Dan
Nicolaescu, giving the false impression that Stefan Monnier wrote it
(sorry about that):

      FWIW the size of a tar file containing all the elc files in emacs went
      from 29511680 to 29491200 after this patch.  Not the best metric, but it
      shows that the patch has some impact.

Sincerely,

Luc Teirlinck.

Re: byte compiling defcustom

[Luc Teirlinck]

   I wouldn't want to speculate, how can one check for that? I don't know
   how to use "Show Saved Lisp Expression", and it seems that the "Custom"
   menu in a customize buffer does not work

Maybe much better example than the one I gave before (I am not really
that familiar with byte optimization):

(defcustom stupid (if t (+ 1 1)) "Silly doc")

With this example the shown value should be 2, but "Show Saved Lisp
Expression" should show the value as:

(if t (+ 1 1))

Sincerely,

Luc Teirlinck.

Re: byte compiling defcustom

[Luc Teirlinck]

   I did not try the patch, but I can not see how this would _not_ ruin
   the "Show Saved Lisp Expression" feature in the State buttons in
   Custom buffers by showing byte code instead of Lisp code that the user
   can edit.

On second thought, I now believe that I misunderstood and that it
should _not_ represent a problem, as long as the uncompiled value is
stored in the `standard-value' property.  But the last defcustom I
gave is easy enough to check anyway,

Sincerely,

Luc.

Re: byte compiling defcustom

[Luc Teirlinck]

The message to which this is a reply has a wrong address for Stefan
(final a missing), so if you reply to it, you will get a bounce
message (sorry about that).  So reply to the following copy instead:

   I did not try the patch, but I can not see how this would _not_ ruin
   the "Show Saved Lisp Expression" feature in the State buttons in
   Custom buffers by showing byte code instead of Lisp code that the user
   can edit.

On second thought, I now believe that I misunderstood and that it
should _not_ represent a problem, as long as the uncompiled value is
stored in the `standard-value' property.  But the last defcustom I
gave is easy enough to check anyway, for somebody who has the patch
already installed anyway.

Sincerely,

Luc.

Re: byte compiling defcustom

[Richard Stallman]

    I did not try the patch, but I can not see how this would _not_ ruin
    the "Show Saved Lisp Expression" feature in the State buttons in
    Custom buffers by showing byte code instead of Lisp code that the user
    can edit.  Does it not?

That seems like a very strong argument.

Re: byte compiling defcustom

[Stefan Monnier]

> Can you make sure that very simple default values do not get compiled?

Yes, that's already taken care of: they get compiled and then uncompiled.


        Stefan

Re: byte compiling defcustom

[Luc Teirlinck]

From my previous message:

   On second thought, I now believe that I misunderstood and that it
   should _not_ represent a problem, as long as the uncompiled value is
   stored in the `standard-value' property.

But then again, I assume that byte-compiling the defcustom could store
byte code in that property.  Anyway, easy enough to check for anybody
having the patch already installed:

Load the compiled version of:

(defcustom stupid (if t (+ 1 1)) "Silly doc.")

Then do:

(get 'stupid 'standard-value)

Which should return:

((if t (+ 1 1)))

Sincerely,

Luc.

Re: byte compiling defcustom

[Stefan Monnier]

> (defcustom stupid (if t (+ 1 1)) "Silly doc.")

> Then do:

> (get 'stupid 'standard-value)

> Which should return:

> ((if t (+ 1 1)))

I don't think it's a relevant example.  Because both (if t (+ 1 1)) and
2 are not only equivalent but they are just as readable.

But indeed (defcustom foo3 (if toto (trul (fr t))) "haha")
turns the expression
into "(byte-code "\b\205	\0\301\302\303!!\207" [toto trul fr t] 3)"
which is a lot more problematic.  So clearly, this patch cannot be
installed as is.


        Stefan

Re: byte compiling defcustom

[Luc Teirlinck]

Stefan Monnier wrote:

   I don't think it's a relevant example.

I did not try to give an example that was relevant, but one that
allowed easily to check whether the problem occurred, i.e. whether the
standard-value property got byte compiled.  There very definitely are
many relevant examples (actual defcustoms) in the current Emacs
distribution, but I just could not immediately remember their names or
otherwise find them back, so I had to make up a test case, instead of
pointing out one of the actually occurring problems.

Sincerely,

Luc.

Re: byte compiling defcustom

[Richard Stallman]

    it seems that the "Custom"
    menu in a customize buffer does not work, it disappears after touching
    the customize value, the same happens in 22.1...

I am not sure what this means.
Could you please send us a *precise* test case for this bug?

Meanwhile, the (temporary) existence of this bug (which we will soon
fix) has nothing to do with the question of whether to compile the
initial value expressions.  It is now clear that we must not compile
them.

We should put a comment at a suitable place explaining that these must
not be compiled.

Re: byte compiling defcustom

[Dan Nicolaescu]

Luc Teirlinck <teirllm@dms.auburn.edu> writes:

  > >From my previous message:
  > 
  >    On second thought, I now believe that I misunderstood and that it
  >    should _not_ represent a problem, as long as the uncompiled value is
  >    stored in the `standard-value' property.
  > 
  > But then again, I assume that byte-compiling the defcustom could store
  > byte code in that property.  Anyway, easy enough to check for anybody
  > having the patch already installed:
  > 
  > Load the compiled version of:
  > 
  > (defcustom stupid (if t (+ 1 1)) "Silly doc.")
  > 
  > Then do:
  > 
  > (get 'stupid 'standard-value)
  > 
  > Which should return:
  > 
  > ((if t (+ 1 1)))

This returns (2). And I would argue that this is the right thing to do
for _this_ example.  If the result is a constant, then it is better for
the user to see the constant, not lisp gobbledygook. 

Now, is there a situation where showing a lisp expression is the desired
thing? Any examples in the emacs sources?
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.

disappearing custom menu (was: Re: byte compiling defcustom)

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  >     it seems that the "Custom"
  >     menu in a customize buffer does not work, it disappears after touching
  >     the customize value, the same happens in 22.1...
  > 
  > I am not sure what this means.
  > Could you please send us a *precise* test case for this bug?

emacs -Q
M-x customize-variable RET fill-column RET

There should be a "Custom" menu entry in the menu bar.

Click on the "70" text box, now try to click on the "Custom" menu to
open it, it disappears. 
This happens with both Gtk+ and Athena widgets, with the CVS HEAD and
22.1.

Re: byte compiling defcustom

[Luc Teirlinck]

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

   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.

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

   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.  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.  I know of a sysadmin
who does not really know Lisp who successfully manages to work that way
(managed to fool me in believing he _did_ know Elisp).

Sincerely,

Luc.

RE: disappearing custom menu (was: Re: byte compiling defcustom)

[Drew Adams]

>   >     it seems that the "Custom"
>   >     menu in a customize buffer does not work, it disappears
>   >     after touching the customize value, the same happens in 22.1...
>   >
>   > I am not sure what this means.
>   > Could you please send us a *precise* test case for this bug?
>
> emacs -Q
> M-x customize-variable RET fill-column RET
>
> There should be a "Custom" menu entry in the menu bar.
>
> Click on the "70" text box, now try to click on the "Custom" menu to
> open it, it disappears.
> This happens with both Gtk+ and Athena widgets, with the CVS HEAD and
> 22.1.

Confirmed in GNU Emacs 22.1.1 (i386-mingw-nt5.1.2600) of 2007-06-02 on
RELEASE
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4) --cflags -Ic:/gnuwin32/include'

Also, if you double-click the mouse to select the `70' value, the Custom
menu disappears as well.

Re: disappearing custom menu

[Lennart Borgman (gmail)]

Dan Nicolaescu wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
>   >     it seems that the "Custom"
>   >     menu in a customize buffer does not work, it disappears after touching
>   >     the customize value, the same happens in 22.1...
>   > 
>   > I am not sure what this means.
>   > Could you please send us a *precise* test case for this bug?
> 
> emacs -Q
> M-x customize-variable RET fill-column RET
> 
> There should be a "Custom" menu entry in the menu bar.
> 
> Click on the "70" text box, now try to click on the "Custom" menu to
> open it, it disappears. 
> This happens with both Gtk+ and Athena widgets, with the CVS HEAD and
> 22.1.


And with the version I am running on w32 (a bit older).

Re: disappearing custom menu

[martin rudalics]

> Click on the "70" text box, now try to click on the "Custom" menu to
> open it, it disappears. 
> This happens with both Gtk+ and Athena widgets, with the CVS HEAD and
> 22.1.

It's because you're in an editable field where `custom-mode-map' is
no active.

Re: disappearing custom menu

[Dan Nicolaescu]

martin rudalics <rudalics@gmx.at> writes:

  > > Click on the "70" text box, now try to click on the "Custom" menu to
  > > open it, it disappears. This happens with both Gtk+ and Athena
  > > widgets, with the CVS HEAD and
  > > 22.1.
  > 
  > It's because you're in an editable field where `custom-mode-map' is
  > no active.

If that is the case, then there's something wrong with the mechanism to
set the map. The menu does not disappear when the point is moved to the
field (and does not appear when the point is moved out of the field). It
disappears when trying to click on it, this is strange for the users.

Re: disappearing custom menu

[martin rudalics]

> If that is the case, then there's something wrong with the mechanism to
> set the map. The menu does not disappear when the point is moved to the
> field (and does not appear when the point is moved out of the field). It
> disappears when trying to click on it, this is strange for the users.
> 

Try

(easy-menu-define
   Custom-mode-menu (list custom-mode-map custom-field-keymap)
   "Menu used in customization buffers."
   (nconc (list "Custom"
	       (customize-menu-create 'customize))
	 (mapcar (lambda (arg)
		   (let ((tag     (nth 0 arg))
			 (command (nth 1 arg))
			 (active  (nth 2 arg))
			 (help    (nth 3 arg)))
		     (vector tag command :active (eval active) :help help)))
		 custom-commands)))

RE: disappearing custom menu

[Drew Adams]

> > Click on the "70" text box, now try to click on the "Custom" menu to
> > open it, it disappears.
> > This happens with both Gtk+ and Athena widgets, with the CVS HEAD and
> > 22.1.
>
> It's because you're in an editable field where `custom-mode-map' is
> no active.

I almost replied the same thing, but I think there is a bug here. If the
menu is inappropriate when editing, then it should be removed as soon as you
enter the field, not when you select text there or when you click the Custom
menu.

Re: disappearing custom menu

[martin rudalics]

> I almost replied the same thing, but I think there is a bug here. If the
> menu is inappropriate when editing, then it should be removed as soon as you
> enter the field, not when you select text there or when you click the Custom
> menu.
> 

Editable fields are very, very special.  I'd rather not tinker
with this.  But if you can repeat it in a different context ...

Re: byte compiling defcustom

[Dan Nicolaescu]

Luc Teirlinck <teirllm@dms.auburn.edu> 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.

Re: disappearing custom menu

[Dan Nicolaescu]

martin rudalics <rudalics@gmx.at> writes:

  > > If that is the case, then there's something wrong with the mechanism to
  > > set the map. The menu does not disappear when the point is moved to the
  > > field (and does not appear when the point is moved out of the field). It
  > > disappears when trying to click on it, this is strange for the users.
  > >
  > 
  > Try
  > 
  > (easy-menu-define
  >   Custom-mode-menu (list custom-mode-map custom-field-keymap)
  >   "Menu used in customization buffers."
  >   (nconc (list "Custom"
  > 	       (customize-menu-create 'customize))
  > 	 (mapcar (lambda (arg)
  > 		   (let ((tag     (nth 0 arg))
  > 			 (command (nth 1 arg))
  > 			 (active  (nth 2 arg))
  > 			 (help    (nth 3 arg)))
  > 		     (vector tag command :active (eval active) :help help)))
  > 		 custom-commands)))

This worked fine. Thanks!
(BTW, to make your work a bit easier when installing this: besides
replacing the similar code in cus-edit.el with the above, I needed to
move the definition of custom-field-keymap before the above code).

Re: byte compiling defcustom

[Stefan Monnier]

For what it's worth, there's a possible middle ground:
use byte-optimize rather the byte-compile.  So the code is still "normal
elisp source code" but potentially a bit different from the original.


        Stefan

Re: disappearing custom menu

[martin rudalics]

> (BTW, to make your work a bit easier when installing this: besides
> replacing the similar code in cus-edit.el with the above, I needed to
> move the definition of custom-field-keymap before the above code).

Installed.

Re: byte compiling defcustom

[Richard Stallman]

Here's one defcustom with a nontrivial default value form.

    (defcustom custom-raised-buttons (not (equal (face-valid-attribute-values :box)
						 '(("unspecified" . unspecified))))

Re: disappearing custom menu

[Richard Stallman]

    If that is the case, then there's something wrong with the mechanism to
    set the map. The menu does not disappear when the point is moved to the
    field (and does not appear when the point is moved out of the field). It
    disappears when trying to click on it, this is strange for the users.

In some sense it would be logical for it to disappear when you move
point into the field.  That does not happen because mere cursor motion
doesn't recompute the menus.  It would be possible to implement that,
but it might slow Emacs down a lot.

However, to have the menu bar item appear and disappear as you move
point would also look strange.  I am not so sure it is really the
right thing.

A different solution occurs to me: arrange for the menu bar item
to be active in these active fields too.  Why not?

The editable field needs to turn off the RET binding and other special
key bindings of Custom mode.  But it does not need to turn off
the menu bar item.

What do people think of this?

Re: disappearing custom menu

[martin rudalics]

> A different solution occurs to me: arrange for the menu bar item
> to be active in these active fields too.  Why not?

I think that's what I checked in, please have a look.

> The editable field needs to turn off the RET binding and other special
> key bindings of Custom mode.  But it does not need to turn off
> the menu bar item.
> 
> What do people think of this?

RE: disappearing custom menu

[Drew Adams]

> A different solution occurs to me: arrange for the menu bar item
> to be active in these active fields too.  Why not?
> 
> The editable field needs to turn off the RET binding and other special
> key bindings of Custom mode.  But it does not need to turn off
> the menu bar item.
> 
> What do people think of this?

I agree. Just enable/disable the appropriate menu items.

Re: byte compiling defcustom

[Dan Nicolaescu]

Richard Stallman <rms@gnu.org> writes:

  > Here's one defcustom with a nontrivial default value form.
  > 
  >     (defcustom custom-raised-buttons (not (equal (face-valid-attribute-values :box)
  > 						 '(("unspecified" . unspecified))))

Good example, it addresses the points I was trying to make:

1. Is there any value in this being a defcustom? IMO, absolutely not. Do
users really care that much about the default raised buttons to change
them to use the much uglier brackets? Very doubtful.

2. Doing (get 'custom-raised-buttons 'standard-value) will indeed show
bytecodes in this case. But the default value:
(not (equal (face-valid-attribute-values :box)
   '(("unspecified" . unspecified))))
is not much readable either if you don't know elisp and know some
details about faces, in which case you can just do C-h v
custom-raised-buttons RET and follow the link in the Help buffer to look
at the source code.

Re: byte compiling defcustom

[Richard Stallman]

    For what it's worth, there's a possible middle ground:
    use byte-optimize rather the byte-compile.  So the code is still "normal
    elisp source code" but potentially a bit different from the original.

I don't see any major flaws with that, but I think it is cleaner
to show the expression precisely as it was in the source code.

Re: byte compiling defcustom

[Richard Stallman]

    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. 

That may be true to some extent, but I am not sure it is always true.
Anyway these defcustoms shuld work right
even if their definitions are not ideal.

    To me it seems that maintaining an infrastructure to access the original
    lisp values for defcustom is just added complexity 

It is reduced complexity.  The code to compile these values would be added
complexity.

Re: byte compiling defcustom

[Luc Teirlinck]

   I don't see any major flaws with that, but I think it is cleaner
   to show the expression precisely as it was in the source code.

Indeed.  If the byte compiler would change the Lisp code in a way that
represents an improvement, then the Lisp code in the source should be
changed.

Moreover, this would represent much added complexity and risk for
negligible benefit.  Due to various keywords, defcustoms are way more
complex than defvars.  Their value is not necessarily evaluated in the
context of the file (e.g `custom-initialize-safe-set') and the
:initialize or :set function could even not evaluate it at all, or
evaluate it in a non-standard way.  So the potential for bugs in the
automatic optimization would be very non-trivial.

It seems clear that in terms of actual optimization,any gains would be
neglegible and the main reason to compile would be to emit warnings.
To me, no change seems necessary, but if the lack of warnings worries
people, can the compiler not just warn about, say, obsolete variables
and such without _changing_ anything about the code, leaving this up
to the author or maintainer.

Sincerely,

Luc.

Re: byte compiling defcustom

[Luc Teirlinck]

From my previous message:

    It seems clear that in terms of actual optimization,any gains would be
    neglegible and the main reason to compile would be to emit warnings.
    To me, no change seems necessary, but if the lack of warnings worries
    people, can the compiler not just warn about, say, obsolete variables
    and such without _changing_ anything about the code,

With the usual ways to disable such warnings, of course, since the
potential for fake warnings would be even a lot bigger that usual.

Sincerely,

Luc.

Re: byte compiling defcustom

[Richard Stallman]

    Good example, it addresses the points I was trying to make:

    1. Is there any value in this being a defcustom? IMO, absolutely not.

I don't know, but it doesn't affect this issue.  It IS a defcustom,
and as long as it is a defcustom, it needs to work right.

Since there is no important need for this optimization, my
decision is not to add it.

Re: byte compiling defcustom

[Richard Stallman]

    It seems clear that in terms of actual optimization,any gains would be
    neglegible and the main reason to compile would be to emit warnings.
    To me, no change seems necessary, but if the lack of warnings worries
    people, can the compiler not just warn about, say, obsolete variables
    and such without _changing_ anything about the code, leaving this up
    to the author or maintainer.

That is an interesting idea.