From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tim Cross Newsgroups: gmane.emacs.devel Subject: Re: light, dark, and theme adjustment & generation [was: solarized] Date: Fri, 18 Sep 2020 09:21:00 +1000 Message-ID: <87h7rw7zxf.fsf@gmail.com> References: <5a3685f0-a1dd-44f9-9e15-e8f1bc35ea57@default> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35448"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.5.5; emacs 27.1.50 To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 18 01:23:42 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 1kJ3Fe-00098A-Hh for ged-emacs-devel@m.gmane-mx.org; Fri, 18 Sep 2020 01:23:42 +0200 Original-Received: from localhost ([::1]:52488 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJ3Fd-00076T-Jk for ged-emacs-devel@m.gmane-mx.org; Thu, 17 Sep 2020 19:23:41 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJ3DG-0006Md-8d for emacs-devel@gnu.org; Thu, 17 Sep 2020 19:21:14 -0400 Original-Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]:36942) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJ3DB-0002Lr-VA for emacs-devel@gnu.org; Thu, 17 Sep 2020 19:21:14 -0400 Original-Received: by mail-pg1-x52a.google.com with SMTP id l71so2288207pge.4 for ; Thu, 17 Sep 2020 16:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version; bh=N8IOgD85CUZ9R20Q0I1XrH4ZY3bcX71Z7oqEUch2N14=; b=J4K7QvaZ2f6cG4hdIACee2Kk2k2R8/ly3gIcMEthwqx8O1OJKqO0JFwCMQZw3O0rdr NNOrUv9zYjYTvVvaCrlrLnckqiqLqCHeKOenHMfEwCwVIRcmm6qLdwr1w1pTSlcC/tGi w0JAqgiD6d3ncCzjVycDJvlhlor+BggYJ4useR8dsJuT6OmqJa8eG1KFf6Amoa2l2o9T b3Sj3LpeGwO7llI6dknlj2rZXcV6YSi7u86ZAmT23OeezQ2MjFZC05PUz9lXdIM3JDdN dxm9E5a6jhzvzYbS43idVjOSqWzKLTSipVGjEIhrz/huAs50Soi9sSvnziWbrWH1epZi vwbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject :in-reply-to:message-id:date:mime-version; bh=N8IOgD85CUZ9R20Q0I1XrH4ZY3bcX71Z7oqEUch2N14=; b=Id4s+5JFcbELSuTtChNKwWl0v6M5+hO1/weKasFd7+39KWI11yWnthmoL1HYTS/ZUE c3tq/hFZwB0lsbYI/S8kM8390qgcqPlL62EyytN1ljTkhkK/GZKUyiZlw9Oe6nt5iTe8 qy1EnEBR+aWnF9x/DRpawyssZdSwLaP8jN7jhCpiQmc95An3Z3eCB6XIsn57Wk8BEws3 2Xpvp9g8Za3wkGT1gM8QbKRy6akvgM14PvpGqhaFWGk/utYs2VrsKxMxRqSNaLkaGotX 4fz5IGsd5s206aRf6gDZmQezTx0hRZR7Ss8H6Y1r63MKvlI63ugdtM/dSPZoNa8KFlQW CC8Q== X-Gm-Message-State: AOAM533BgXUSjwCc2/Ta7GqEDCe2udYZloNF9iKgLssU6F52+eoasBTi 1ci2iLMkkhsWx4l35xr3X3MA+DjOtXg= X-Google-Smtp-Source: ABdhPJx0Y1sJnlyx/RuKnEiuCCAeM8YEDEGzMg1h0j/Q0dXEwrZO7JtlumTbkRxlmb2cOy1MuzWfBQ== X-Received: by 2002:a62:3706:0:b029:142:2501:39e5 with SMTP id e6-20020a6237060000b0290142250139e5mr13886395pfa.52.1600384865614; Thu, 17 Sep 2020 16:21:05 -0700 (PDT) Original-Received: from tim-desktop (106-69-95-142.dyn.iinet.net.au. [106.69.95.142]) by smtp.gmail.com with ESMTPSA id j19sm749138pfi.51.2020.09.17.16.21.03 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Sep 2020 16:21:04 -0700 (PDT) In-reply-to: <5a3685f0-a1dd-44f9-9e15-e8f1bc35ea57@default> Received-SPF: pass client-ip=2607:f8b0:4864:20::52a; envelope-from=theophilusx@gmail.com; helo=mail-pg1-x52a.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, 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:256038 Archived-At: Drew Adams writes: > I'm not advertising this as an Icicles feature. My > point is to suggest having tools to globally tweak > an appearance and create a theme from that. That > includes starting with some theme and tweaking it. > > Besides adjusting hue, saturation, and value, it would > be good to be able to adjust _contrast_. > I agree this would be a useful component. I have often found themes which I find to be 80% there, but just need a little tweaking to adjust hue, saturation or contrast, but the effort to do that by updating each face is a pain. I would suggest that any 'theme generator' would need such functionality. > Others have brought up theme generation. I'm not sure > what was meant by that, but what I describe here could > be considered a kind of theme generation, as well as a > kind of theme editing. > > IOW, besides customizing individual face settings in > a theme, it can be quite useful to be able to adjust > a set of faces used by a them _together_. > While everyone will have a different interpretation of what a theme generator is, my position is that it would provide a way to work with theme definition which reduces the need to work at the individual face level. You will still need this ability, but it would be great to have a way to work at a group or layer level. This would possibly require some more specific way of defining relationships between faces. > The Icicles commands that do this act on all faces. > But it could be helpful to be able to (easily, somehow) > limit such global tweaking to a particular subset of > faces. Agreed. Consistency will be important as well. A very common failure I've seen with attempts to provide an interface to manage themes is when the generated result is inconsistent. I recall the old way of customizing your theme under windows. The system work OK provided you wanted a theme with a light background. However, as soon as you wanted a theme with a dark background, you would suddenly have situations where you ended up with black/dark foreground faces on black/dark backgrounds. I've seen the same problems under various GNU Linux window managers and other applications. The challenge for Emacs will be how to ensure faces are categorised correctly. We can have algorithms to ensure certain levels of contrast etc, but if you don't have some way of classifying how/where the face is used, you cannot easily determine this. As any package can define new faces, this will be a challenge. It becomes an even greater challenge because packages and face definitions can be loaded at different times - how does any theme generator or customisation framework handle the situation where a face is not yet defined/known at the point when the tool runs? Do we just accept the tools work on a core set of faces and suggest that any package which defines a new face defaults to inherit from one of the core faces or do we implement some higher level abstraction which is used whenever a new face is loaded to define initial settings? -- Tim Cross