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

[xenodasein]

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.