From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Corwin Brust Newsgroups: gmane.emacs.devel Subject: Re: Default custom file was: Re: Propose to add setup-wizard.el to ELPA Date: Thu, 20 Jan 2022 08:25:07 -0600 Message-ID: References: <87v8yuv03a.fsf@yahoo.com> <87r19iuzb5.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36419"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Emacs developers To: xenodasein@tutanota.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 20 22:01:59 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nAeZB-0009J2-Qk for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Jan 2022 22:01:57 +0100 Original-Received: from localhost ([::1]:55060 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nAeZ8-0001QL-K8 for ged-emacs-devel@m.gmane-mx.org; Thu, 20 Jan 2022 16:01:54 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39034) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nAYNP-0000b5-8t for emacs-devel@gnu.org; Thu, 20 Jan 2022 09:25:23 -0500 Original-Received: from mail-ed1-f48.google.com ([209.85.208.48]:46028) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nAYNM-00034z-Dl for emacs-devel@gnu.org; Thu, 20 Jan 2022 09:25:22 -0500 Original-Received: by mail-ed1-f48.google.com with SMTP id z22so29274246edd.12 for ; Thu, 20 Jan 2022 06:25:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wjCC1p8F9/fm2Yy6o1vprfCXh02vRX7iFm5/+A6AgrU=; b=RlkcHiFnQtjmvVdsMPGSlNR1P+vYoQTnf5jDqXwHTJUsD2oW81FNdjF5Hl/kK/tItB L0dKXPGaduRpoRIg6uCNVjN+3TjWahqPb5wxRqgQOna1oYeT/8OiNj3cLOe0gSaL+Pab 9LOE/8o1b5rCietKTFuFDm3bqeTR5NGCVdWASEirr5bghaGA4jJBw8n6+Rqp3DcUGL6Z BMuiiFGB6eYKqig69D241fM6/87uqqJJJjjHJQ7M6pzieNQqO39F8yT5yxNtEeA7PrEZ 4mouDZEiJXW8lmfiVE94ZDVUVPvyXRAW/Piga58kPGVvJ+FJOAMWoKHypnTQPELGrAcw ve3w== X-Gm-Message-State: AOAM531aXKq9b4vgFUpRrPnZQMS7Got9MVkPQYvtFZrGuUtr9VNhTqNs /ewc4iLvfA1+z3yeucbR5E8MmNyXd2MIgcdjoNE= X-Google-Smtp-Source: ABdhPJzJFoCEeJKd4aj9chzbLtGNZ0QthWD7D4hlZnMOg5Ibwp+bfcDBYYeuwZIh0g0eLS1FW0UOcgoUfwUKK/4Hgr4= X-Received: by 2002:a17:907:8a02:: with SMTP id sc2mr1269809ejc.448.1642688718146; Thu, 20 Jan 2022 06:25:18 -0800 (PST) In-Reply-To: Received-SPF: pass client-ip=209.85.208.48; envelope-from=mplscorwin@gmail.com; helo=mail-ed1-f48.google.com X-Spam_score_int: -13 X-Spam_score: -1.4 X-Spam_bar: - X-Spam_report: (-1.4 / 5.0 requ) BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:285052 Archived-At: 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 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. > >> > >> >