Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA

[Corwin Brust]

You appear to have forgotten to CC the list so I've taken the liberty
of putting the group back in CC.

Thanks for taking the trouble to send me a third message asking me to
restate what I've already said.

In any case, suffice to say: I don't think this is a helpful change; I
attempted to show why I think it is unhelpful to anyone who isn't
already comfortable with Emacs.

That said, Drew's prior note convinced me not to involve myself
further; if you can somehow convince the maintainers that this
obfuscation and further proliferation of emacs configurations across
several "dot files" should be imposed on users by default I don't
intend to object further.

On Thu, Jan 20, 2022 at 3:50 AM <xenodasein@tutanota.de> wrote:
>
> Are you in the habit of randomly calling people supercilious then
> ignore when addressed?  Okay then, don't bother, I doubt you can
> present a better argument than "I can't copy two files around"
> anyway.
>
>
>
> Jan 18, 2022, 12:55 by xenodasein@tutanota.de:
>
> > Jan 8, 2022, 21:26 by xenodasein@tutanota.de:
> >
> >> Jan 8, 2022, 20:17 by >> corwin@bru.st>> :
> >> > Hi developers!
> >> >
> >> > I would very much prefer to be able to use a single file to contain my
> >> > hand-coded configurations as well as to save customizations.
> >> >
> >> > I found this a very comfortable way to build an emacs configuration
> >> > without understanding elisp over decades.
> >> >
> >> > During the last couple of years I have learned more elisp (yay, fun!)
> >> > and I don't find any frustration having to set up my custom-file
> >> > explicitly, now that this is something I prefer doing.
> >> >
> >> > During the "middle years", I knew enough to configure a fresh emacs by
> >> > retyping a minimum set of elisp into a .emacs file to get myself
> >> > started from a fresh install. (I didn't really understand how this
> >> > code I was typing worked, I just knew it made emacs easier for me to
> >> > use.) Once my .emacs was created on the newly setup system I would
> >> > use customize to amend the configuration as I used the editor. From
> >> > that point, I would migrate my configuration from machine to machine
> >> > until I somehow lost the .emacs file, at which point the process would
> >> > start over.
> >> >
> >> > Placing customized output into the .emacs file meant I had only one
> >> > file to keep track, trying to keep my 'live configuration settings"
> >> > going.
> >> >
> >> > I didn't find the mixture of hand and machine authored code in my
> >> > configuration file unexpected. In fact, I consider that most
> >> > programs with a "control panel" seem to work this way: if I manually
> >> > edit the rc files that work. If I use the GUI the program updates my
> >> > rc files for me. In this light, I see the present approach
> >> > (supporting a single .emacs file with all config/customizations in) as
> >> > rather more elegant and showcasing Emacs' expert manipulation of my
> >> > files.
> >> >
> >> > Emacs is one of the only programs I trust to edit files for me
> >> >
> >> > In any case, I would discourage efforts to complicate the minimum set
> >> > of user-space files required to effect a combination of configuration
> >> > and customizations. I hope that additional understanding of Emacs
> >> > would not be required to reenable this behavior if my perspective
> >> > isn't common among emacs users.
> >> >
> >> > Finally, it's unclear to me where the level of zeal toward changing
> >> > the current behavior is coming from. I can understand that people may
> >> > well not share my view. I don't understand the sense of urgency and
> >> > supercilious tone. Perhaps I can ask those who strongly disagree
> >> > with my perspective to also share personal stories of how their
> >> > proposed changes would have improved their own use of Emacs over the
> >> > years.
> >> >
> >> > TIA
> >>
> >>
> >> Hi, thanks for sharing your insights on this.
> >>
> >> I genuinely do not understand the difficulty and difference between
> >> having only a single file, or a directory of multiple files, among
> >> which you only edit one.  I'd appreciate reading your reasoning on it.
> >> What makes this more difficult than using multiple programs, which is
> >> hard to avoid for most computer use, each with their own configurations?
> >>
> >> The type of configuration files you describe have data-driven, easy to
> >> edit formats, which mitigates problems when edited from an interface.
> >> They are able to almost completely provide any type of customization
> >> possible for their purposes.  They are very different from the
> >> computational jungle init.el becomes in some users hands.  Unfortunately,
> >> there is also now early-init.el, which is the only way to do some things.
> >>
> >> But here's the thing; at least from my perspective if things go well you
> >> will still need only one file, the custom file. You will be able to have
> >> a majority of the customizations one would want to inside it, editable by
> >> hand or interface.  Exactly what you described.  If you still want to
> >> have some handwritten Elisp functions, those could be installed with
> >> package-install-file.  Only when you want to do involved changes to Emacs
> >> state, you would use early-init/init, which most users shouldn't have to.
> >>
> >> AFAIU from what is envisioned on this thread, you will not need any
> >> additional unserstanding of Emacs to have custom-set-* forms inside
> >> init.el in the short term.
> >>
> >>
>