> Yes, it's going to be annoying for two fractions of users, the
> targeted fraction - that is the beginners who didn't set up
> package.el right and old timers during some rare moments of messing
> with their configs.
Yes, but the second init-file would result in no annoyance for anyone.
Why is a small amount of annoyance better than no annoyance?
> And I too would have preferred just removing any additions, but my
> proposal seems like an OK compromise.
If by "additions" you mean Emacs writing to the init-file, then the
second init-file proposal eliminates that behavior entirely. Why is
there the need for a compromise? Having Emacs write to the init-file
is an order of magnitude more complexity than having an optional
second init-file that doesn't need to be used by most people, so it
seems to me like any solution that involves Emacs writing to the
init-file is a step backwards.
> And I don't care about batch mode completely. If you're using batch
> mode, than you know what you're doing.
Yes, but nobody likes inconsistent behavior. I think the fewer
unexpected differences there are between Emacs' modes of operation,
the better.
> It's just that we can't solve package-initialize by writing to
> custom.
Correct. And since we can solve package-initialize without writing to
anything at all, why not do that?
> I'm just proposing to tweak error handling, that's it.
You're injecting business logic into an otherwise generic piece of
code. I don't think this is a sign of good design.
> While you're proposing to add another init file.
Can you explain why this is a big problem? In what circumstance would
this cause trouble?
Maybe it would be better to call it a "config file", because that's
basically all it is. And we've got plenty of those already. Dozens, in
fact, scattered all over ~/.emacs.d and used by various packages and
different parts of Emacs.
> we're talking about upgrading experience of a very limited subset of
> users
The second init-file would accomplish this as well with fewer
problems.
> (only those new users who haven't yet acquired the skill of
> copy-pasting magic spells into their init)
The second init-file would not require anybody to do this. In fact, it
would free them from such a need, because (package-initialize) no
longer needs to be in the init-file.
> So, while this is somewhat ambitious, adding another init just for
> that is even more so.
I think we need to see some concrete disadvantages of the second
init-file proposal, since the error-catching proposal has some
already.
~~~~~
But really, this is all just an aside. The real problem is that having
Emacs add `package-initialize' automatically is *fundamentally
broken*. There is NO WAY to determine the correct place to put the
call. And having a system that sometimes "fixes" the problem in a way
that breaks the user's config can't possibly be better than a system
that always works. Right?