Re: find-file-hook as illustration of Custom problems

[Luc Teirlinck]

Richard Stallman wrote:

   For the case of hooks, we could imagine changing cus-edit.el so that
   edits made using Custom only affect elements that were installed using
   Custom.  Any other elements could be invisible and untouchable; or
   they might be displayed in a separate way as "program-added hooks" and
   untouchable through the usual Custom features.

I believe the latter.  The user should know that there are other,
untouchable things in the list.

  In effect, this means treating a single list as if it were the
  combination of too list values, one to be edited through Custom and
  one to be updated by programs.

I guess that Custom could use an internal custom-list-var for every
list-var.  Everything specified in the definition of the defcustom
should be in custom-list-var and hence, removable.

   I don't know how hard this would be.

That is the problem, of course.

The problem occurs not only for hooks, but for every non-atom, to
which elements can be added both by code and by the user.  So the
solution should apply to all such non-atoms.  But not to lists that
have a fixed length, like values that are a supposed to be a single
cons.  How do we tell such things apart?  Probably from the type.  So
something in the type of a list to which elements can be added both
through code and through Custom should say that Custom needs to use a
custom-list-var.  Currently, types are not designed with this in mind.
How do we determine whether a defcustom of type 'sexp' with standard
value nil is intended to be a variable length list or not?

I believe that we eventually should go in a direction like this.
If we want it for 21.4 somebody should essentially start to try to
implement it right now.  Per already has said that he has no time.
I do currently not have the time to start implementing something like
this either.

Sincerely,

Luc.