From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: "Themes" shipping configuration - an unusual convention Date: Thu, 30 Apr 2020 07:48:16 -0700 (PDT) Message-ID: <2e05cfdf-7c35-4154-8b7c-4adde4c4e454@default> References: <863691n4xl.wl-me@enzu.ru> <87imhw431x.fsf@yahoo.com> <87mu78huhx.fsf_-_@yahoo.com> <87k12bdgx7.fsf@yahoo.com> <83zhb6grtq.fsf@gnu.org> <83ftcwgb07.fsf@gnu.org> <291bb5b2-92d5-85f1-57d8-895eed14ffc2@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="2655"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Dmitry Gutov , =?utf-8?B?U8OpYmFzdGllbiBHZW5kcmU=?= , Emacs developers To: Stefan Kangas , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 16:49:55 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 1jUAVf-0000aB-Fr for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 16:49:55 +0200 Original-Received: from localhost ([::1]:50734 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUAVe-0001Gb-Db for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 10:49:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35930) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUAUT-0000i4-OU for emacs-devel@gnu.org; Thu, 30 Apr 2020 10:48:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUAUT-0001QD-25 for emacs-devel@gnu.org; Thu, 30 Apr 2020 10:48:41 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:55788) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jUAUN-0001Mt-OJ; Thu, 30 Apr 2020 10:48:35 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03UEcqQ6112722; Thu, 30 Apr 2020 14:48:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=UWOcqI6RCcwNkrJ73sxTXY2Dwptdl3bKGt9LztfaVnM=; b=iNFvtH9iEFeeTh45nquny07GHN8GrHBoeaoq8gZjHFzqufxQDX+lDOHStpF1T4rDVk7m mJJOIK8x9Ooj4ISbrjtKjyE53i/qBjxaFkwikz1ZMp164so1u6qbrnMxr3qrhptTdnsz dQxT/7XVxqlf+6Vtiui40v+Me0ctOR80PmJUWAzjcrkbGT09Pvtxn/firlPMKm3jDjuW KfVlts8VOmBbeRZrAJmPN4tVFzbSiijLbYVAvYaZQzYsVAexet22IqZryxccloApkFUF //hVyMpRKdTurvkaaHuowgSzd37Y/7OyKJYbnrVmzGJrkjEpyeqtjjvev8D3Fx6YFWH+ 4Q== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 30nucgbvjv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Apr 2020 14:48:33 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03UEmSm6145180; Thu, 30 Apr 2020 14:48:32 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserp3030.oracle.com with ESMTP id 30qtkwgrwr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 30 Apr 2020 14:48:30 +0000 Original-Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03UEmIAw027550; Thu, 30 Apr 2020 14:48:19 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4993.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9607 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 suspectscore=1 mlxscore=0 phishscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004300121 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9607 signatures=668687 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 priorityscore=1501 mlxlogscore=999 impostorscore=0 suspectscore=1 malwarescore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 adultscore=0 phishscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004300120 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/04/30 10:48:34 X-ACL-Warn: Detected OS = Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 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:248243 Archived-At: > So a theme can be used to change configuration, and indeed this is the > recommended way to do it. Interesting, and news to me. But is this a > good convention? I'm not so sure. >=20 > AFAIK, all other applications I have used understand "theme" to mean a > "package containing graphical appearance details"... >=20 > I don't think users will expect a "theme" to modify the behavior of > Emacs. There are usually things called "profiles" where one would > save or load settings from. This means that if M-x load-theme changes > the behavior of Emacs (significantly or otherwise), they are in for a > surprise. >=20 > I would propose to change the convention such that a "theme" is only > meant to modify "graphical appearance details". Not behavior. (From > what I can tell, all themes currently shipped with Emacs follow this > convention.[1]) >=20 > We could introduce a *separate* convention, called e.g. "custom > profiles", which are understood to also change settings. They could > have their own directory in our tree called "etc/profiles", and > separate commands to load them (say, M-x load-profile). >=20 > Of course, a "custom profile" could technically do anything a "theme" > does and vice versa. Just as a 'require'd package can technically > override any face, enable viper-mode or whatever. But we should > discourage that. ... > Footnotes: > 1. The exception is some variables related to > graphical display, which is not unusual or > surprising to my mind. I believe this is a principal difference between custom themes and color themes. Custom themes are essentially part of Customize, and from the outset they were about customizing options. Only later were they extended to do some (most) of what color themes do: define a color scheme by setting a bunch of faces, frame parameters etc. (That's my recollection anyway. Chong Yidong extended custom themes to implement some of what color themes provide.) Nowadays, the distinction has mostly been lost, unfortunately, and many people speak of "color themes" when they really mean vanilla Emacs custom themes. https://www.emacswiki.org/emacs/ColorThemes https://www.emacswiki.org/emacs/CustomThemes Your proposal seems to be to more or less limit Emacs custom themes to defining color schemes, or perhaps color schemes plus some other display properties.