bug#7524: 24.0.50; backquote converts newlines in strings to "\n"

["Drew Adams" <drew.adams@oracle.com>]

> > (This is particularly messy when used in defcustom values.)
> 
> I don't know what you're referring to.  I'll keep the bug 
> open for now, assuming that the defcustom issue will be
> the actual bug.

You're right of course about the chars "\n" and a ^J char in a Lisp string.

`defcustom' does different things in this regard, depending on the :type (and
whether there is a mismatch, but that's something else no doubt).

See what the \n representation does, for example, with the file I sent to
emacs-devel yesterday, thread "Variable behavior for `mouse-3' second click at
same spot".  Here's a direct URL to the file.

http://www.emacswiki.org/emacs/mouse3.el

Eval the defcustom for `mouse3-region-popup-submenus', then use `M-x customize',
and you'll see how messy (how wide) the display is.

Independently of this, perhaps Customize should wrap long lines in some way.
Dunno.  Doesn't seem like it should be displaying lines as 168 chars wide rather
than wrapping them.

This doc-string with two newline chars gets shown as a single line without any
wrapping: 168 chars wide:

"Replace the selected rectangle by the contents of a register you name.
Note that the rectangle currently selected is first killed.  You can
restore it by yanking."

Much of the reason for adding the doc string to the lambda was to give Customize
users more info about these anonymous commands.  The way things are, I guess the
best thing for a programmer to do is create named commands and forgo anonymous
ones within option values.  Nothing wrong with that, but I think we should be
able to do better wrt Customize display.

Especially since most of the time newlines in strings _are_ shown in Customize
using newline chars rather than the two chars "\n".

Maybe the :type could be refined in this particular defcustom in some way that
would cause the Customize display to be as usual (newline chars, no "\n").
Dunno (suggestions welcome).  But at least this defcustom is not a case of
`mismatch' (mismatch seems always to display a newline char in a string as
"\n").