From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: master 0161c9d 1/2: Load all generic-x.el modes unconditionally Date: Wed, 10 Feb 2021 09:00:07 -0500 Message-ID: References: <20210209160550.18823.10795@vcs0.savannah.gnu.org> <20210209160551.832FB20AD1@vcs0.savannah.gnu.org> <87o8gti2ln.fsf@gnus.org> <83sg65jffx.fsf@gnu.org> <83im71j96z.fsf@gnu.org> <83czx8k3gn.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38616"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: larsi@gnus.org, stefan@marxist.se, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 10 15:03:05 2021 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 1l9q59-0009vg-4i for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Feb 2021 15:03:03 +0100 Original-Received: from localhost ([::1]:45118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l9q58-0003b8-1T for ged-emacs-devel@m.gmane-mx.org; Wed, 10 Feb 2021 09:03:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34646) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9q2Q-00029J-9V for emacs-devel@gnu.org; Wed, 10 Feb 2021 09:00:19 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7757) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l9q2N-0006az-L8; Wed, 10 Feb 2021 09:00:13 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 548AA4407ED; Wed, 10 Feb 2021 09:00:10 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EA49B4406A2; Wed, 10 Feb 2021 09:00:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1612965608; bh=LBDulvZGeJlj/ElnhYxjshczO+7CRQLrj6ynXu57GDk=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=SvTQ879k1PAPPQiZB2VQtFOq7LFN6ShxK16+efO++KJJBwXfp4Lk+2Y9NpxJpcYdj /bpv2dIZdWgdILJcwhlmsBD3VMxBAL+PNSbfrb46ohjs6F0B3K4aOFYtRKW6ej10qW i4xmZNmvgteynu+esq6WDjxoIoNNbnf0gtHOwGfCVrdJOs8Sy9fX+3WnRsNJ0PQfpC EgzHLS/EBpgLnINcE8Ox5OHewK7HH7tTsTGJmKNsWl/qh32WBregpb3t/PwcBktt7X RNuFaX1OCoK/tg1zNsYJ8bEeuEvbar7nHUn18dJcC1pGBdYRNwDrVIiBuvs4kV2X3G gUEudwlHIifNg== Original-Received: from alfajor (unknown [216.154.41.47]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A0DEA12027A; Wed, 10 Feb 2021 09:00:08 -0500 (EST) In-Reply-To: <83czx8k3gn.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 10 Feb 2021 05:26:48 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:264278 Archived-At: >> > I don't see a discussion, just an opinion that some variable should go >> > away. Can't we remove it without activating all the modes? >> [...] >> > How did you intend to handle the backward compatibility issues? >> >> I'm not sure which kinds of backward compatibility issues you're >> thinking of. >> >> AFAIK none of the functions defined in `generic-x` overlap with other >> packages, so there shouldn't be any conflict or >> backward incompatibility. >> >> What am I missing? > > What do we tell all those (myself included) who require generic-x in > their init files? I don't know what they need to be told. Can you clarify what broke or risks breaking because of the change? > And while at that: why did you think that variable was ugly and had > to go? Because a file that defines different sets of functions depending on some configuration variable tends to be problematic (I can't remember the exact issue that prompted my suggestion but it was related to that IIRC). Stefan