From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thibaut Verron Newsgroups: gmane.emacs.devel Subject: Re: A modern-mode? Date: Thu, 17 Sep 2020 05:18:00 +0200 Message-ID: References: <87v9ge3tet.fsf@gkayaalp.com> <83bli57dug.fsf@gnu.org> <20200916213609.GA635@breton.holly.idiocy.org> Reply-To: thibaut.verron@gmail.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008fdc7005af79d5c2" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23820"; mail-complaints-to="usenet@ciao.gmane.io" To: Alan Third , Thibaut Verron , Eli Zaretskii , self@gkayaalp.com, akrl@sdf.org, emacs-devel , mardani29@yahoo.es Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 17 05:19:13 2020 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 1kIkRz-00063A-2E for ged-emacs-devel@m.gmane-mx.org; Thu, 17 Sep 2020 05:19:11 +0200 Original-Received: from localhost ([::1]:39380 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kIkRy-0003Nl-3T for ged-emacs-devel@m.gmane-mx.org; Wed, 16 Sep 2020 23:19:10 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47204) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kIkR6-0002di-Qe for emacs-devel@gnu.org; Wed, 16 Sep 2020 23:18:16 -0400 Original-Received: from mail-wr1-x442.google.com ([2a00:1450:4864:20::442]:39959) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kIkR4-00040I-Vn; Wed, 16 Sep 2020 23:18:16 -0400 Original-Received: by mail-wr1-x442.google.com with SMTP id j2so389501wrx.7; Wed, 16 Sep 2020 20:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to; bh=MabeVtT1l8YJdGgdgAG3+hylZwAfnWWRzPh5oa05bPY=; b=QhfFxS3EQ10mHfH+gSdSWcowtzf5Ma0fJvSAndFaI094QTwyD2OWXP6J/CG0mqCFDn +uPlP1ePUOPHRN8q3vuEueXaSwQBO1QG7nEoounv7ZVd9plhfMdyUpigCyyQDM1kDP2V G8UNzFBQ9eGnfYvNGGL4WByjqYcIrkutHmyM2/E4fclkOyNx7W9EJWWsorv3OVltKplE pt39UimjHOFr5Mq30DFC81xUgPXrIQeBuf8xjxkZ2yBz/KwbCf9EF/WmpUVYVPmyvhD2 aHKtFuwo/AayOTbct4hvqsOuxZNZ8IJgyROQfrU5ii7OSXKBFNw5GNohuiU4agiYygWM A0hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to; bh=MabeVtT1l8YJdGgdgAG3+hylZwAfnWWRzPh5oa05bPY=; b=JvwbtsW4obevI95ZygSnLUkgsYIaBZgRhycqD98UdpX5+6grgIjuz7L8czQCRIdD0Y RrG8n6sG2DDN6OPD0y8rnVMFiGwWIzRw5f5HKYLtEQNDCmEudVSRFYOPDKd8xIpZ8FMw LAuWMYAskaZkvZkPc+rY4uPZQUJz5BMsXzj1XG/tgfe6Mhyb+PuswGu7d8Kekw3GEpB6 CvZfvGzokep+Yw1BThoqM5ruxs2NWFJN9QxOvvvmCaLI50uKVaClHAqbEA6JVDM73iVw DQdqXR62gJIPHiGzUZQLU+KfzsEfyxN/qHgAvBqKjBBKoXpfGaXCM2CQH6GtD+amN9tR YI9w== X-Gm-Message-State: AOAM531+vzzWVrQrIgybwlAinkOO3o1ThaR9cjgFXFfMczvy3MpWeoTk V/qJdjZZz0SDW2EqCDakXtzdzMwu9NiHdT9jDj0= X-Google-Smtp-Source: ABdhPJx5R5PUTIk+syrHEOVmH6rwpox+BqA6EI1xIJHbtcAOUuIDWOIDX+iwYgWP71pxlZFQm0Y9frG1r1IgCQf1eks= X-Received: by 2002:a5d:4581:: with SMTP id p1mr30521132wrq.345.1600312692430; Wed, 16 Sep 2020 20:18:12 -0700 (PDT) In-Reply-To: <20200916213609.GA635@breton.holly.idiocy.org> Received-SPF: pass client-ip=2a00:1450:4864:20::442; envelope-from=thibaut.verron@gmail.com; helo=mail-wr1-x442.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:255949 Archived-At: --0000000000008fdc7005af79d5c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le mer. 16 sept. 2020 =C3=A0 23:36, Alan Third a =C3=A9cr= it : > On Wed, Sep 16, 2020 at 10:02:20PM +0200, Thibaut Verron wrote: > > I don't think that I'm the only one with this understanding, see for > > example the earlier post suggesting the name newbie-mode (synonymous > > to beginner-mode for me) with the idea that users would eventually > > grow out of this mode, like training wheels. I don't consider any of > > the suggested settings to be training wheels. > > It's the use of the theme (or mode) that's expected to be "grown out > of". As the user progresses they'll discover they like this, but they > don't like that, and now they have to make the choice of whether to > disable the theme and just enable the features they want in their > init.el, or enable the theme and try to disable the features they > don't want in their init.el. I think the latter option is less > desirable and probably harder to achieve. > > Perhaps the theme should come with documentation explaining what you > need to add to your init.el to achieve the same effects. > But why is that a good thing? The point as I understand it is that all those features were suggested to be activated by default (some of them are). Because we cannot so easily change the defaults, this mode gives an easy entry point to users wanting those defaults (even if they don't know it yet). If they were defaults we wouldn't expect the users to explicitly re-add them to their init.el (actually, if we did, there wouldn't be a problem with changing the defaults in the first place). So why treat this mode any differently? If this mode is implemented, I'd probably go the other route and remove the corresponding settings in my init.el and invoke the mode instead. Just as I would do with anything else I would be doing by hand but now comes built-in, to avoid duplicating the work of maintaining the code. As for disabling individual features, it's been suggested that the mode offers customization for its individual options, so there shouldn't be any need for elisp to activate or deactivate individual options. > --0000000000008fdc7005af79d5c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le mer. 16 sept. 2020 =C3=A0 23:36, Alan Third <alan@idiocy.org> a =C3=A9crit=C2=A0:
On Wed, Sep 16, 2020 at 10:02:20PM +0200, = Thibaut Verron wrote:
> I don't think that I'm the only one with this understanding, s= ee for
> example the earlier post suggesting the name newbie-mode (synonymous > to beginner-mode for me) with the idea that users would eventually
> grow out of this mode, like training wheels. I don't consider any = of
> the suggested settings to be training wheels.

It's the use of the theme (or mode) that's expected to be "gro= wn out
of". As the user progresses they'll discover they like this, but t= hey
don't like that, and now they have to make the choice of whether to
disable the theme and just enable the features they want in their
init.el, or enable the theme and try to disable the features they
don't want in their init.el. I think the latter option is less
desirable and probably harder to achieve.

Perhaps the theme should come with documentation explaining what you
need to add to your init.el to achieve the same effects.=C2=A0

But why is th= at a good thing? The point as I understand it is that all those features we= re suggested to be activated by default (some of them are). Because we cann= ot so easily change the defaults, this mode gives an easy entry point to us= ers wanting those defaults (even if they don't know it yet).=C2=A0

If they were defaults we wou= ldn't expect the users to explicitly re-add them to their init.el (actu= ally, if we did, there wouldn't be a problem with changing the defaults= in the first place). So why treat this mode any differently?=C2=A0

If this mode is implemented, I&= #39;d probably go the other route and remove the corresponding settings in = my init.el and invoke the mode instead. Just as I would do with anything el= se I would be doing by hand but now comes built-in, to avoid duplicating th= e work of maintaining the code.=C2=A0

As for disabling individual features, it's been suggested= that the mode offers customization for its individual options, so there sh= ouldn't be any need for elisp to activate or deactivate individual opti= ons.=C2=A0
--0000000000008fdc7005af79d5c2--