bug#39887: 26.3; Customize buffer does not show type expected

[Drew Adams]

> > The title already explains the bug. It would be great if the customize
> > buffer shows which type of variable is expected. Although the :type
> > keyword is included in the defcustom declaration, it is not shown in
> > the customization buffer which type is expected. If the wrong type is
> > filled in then the only error message given is "(mismatch)". Quite
> > some package writers do not - additionally - document their variables.
> 
> The Customize buffer is supposed to be a user-friendly, easy interface
> to use, and displaying types like
> 
> (alist :key-type symbol :value-type (choice symbol integer))
> 
> which only would make sense to a programmer would be the wrong way to go
> here.  The Customize interface already tries to guide the users as much
> as the type spec allows.
> 
> I'm sure there are individual doc strings that could stand improving,
> though, in which case bug reports for those would be welcome.  But I'm
> closing this bug report.

FWIW - 

My comment went in the opposite direction:

   +1. Great idea.  The type declaration in the help
   might also even be a link to the doc for :type.

I disagree that just because the Customize UI needs
be able to be amenable to non-lispers it should ONLY
have ever help for non-lispers.  That doesn't follow.

Many (most?) Emacs users are also to some extent
lispers.  And there's no reason that defcustoms are
necessarily limited to simple structures.  Users who
who can understand complex Lisp structures can also
benefit from Customize, including the UI - especially
its type-checking.  Customize is not only for
non-lispers.

When a defcustom type is simple, a non-lisper can
likely grok its spec in the help.  Why do you suppose
that we put a command's signature in the `C-h f' help?
Why should a novice who uses `C-h k C-f' be presented
with `(forward-char &optional N)'?  Why?  Because some
Emacs users can benefit from that info.

And when a custome type is complex, a novice can just
ignore the type signature, and a knowledgeable lisper
can appreciate seeing it.

For the same reason that menu `State' has item `Show
Saved Lisp Expression', we should be able to show
users the :type expression.

How that's made available is a different (and open)
question.  But whether users should be able to see
it within Customize should be answered with YES,
not NO (IMHO).

Option types can be a bear.  The more help we offer
users, the better.  This enhancement request was a
wonderful suggestion.

Yes, a user can use `C-h v' and move to the source
code to see the defcustom.  But we can make it easier
to see the :type info - in context with the existing
value.

(Just one opinion.)