From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Protesilaos Stavrou Newsgroups: gmane.emacs.devel Subject: Re: ELPA: add lin.el Date: Sat, 06 Nov 2021 06:55:49 +0200 Message-ID: <87pmrdkhm2.fsf@protesilaos.com> References: <871r3uv1tk.fsf@protesilaos.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20989"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Notmuch/0.33.2 (https://notmuchmail.org) Emacs/29.0.50 (x86_64-pc-linux-gnu) Cc: emacs-devel To: Stefan Kangas Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Nov 06 05:56:48 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 1mjDl2-0005IJ-HM for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Nov 2021 05:56:48 +0100 Original-Received: from localhost ([::1]:59694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mjDl0-0005GX-QU for ged-emacs-devel@m.gmane-mx.org; Sat, 06 Nov 2021 00:56:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37244) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjDkF-0004ZV-70 for emacs-devel@gnu.org; Sat, 06 Nov 2021 00:55:59 -0400 Original-Received: from relay8-d.mail.gandi.net ([217.70.183.201]:44683) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjDkC-0005GB-6l for emacs-devel@gnu.org; Sat, 06 Nov 2021 00:55:58 -0400 Original-Received: (Authenticated sender: public@protesilaos.com) by relay8-d.mail.gandi.net (Postfix) with ESMTPSA id 8D6281BF203; Sat, 6 Nov 2021 04:55:51 +0000 (UTC) In-Reply-To: Received-SPF: none client-ip=217.70.183.201; envelope-from=info@protesilaos.com; helo=relay8-d.mail.gandi.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham 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:278841 Archived-At: On 2021-11-05, 13:28 -0700, Stefan Kangas wrote: > Protesilaos Stavrou writes: > >> The user can enable 'lin-mode' in select major modes to have a more >> intense (or just different) style for the highlighted line of >> 'hl-line-mode', without compromising the utility of the 'hl-line' face >> in all other buffers. > > This looks useful, thanks. My question is: why make it into a > third-party package instead of a patch against hl-line.el? The package has the upside that it can be used right away. Whereas changes in Emacs 29 will have to be followed by changes to all relevant downstream packages that need to style hl-line accordingly (I know of Elfeed, Mu4e, Notmuch). I suggest we do both: let the package exist and also patch hl-line.el. > I imagine that we could introduce a new permanently local defvar that > users (or even mode developers?) could set in individual modes. If > that variable is non-nil, these faces are used instead of the default > ones. We could also have a defcustom that disables this completely (I > think it should be on by default, but we can bikeshed that later). > > We could also just include the mode of course, if we think that's the > better interface. I sort of like the variables, as that allows modes to > "register" themselves as interesting for this purpose, and the user to > completely disable the functionality if they don't like it by setting a > defcustom. (Instead of all users having tons of mode-hooks in their > configuration for each and every little mode where this could make > sense.) > > What do you think? I think having major modes register themselves in that way is the best outcome. The presence of a separate minor-mode/package is just a way to work around the current constraints. -- Protesilaos Stavrou https://protesilaos.com