Re: Summary and next steps for (package-initialize)

[Radon Rosborough <radon.neon@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2960 bytes --]

> 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?

[-- Attachment #2: Type: text/html, Size: 4011 bytes --]