bug#38696: "If you edit it by hand, you could mess it up"

[Drew Adams]

>   > But that's not the likeliest scenario.  The real,
>   > more likely problem is that you make a change to
>   > this code and later Customize overwrites your
>   > change - and you might not be aware of that.
> 
> We could make Customize detect hand-editing by looking at the value
> in .emacs and determining that it doesn't have a format Customize
> could ever write?
> 
> Or we could the comment say, "If you want to edit this value by hand,
> delete this comment."  Customize could interpret the absence of
> that comment as meaning the value has been hand-edited.
> 
> Either way, Customize could then report a problem and offer a choice
> of (1) deleting the value in the file, or (2) quitting.

I guess you're proposing that, if a user edits
what Customize puts in a user file (`custom-file'
or init file), then Customize could/should try to
detect that that has occurred.  And then Customize
could/should ask the user how to handle that
situation.

A priori that sounds complicated, and maybe error
prone, to me.  But maybe it's worth considering.

My suggestion would be to just change the comment
wording a bit, to make clear that future use of
Customize might overwrite any manual changes you
make to that code.  IOW, state that clearly as a
major reason _why_ you're advised not to edit the
code.

And as others have pointed out, future Customize
use might not always be obvious, interactive use
of `M-x customize-*' commands.

---

I'd also suggest that the inserted comment, and
the Emacs docs more generally, would do well to
suggest/advise that users use `custom-file', to
keep Customize-generated code separate from their
init files.

That's a good idea in general, IMO, and it would
go a long way toward avoiding the problem of
users editing such code, i.e., of users and
Customize stomping on each other.

---

I'd even suggest that if `custom-file' is
undefined then Customize should immediately ask
a user to define it, instead of just silently
writing to a user's init file.

At least, that could be done if Customize could
be sure there's not already any Customize code
in the init file.

But if an init file already has some Customize
code, then such a dialog becomes more delicate.
Customize might need to just advise moving such
existing code to the new `custom-file'.

Or if, as you suggest, it could detect its own
code then it could offer to move any such that's
in the init file to a `custom-file'.