unlispification considered harmful - turn off custom-unlispify-tag-names by default

unlispification considered harmful - turn off custom-unlispify-tag-names by default

[Drew Adams]

I don't think unlispification is a good thing for users. The default value of
`custom-unlispify-tag-names' should be nil.

Do you really think that this:

 Read Buffer Completion Ignore Case: Show Value

is more readable, even to a non-Lispian, than this?

 read-buffer-completion-ignore-case: Show Value

I don't think so. The second makes it clear that this is a variable name (or a
face name). The first is just baroque obfuscation, IMO. (The name could be
`custom-obfuscate-tag-names'.)

Emacs users are used to seeing variable names, function names, and so on - think
of `apropos' output. We don't use "unlispified" names there, and we shouldn't
use them here either. This almost insults users, IMO - it doesn't help them.
They should be able to expect the same names everywhere.

Users use `M-x customize-option', not just the menubar menu, to get to Customize
buffers in the first place. And that command requires you to input an option
name in "lispified" format. Once you're in, obfuscation takes over. If you can
handle using the Lisp name to get in, then you can handle seeing it on the
inside too.

If `custom-unlispify-tag-names' is nil, then you can use, in Customize, `C-h v',
`find-variable', and other commands that pick up the variable name as a default.
Not so if it is t. (Yes, doc strings sometimes give more info than the text
shown in Customize - `read-buffer-completion-ignore-case' is a case in point.)

Less obviously, the same argument can be made for
`custom-unlispify-menu-entries'. The two should go together, so that you see the
same representation everywhere.

These options should really just be removed, IMO, but a first step would be to
give them a value of nil.

Re: unlispification considered harmful - turn off custom-unlispify-tag-names by default

[Glenn Morris]

I have zero interest in this subject, but here is a link to a previous
related discussion, in the hope of avoiding repetition.

http://lists.gnu.org/archive/html/emacs-devel/2005-01/msg00093.html