From unknown Wed Sep 24 15:22:00 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#79481 <79481@debbugs.gnu.org> To: bug#79481 <79481@debbugs.gnu.org> Subject: Status: global-hl-line buffers Reply-To: bug#79481 <79481@debbugs.gnu.org> Date: Wed, 24 Sep 2025 22:22:00 +0000 retitle 79481 global-hl-line buffers reassign 79481 emacs submitter 79481 Juri Linkov severity 79481 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 21 13:07:05 2025 Received: (at submit) by debbugs.gnu.org; 21 Sep 2025 17:07:05 +0000 Received: from localhost ([127.0.0.1]:55791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0NWi-0007NV-Nc for submit@debbugs.gnu.org; Sun, 21 Sep 2025 13:07:05 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59348) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v0NWe-0007My-Ne for submit@debbugs.gnu.org; Sun, 21 Sep 2025 13:07:01 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1v0NWU-0004hz-Ia for bug-gnu-emacs@gnu.org; Sun, 21 Sep 2025 13:06:50 -0400 Received: from mout-p-103.mailbox.org ([80.241.56.161]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim 4.90_1) (envelope-from ) id 1v0NWK-0003wu-CR for bug-gnu-emacs@gnu.org; Sun, 21 Sep 2025 13:06:45 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [10.196.197.102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-103.mailbox.org (Postfix) with ESMTPS id 4cVCMG2LdRz9spj for ; Sun, 21 Sep 2025 19:06:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1758474394; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=cHswYQrP8FzE67WguPyyK+iV3cjC5jywjirO4uXwvTU=; b=jd70ATshsl4dwqpL24Vcc/bZn+pIJwgKnr6gVywuh1fzDBflI5CNcOZDgX+I1x3qlnL0Nw BsFAQN1D0W71zZULc5DK+feoaqufhKyPifTGZTTU2mrPbG4XVf1skYp3iNU6mt5orNL7LD ZDpotqyXiqj/eNtUsWLS/CTImxA8EPe/zwGc4uiI/6X0bzsvjfG8+Pj7p+TZ3LyupXDXGg WnfZnBZbk+O97uCTpJ6wjwbK3D/ez0DRuP0hZ2OgyktL7Z2wp1AYl9F7d8EcXv1dvvolKG Rd7AWFThBp5gdkOFjvnenF3aK0mpw9LQxRoRIOagKJ+QR0kQO/4R6NHKzpSm7w== From: Juri Linkov To: bug-gnu-emacs@gnu.org Subject: global-hl-line buffers Organization: LINKOV.NET X-Debbugs-Cc: eg642616@gmail.com Date: Sun, 21 Sep 2025 20:05:20 +0300 Message-ID: <87segfzqjr.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=80.241.56.161; envelope-from=juri@linkov.net; helo=mout-p-103.mailbox.org X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Recently we added 'tab-line-exclude-buffers' that is checked by 'buffer-match-p'. Shouldn't we now rename 'global-hl-line-modes' to something like 'global-hl-line-buffers' and use 'buffer-match-p', given that it was added in 31.1, so there is no need to provide an alias for deprecation. From debbugs-submit-bounces@debbugs.gnu.org Sun Sep 21 18:26:23 2025 Received: (at 79481) by debbugs.gnu.org; 21 Sep 2025 22:26:23 +0000 Received: from localhost ([127.0.0.1]:57645 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0SVi-0007r2-Ry for submit@debbugs.gnu.org; Sun, 21 Sep 2025 18:26:23 -0400 Received: from mail-oa1-x42.google.com ([2001:4860:4864:20::42]:43428) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1v0SVe-0007pk-Oq for 79481@debbugs.gnu.org; Sun, 21 Sep 2025 18:26:19 -0400 Received: by mail-oa1-x42.google.com with SMTP id 586e51a60fabf-31d8778ce02so3754364fac.1 for <79481@debbugs.gnu.org>; Sun, 21 Sep 2025 15:26:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758493572; x=1759098372; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=3uFuLE+2ne6+MeCd1rKyZiU1ZbyE0MJupLymO+vYtJo=; b=VSm9ng59odBkRWHToRuVm6YAi94U2jSJN8AOpYqdhoOE7xcSaVv9xiKE6xtGbKvJZZ GvEoaJPJS97uEuOaaf8lpxIHVGcfAL8GROMmQmQkOtGuT0W5XK7aioAit/NgrF6hLIHu CHU/OOwTubN2dX1ls+M7Hid4dpKVHIjLimsBhCSk9lhKjXEUKcf/xziWTdMo8wvWoBRi dA1OGUl9fi/uQT5K1lGuM0H3vQ+aTHekg6c30n4kMIxaqGN5DGFwJJwr+hIdyh/PJnBq TblMBUOM0G7eFQOXJJNpGEysyWlnq+vXBs+J+zzHDRvKWEW6YLmXZrP2nPo7KThWx3Wm hkKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758493572; x=1759098372; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=3uFuLE+2ne6+MeCd1rKyZiU1ZbyE0MJupLymO+vYtJo=; b=mIOALa8zs7vUBE0OaEcFGuPsTD9LN+CrXjwA6uOpcPlpx8w2LKHLQVDI+RtFZZVb9F j2OptXt6Es+tiPPyoCYjbVenE7nvrwUBYroikYOBUZUf5+PG486pkEP4NBbk04dn5Gxa O+YZ7AL5Orx1nNhVyB4r3m9ywVoFFWXSVPCeSrOxI/8Pr5Gp2dZIrUESbWojTb7bs0uG sZc0Wo7/l3AyByB9R50lyZued1Ln2JekfJa4zwgmH6I0LZcqb0g0eHpvwae09yXxX3PZ lvajjw0u6U/vexh3s9E5ZZ8QqpbjaL5855d8ZngkO3iRnKnZ5ZuplFAzUHSpbbEV/45O 60HA== X-Gm-Message-State: AOJu0YzFJbkLdopM09BQdjdxqs75W5D1hby7eKFGlxw7QqVkJ6kL3Eql ev5q9iNyi/NIKJqFsgbrse/rDrvlD3ZfrgxuLRs7hPMx0z6W90f6yBUCzkB5zRwU X-Gm-Gg: ASbGncvTUM0pQKHEIq4u9sFulhiDGOd8mu1zT1J/8RD/ZATqmdje/vLLfJzh4HFnMF8 lOnRe1Hv2cH2WsHx9p3Lvwt7NjEv6hFHCE0BAcgDseCxIABDa3hSEnI7M5sma9v7j+bxYTHBaZl IS3e5fKEvNOO1UHHB66TDQBQAm53WSTQZcQQ5O3bEVFudkprNJOoy/5Y9WD2JvRBFrL6I1PsuNe noHLsFQ64WA0wAr+R7NbSAf8+BmUfDP+TmYRnlFgwqfqaLEXbUPP+RuYIvk06s34fD+bAeO6PD4 qFCUo1i0Tvji5kfNDCHjB3czGi0FxoXnT4oXOeccokIAfw0ot/obgG0rul3vVaT8WssRhSQLInH ++0FCd9Qn0FeS1FQe X-Google-Smtp-Source: AGHT+IGoJI4PkVmwo0h4k3CCGNXwNUkV35hrVhAU9niJRiPgHCjUDsnvZcOijxVqY7lmxBBtK9d3vw== X-Received: by 2002:a05:6871:3618:b0:332:bcc6:e02d with SMTP id 586e51a60fabf-336d0f381bfmr8026271fac.3.1758493571842; Sun, 21 Sep 2025 15:26:11 -0700 (PDT) Received: from fedora ([189.215.165.139]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7692a974e1dsm5204379a34.34.2025.09.21.15.26.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Sep 2025 15:26:11 -0700 (PDT) From: =?utf-8?Q?Elijah_Gabe_P=C3=A9rez?= To: Juri Linkov Subject: Re: bug#79481: global-hl-line buffers In-Reply-To: <87segfzqjr.fsf@mail.linkov.net> References: <87segfzqjr.fsf@mail.linkov.net> Date: Sun, 21 Sep 2025 16:26:09 -0600 Message-ID: <87bjn330ji.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/31.0.50 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.3 (/) X-Debbugs-Envelope-To: 79481 Cc: 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) Juri Linkov writes: > Recently we added 'tab-line-exclude-buffers' > that is checked by 'buffer-match-p'. > > Shouldn't we now rename 'global-hl-line-modes' to something like > 'global-hl-line-buffers' and use 'buffer-match-p', given that it was > added in 31.1, so there is no need to provide an alias for deprecation. I don't have problem with that, you can do the change, IME `buffer-match-p` is a better and powerful alternative to `easy-mmode--globalized-predicate-p`, however the `buffer-predicate` type does not have a complete UI for `Customize` yet. -- - E.G via Gnus and Org. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 22 01:01:35 2025 Received: (at 79481) by debbugs.gnu.org; 22 Sep 2025 05:01:35 +0000 Received: from localhost ([127.0.0.1]:60168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0YgA-00082S-7r for submit@debbugs.gnu.org; Mon, 22 Sep 2025 01:01:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43468) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v0Yg1-00081u-E4 for 79481@debbugs.gnu.org; Mon, 22 Sep 2025 01:01:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1v0Yfv-0008BM-FH; Mon, 22 Sep 2025 01:01:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DJtV6L9rHZQBG/KZBIVIweIKYl2uhMMMhxQOLIXHpC8=; b=PpbUvMSwl7/5 6KoZtRJi2SQMjPAmmT7c+VRAXE9jaHgwfizocomAVgic138QCTU3xiJCfXfK3Iu0bWC8KYC4vxF7j I8fFQokmBaP9WUZ7Yee7R8+GHrhxPiVOQYTrdXL2nNBRDziaxSdIQvDDRwzGfdZu7hl0JlCk9u78y hxwwvrVD7y7lZoPUSbZwx8LW4VO5K7lmx/EuCQRb73Pa2Bib9OfBNxMX1BXyP0Ypa5dZxuV42wzDO Ga3iNxauCqpowz5qdS3mVYkj5VSIhO0MOPf/QO87Yfp26/ImiT4r6cXRos4lFtnfNUzrowOMeyMNy PtdajMWaSc4FloFTVTLJXA==; Date: Mon, 22 Sep 2025 08:01:15 +0300 Message-Id: <86ecrzf5d0.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-Reply-To: <87segfzqjr.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 21 Sep 2025 20:05:20 +0300) Subject: Re: bug#79481: global-hl-line buffers References: <87segfzqjr.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79481 Cc: eg642616@gmail.com, 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: eg642616@gmail.com > From: Juri Linkov > Date: Sun, 21 Sep 2025 20:05:20 +0300 > > Recently we added 'tab-line-exclude-buffers' > that is checked by 'buffer-match-p'. > > Shouldn't we now rename 'global-hl-line-modes' to something like > 'global-hl-line-buffers' and use 'buffer-match-p', given that it was > added in 31.1, so there is no need to provide an alias for deprecation. What is the plan here? Are we going to do something like that with all the globalized modes? only with some of them? if the latter, which ones? IOW, if there's an intent to make similar changes in other minor modes, we should probably discuss some general mechanism for doing that, before we go out and make the changes one mode at a time. One question that I'd like answered is how come we never needed anything like that until now? From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 22 02:42:50 2025 Received: (at 79481) by debbugs.gnu.org; 22 Sep 2025 06:42:50 +0000 Received: from localhost ([127.0.0.1]:60493 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0aG9-0005RO-Lg for submit@debbugs.gnu.org; Mon, 22 Sep 2025 02:42:49 -0400 Received: from mout-p-102.mailbox.org ([80.241.56.152]:54776) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v0aG8-0005R7-6q for 79481@debbugs.gnu.org; Mon, 22 Sep 2025 02:42:48 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4cVYSw3tdCz9tcd; Mon, 22 Sep 2025 08:42:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1758523360; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wJvRMylWW2ArJe/ftBnEwoUSkm10wg+S0gjPWlgGNgo=; b=eEW4BzTwFzHwAsYgG846DisC4ioUtWFhvKPkFtnyJkYCFb6JH829gM+IyMK/lsOeijdBaG cGuLJV23X46z47djKG2foueCj3p5Dwxh+lU6b2LXbNojZ+rhqrcc5Hcx50bXAwvmg/Mg9F CZ9ZW1j35CG9BY9DiERmTmYepmMqEIVoAHY3lZMCfmcnLtvD1dQdzSlbe984DNOwEUv5p6 65z/GuEqT/pXIvTNG+rIhknvLXtDWYj18tdOvpg5/z+OjYf6nFZEvlzbiH7WJa/OUq2BZ3 eXrt+C+Y0Vt7bDqBOJVEOU08l2jEOgTmASoWwpic21HPq+Z2LYZwkl7UlBXz+g== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::102 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#79481: global-hl-line buffers In-Reply-To: <86ecrzf5d0.fsf@gnu.org> Organization: LINKOV.NET References: <87segfzqjr.fsf@mail.linkov.net> <86ecrzf5d0.fsf@gnu.org> Date: Mon, 22 Sep 2025 09:39:30 +0300 Message-ID: <87ikhbousd.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4cVYSw3tdCz9tcd X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79481 Cc: eg642616@gmail.com, 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Recently we added 'tab-line-exclude-buffers' >> that is checked by 'buffer-match-p'. >> >> Shouldn't we now rename 'global-hl-line-modes' to something like >> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was >> added in 31.1, so there is no need to provide an alias for deprecation. > > What is the plan here? Are we going to do something like that with > all the globalized modes? only with some of them? if the latter, which > ones? > > IOW, if there's an intent to make similar changes in other minor > modes, we should probably discuss some general mechanism for doing > that, before we go out and make the changes one mode at a time. One > question that I'd like answered is how come we never needed anything > like that until now? One possibility is to add a new keyword like e.g. ':filter' (define-globalized-minor-mode global-tab-line-mode tab-line-mode tab-line-mode--turn-on :filter 'tab-line-exclude-buffers that will enable buffer-local mode selectively according to the filter option. But this could work only for 'define-globalized-minor-mode', not for global modes that use global hooks like this: (define-minor-mode global-hl-line-mode :global t :filter 'global-hl-line-buffers From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 22 03:06:54 2025 Received: (at 79481) by debbugs.gnu.org; 22 Sep 2025 07:06:54 +0000 Received: from localhost ([127.0.0.1]:60581 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0adS-0006rR-Gf for submit@debbugs.gnu.org; Mon, 22 Sep 2025 03:06:54 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:45984) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v0adQ-0006rA-5Y for 79481@debbugs.gnu.org; Mon, 22 Sep 2025 03:06:52 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1v0adJ-0001ju-RC; Mon, 22 Sep 2025 03:06:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2kAtseD9f5fb3Z8E5bN7waC/vtHwh0eVb1SkqRPG4Qg=; b=XeuDwCMkmhqk CHld/21s0AkdbnJT7/naI3HhqFHBG3knBQjeAfEMhUArASD5whjMNTPl7k9WAdTHUbdaecYs61muG 8ybc8LJbORtnuj2MDjkMEKNi4GkXUXOv8ezYyeRTnzM6c61zgnnG5VozKO9FH6Vkep49AA0Z5PMOi /nWVly1kSrp6qypudDJgiBn36BriO8X0E2oitV2og5iHbP3XaAEFV7MCNy1MbrrxrEpIXZS0xlotS KcQMDl558DVWW/f4tv911yknpd/wB8z4oYg2hvv5gJR2aBue+lAGzypVaaBPPCDQvf7C9J8SrzzfJ ITy1FIlyg0XL00k4XZikOw==; Date: Mon, 22 Sep 2025 10:06:39 +0300 Message-Id: <86tt0vdkzk.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov , Stefan Monnier In-Reply-To: <87ikhbousd.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 22 Sep 2025 09:39:30 +0300) Subject: Re: bug#79481: global-hl-line buffers References: <87segfzqjr.fsf@mail.linkov.net> <86ecrzf5d0.fsf@gnu.org> <87ikhbousd.fsf@mail.linkov.net> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79481 Cc: eg642616@gmail.com, 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Juri Linkov > Cc: 79481@debbugs.gnu.org, eg642616@gmail.com > Date: Mon, 22 Sep 2025 09:39:30 +0300 > > >> Recently we added 'tab-line-exclude-buffers' > >> that is checked by 'buffer-match-p'. > >> > >> Shouldn't we now rename 'global-hl-line-modes' to something like > >> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was > >> added in 31.1, so there is no need to provide an alias for deprecation. > > > > What is the plan here? Are we going to do something like that with > > all the globalized modes? only with some of them? if the latter, which > > ones? > > > > IOW, if there's an intent to make similar changes in other minor > > modes, we should probably discuss some general mechanism for doing > > that, before we go out and make the changes one mode at a time. One > > question that I'd like answered is how come we never needed anything > > like that until now? > > One possibility is to add a new keyword like e.g. ':filter' > > (define-globalized-minor-mode global-tab-line-mode > tab-line-mode tab-line-mode--turn-on > :filter 'tab-line-exclude-buffers > > that will enable buffer-local mode selectively > according to the filter option. > > But this could work only for 'define-globalized-minor-mode', > not for global modes that use global hooks like this: > > (define-minor-mode global-hl-line-mode > :global t > :filter 'global-hl-line-buffers I added Stefan to the discussion, in the hope that he might have comments or suggestions. From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 22 11:11:39 2025 Received: (at 79481) by debbugs.gnu.org; 22 Sep 2025 15:11:40 +0000 Received: from localhost ([127.0.0.1]:35065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0iCZ-0004xd-HL for submit@debbugs.gnu.org; Mon, 22 Sep 2025 11:11:39 -0400 Received: from mout-p-201.mailbox.org ([2001:67c:2050:0:465::201]:44642) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v0iCP-0004wb-6z for 79481@debbugs.gnu.org; Mon, 22 Sep 2025 11:11:33 -0400 Received: from smtp102.mailbox.org (smtp102.mailbox.org [IPv6:2001:67c:2050:b231:465::102]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4cVmlp2HPXz9tfF; Mon, 22 Sep 2025 17:11:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1758553878; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=6RfJ+llsKWwJrJXhtcDw8FKoY6z1tYfNe2GivXzfNWM=; b=sXWJ4/XdNHJZN6n/06A1WuLsisu601tFi5OZnZ6e1Rni1Wpz/XnEFmQjF3AfEpXxgjByJO kO/+L2rEQIIwBKOWQX41Zra+pMd5QGXeWm88B+XCnPk2GfIJOhFJBbcgsAWJHAJO8ZU+3A 6BgnzAUUXSd4NYwcVPJ7l5HhZFQUjhB9KhzR+pwK3QYf3idUK6NuGxu4zeUicHclv92J53 IfCWwrXZb2hOrhYP9lMajYgfpCvsIK1OECtfEAr2I5MYWep2OWrlZ8xoBD8bf3Qi8ZamO0 Crayp37OOvaBIVZz2QXV9YUZltQc7B4V48jxjBkrZ0SVSfPojX+pPMuVaVcV0Q== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::102 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Elijah Gabe =?iso-8859-1?Q?P=E9rez?= Subject: Re: bug#79481: global-hl-line buffers In-Reply-To: <87bjn330ji.fsf@gmail.com> Organization: LINKOV.NET References: <87segfzqjr.fsf@mail.linkov.net> <87bjn330ji.fsf@gmail.com> Date: Mon, 22 Sep 2025 18:03:06 +0300 Message-ID: <87wm5qiqw9.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Rspamd-Queue-Id: 4cVmlp2HPXz9tfF X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 79481 Cc: 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain >> Recently we added 'tab-line-exclude-buffers' >> that is checked by 'buffer-match-p'. >> >> Shouldn't we now rename 'global-hl-line-modes' to something like >> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was >> added in 31.1, so there is no need to provide an alias for deprecation. > > I don't have problem with that, you can do the change, IME > `buffer-match-p` is a better and powerful alternative to > `easy-mmode--globalized-predicate-p`, Do you think we should add the word "exclude" to the name? Or it's fine to require using 'not' in the condition? > however the `buffer-predicate` type does not have > a complete UI for `Customize` yet. Here is the patch that makes possible the customization of all `buffer-predicate` conditions recursively: --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename=buffer-predicate-widget.patch diff --git a/lisp/wid-edit.el b/lisp/wid-edit.el index 311e39f4c0f..4e2e88c7dfa 100644 --- a/lisp/wid-edit.el +++ b/lisp/wid-edit.el @@ -4387,12 +4387,35 @@ 'widget-visibility-value-create ;;; Buffer predicates. (define-widget 'buffer-predicate 'lazy - "A buffer predicate." + "A buffer predicate for the condition argument of `buffer-match-p'." :tag "Buffer predicate" :type '(choice (const :tag "All buffers" t) (const :tag "No buffers" nil) - ;; FIXME: This should be expanded somehow. - sexp)) + (regexp :tag "Buffer name regexp") + (function :tag "Predicate function") + (cons :tag "Category" + (const category) + (symbol category)) + (cons :tag "This command" + (const this-command) + (symbol this-command)) + (cons :tag "Major mode" + (const major-mode) + (symbol major-mode)) + (cons :tag "Derived mode" + (const derived-mode) + (symbol derived-mode)) + (cons :tag "Not" + (const not) + (buffer-predicate :tag "not-condition")) + (cons :tag "Or" + (const or) + (repeat :tag "List of or-conditions" + buffer-predicate)) + (cons :tag "And" + (const and) + (repeat :tag "List of and-conditions" + buffer-predicate)))) (provide 'wid-edit) --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 22 16:45:30 2025 Received: (at 79481) by debbugs.gnu.org; 22 Sep 2025 20:45:31 +0000 Received: from localhost ([127.0.0.1]:36302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v0nPe-0002J9-Cp for submit@debbugs.gnu.org; Mon, 22 Sep 2025 16:45:30 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12586) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v0nPb-0002Io-1V for 79481@debbugs.gnu.org; Mon, 22 Sep 2025 16:45:27 -0400 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 6FA1544258C; Mon, 22 Sep 2025 16:45:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1758573920; bh=6zDzSxbzWs6IYsGRc5XC5v1+lUaWXGzbjlU+i6NjJ88=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=hVtC17iWz2W0vrXPCUhXVl0Ib4EvStDAjKu9DA8dF75k/nKB9uOTDt+yosG02/cYJ k/GX5OsEoF62Ps/D9/KZ6aWb944+0fnVer0P3eMfBB6KCHD+L32/0YsN8huXgJMU5z 3smQBMYGr5/edwfKIOaMjbWimjARE/p/oJ7PK6Ag1sZ+iHU/3psVg2qpxoPRUPiDRM rZb3iHBbJMCbi/18pgsSjPcJCg8uZO7S7uEkwR+EtFqjhJUPdQdviVlsLwsSTaXosD Un7W9DJisyv9a/2NbrNkrT2X+BA+4lidYWYW9eTA+wnrcTbz+tZbNe+TsypLpz7drL 7Mw0RwCwTV3QQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3317844255D; Mon, 22 Sep 2025 16:45:20 -0400 (EDT) Received: from pastel (104-195-250-137.cpe.teksavvy.com [104.195.250.137]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0036A120352; Mon, 22 Sep 2025 16:45:19 -0400 (EDT) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#79481: global-hl-line buffers In-Reply-To: <86tt0vdkzk.fsf@gnu.org> Message-ID: References: <87segfzqjr.fsf@mail.linkov.net> <86ecrzf5d0.fsf@gnu.org> <87ikhbousd.fsf@mail.linkov.net> <86tt0vdkzk.fsf@gnu.org> Date: Mon, 22 Sep 2025 16:45:19 -0400 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.412 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79481 Cc: eg642616@gmail.com, 79481@debbugs.gnu.org, Juri Linkov X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> One possibility is to add a new keyword like e.g. ':filter' >> >> (define-globalized-minor-mode global-tab-line-mode >> tab-line-mode tab-line-mode--turn-on >> :filter 'tab-line-exclude-buffers >> >> that will enable buffer-local mode selectively >> according to the filter option. We don't need yet-another-keyword for that, we can do the filtering inside `tab-line-mode--turn-on` (that's why we have two arguments, `tab-line-mode` and `tab-line-mode--turn-on`). If that kind of need is very frequent for globalized minor modes, we could consider adding such a feature directly in the macro, of course, but it's a bit delicate since it would tend to "fight" with the filtering done within the TURN-ON function: we'd probably need to provide both a way to exclude some buffers and a way to include buffers (which TURN-ON would otherwise skip). So, I hope "YAGNI" does the trick here. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 24 13:16:22 2025 Received: (at 79481) by debbugs.gnu.org; 24 Sep 2025 17:16:23 +0000 Received: from localhost ([127.0.0.1]:50556 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v1T6L-0004lS-Do for submit@debbugs.gnu.org; Wed, 24 Sep 2025 13:16:22 -0400 Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]:60682) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v1T6D-0004jB-Q3; Wed, 24 Sep 2025 13:16:15 -0400 Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4cX3Qr5mG7z9tJ0; Wed, 24 Sep 2025 19:16:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1758734164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Mbgewn+SGOAXEXF/5l5JK1lPc830WFuse9Y7qlyUiKM=; b=FZL/IKqEixkRrrsPm9jEqKUwxwbQ9501njfdSLc8C41HXI97a/VJcEllW00lE+BFViUQl5 Wm/7Jz214P/OQTog67YVEZEawBpg6CfK4gWLW+bRKVD7UIPbgT+AFJSB5VfseNJdEXd2hz qaSTY3/MXr46A+8mflH1mrlAzNwseEhjqXsEMvj74RqcOroo3qcxzgW4SVCkFMCgOvS2w4 JnFQRcXft3ib5EmhUsBZ5A8TY+8EpvZ+lJKDnYVI77XKGvmdy0L4zga2eQitlaqSiJeJjH nWfzZkfjWcSnVH/wqh4XZ/KKhUi4kSFkBy1Ur30AzTeCenObln+N+KFvMNFTsw== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::2 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Elijah Gabe =?iso-8859-1?Q?P=E9rez?= Subject: Re: bug#79481: global-hl-line buffers In-Reply-To: <87wm5qiqw9.fsf@mail.linkov.net> Organization: LINKOV.NET References: <87segfzqjr.fsf@mail.linkov.net> <87bjn330ji.fsf@gmail.com> <87wm5qiqw9.fsf@mail.linkov.net> Date: Wed, 24 Sep 2025 20:14:31 +0300 Message-ID: <875xd7vklk.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4cX3Qr5mG7z9tJ0 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79481 Cc: 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) close 79481 31.0.50 thanks >>> Recently we added 'tab-line-exclude-buffers' >>> that is checked by 'buffer-match-p'. >>> >>> Shouldn't we now rename 'global-hl-line-modes' to something like >>> 'global-hl-line-buffers' and use 'buffer-match-p', given that it was >>> added in 31.1, so there is no need to provide an alias for deprecation. >> >> I don't have problem with that, you can do the change, IME >> `buffer-match-p` is a better and powerful alternative to >> `easy-mmode--globalized-predicate-p`, > > Do you think we should add the word "exclude" to the name? > Or it's fine to require using 'not' in the condition? For example, 'show-paren-predicate' uses 'not' in the default value, so I added 'not' to 'global-hl-line-buffers' as well. >> however the `buffer-predicate` type does not have >> a complete UI for `Customize` yet. > > Here is the patch that makes possible the customization > of all `buffer-predicate` conditions recursively: Now pushed and closed. From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 24 14:29:23 2025 Received: (at 79481) by debbugs.gnu.org; 24 Sep 2025 18:29:23 +0000 Received: from localhost ([127.0.0.1]:50956 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v1UF0-0007LA-Tv for submit@debbugs.gnu.org; Wed, 24 Sep 2025 14:29:23 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:48875 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v1UEv-0007Kf-QP for 79481@debbugs.gnu.org; Wed, 24 Sep 2025 14:29:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ukuTSkELvi59Cqnb7/RMf/xwg8Sx5uyrsS7NwCo5aP8=; b=ao//hDw7wvvN+ooF7NJunNT18n Xn6u8bDqsuetR3Y6akSM2dOxpLAxRh8nHXDxWBkAWifq2dPUrYSCGCLwZG/re8VPfTCicMzl6J5Qj zX293U0sV0VgdXzS88iiq1+T4g6n2PIdANO/o7rSyH2x4ZqsxT71cd4k7VCzBPyhCL+0=; From: Daniel Mendler To: 79481@debbugs.gnu.org Subject: global-hl-line-buffers - why not :predicate? Date: Wed, 24 Sep 2025 20:29:07 +0200 Message-ID: <87y0q31z7w.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79481 Cc: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Hello Juri, I wonder about the motivation for the introduction of `global-hl-line-buffers', which is different from the `global-*-modes' variables provided by other globalized minor modes via the `:predicate' argument of `define-globalized-minor-mode'. See for example `global-completion-preview-mode' which is defined as follows: (define-globalized-minor-mode global-completion-preview-mode completion-preview-mode completion-preview-mode :predicate '((not archive-mode calc-mode compilation-mode diff-mode dired-mode image-mode minibuffer-mode minibuffer-inactive-mode org-agenda-mode special-mode wdired-mode) t)) The `:predicate' key here generates the `global-completion-preview-modes' variable with the value `((not archive-mode ...) t)'. I figured that `global-hl-line-mode' is not simply a globalized minor mode. But maybe it could be at some point in the future? Therefore it might be better to stay consistent with other global minor mode predicate variables and rename `global-hl-line-buffers' back to `global-hl-line-modes'? Is there a need for the additional functionality of `buffer-match-p' vs `easy-mmode--globalized-predicate-p'? As far as I understand `buffer-match-p' supports more filter conditions, but do we need anything beyond filtering by mode? Thanks! Daniel From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 24 14:50:54 2025 Received: (at 79481) by debbugs.gnu.org; 24 Sep 2025 18:50:54 +0000 Received: from localhost ([127.0.0.1]:51118 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v1UZp-0001Np-Nv for submit@debbugs.gnu.org; Wed, 24 Sep 2025 14:50:54 -0400 Received: from mout-p-101.mailbox.org ([80.241.56.151]:52920) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v1UZl-0001Mk-DX for 79481@debbugs.gnu.org; Wed, 24 Sep 2025 14:50:51 -0400 Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4cX5Wy2TCCz9svK; Wed, 24 Sep 2025 20:50:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linkov.net; s=MBO0001; t=1758739838; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wi8Z/8MpU9X3f0UKNSYN+lTlkxJ0FfsFmmhRw+nXMWk=; b=aaFOpdhtcZwLbGi6KghyIeFG0/TVBNrvxOpuDEkxXATHJAa6bwg1/ThkaM6qQ9aqecMSRz TsFV1lkVuQey3oI80nyn0nRCKlghJgaVg/KZ0tHwnS1tCwcIHVbP2yycke3tqU65tHV7UV jMpgHxo8M+WKmKJ2Ak9EkB0U81EoXJhDPjD3BYwhe92dzJeZbEkBiWsUSW9rEAn/Zul9Hn 8PHMyIKX3GDfnrgqmRvMxEU22+0aCeFYxWhVxihOJBqVySJkHK7CcJUhZ56P7OwB1dE9y8 2aIp1jy0XQisSjZw79AWA4qY4v1ZjvDPzdxY6LuVqEYsZxZ5DoYEkwK/bezjRQ== Authentication-Results: outgoing_mbo_mout; dkim=none; spf=pass (outgoing_mbo_mout: domain of juri@linkov.net designates 2001:67c:2050:b231:465::202 as permitted sender) smtp.mailfrom=juri@linkov.net From: Juri Linkov To: Daniel Mendler Subject: Re: bug#79481: global-hl-line-buffers - why not :predicate? In-Reply-To: <87y0q31z7w.fsf@daniel-mendler.de> Organization: LINKOV.NET References: <87segfzqjr.fsf@mail.linkov.net> <87y0q31z7w.fsf@daniel-mendler.de> Date: Wed, 24 Sep 2025 21:50:00 +0300 Message-ID: <877bxnsn1j.fsf@mail.linkov.net> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 4cX5Wy2TCCz9svK X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79481 Cc: 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > I figured that `global-hl-line-mode' is not simply a globalized minor > mode. But maybe it could be at some point in the future? `global-hl-line-mode' can't be a globalized minor mode, because it uses global hooks. > Is there a need for the additional functionality of `buffer-match-p' > vs `easy-mmode--globalized-predicate-p'? As far as I understand > `buffer-match-p' supports more filter conditions, but do we need > anything beyond filtering by mode? Why not push the limits in another direction and extend the :predicate of globalized minor modes to support `buffer-match-p' as well? From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 24 15:03:21 2025 Received: (at 79481) by debbugs.gnu.org; 24 Sep 2025 19:03:21 +0000 Received: from localhost ([127.0.0.1]:51201 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1v1Uls-0002US-KZ for submit@debbugs.gnu.org; Wed, 24 Sep 2025 15:03:21 -0400 Received: from server.qxqx.de ([2a01:4f8:c012:9177::1]:59319 helo=mail.qxqx.de) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1v1Ulm-0002Tt-CS for 79481@debbugs.gnu.org; Wed, 24 Sep 2025 15:03:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=daniel-mendler.de; s=key; h=Content-Type:MIME-Version:Message-ID:Date: References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7VnIqUfSacAbvn71TaGVLU9uVX71DdyGqWb3B6p54VM=; b=kEQK+0R4RTljL9blcMeu3Fo23Z Q92fqy3oXKKyGB86zl/Su1mq1SVyq9xe4Em8Tr7H/uVCiY4FrQF4RHTnhBHpjVk+HNz5WH0W2Okuo GhSCRLZEL51gqbsD5ZoToJWywFZ+9A1dXOiGq4RkPzG6T4Imy9YhQjdcit85cuzwg3Ss=; From: Daniel Mendler To: Juri Linkov Subject: Re: bug#79481: global-hl-line-buffers - why not :predicate? In-Reply-To: <877bxnsn1j.fsf@mail.linkov.net> References: <87segfzqjr.fsf@mail.linkov.net> <87y0q31z7w.fsf@daniel-mendler.de> <877bxnsn1j.fsf@mail.linkov.net> Date: Wed, 24 Sep 2025 21:03:04 +0200 Message-ID: <87ecrvd66v.fsf@daniel-mendler.de> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 79481 Cc: 79481@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) Juri Linkov writes: >> Is there a need for the additional functionality of `buffer-match-p' >> vs `easy-mmode--globalized-predicate-p'? As far as I understand >> `buffer-match-p' supports more filter conditions, but do we need >> anything beyond filtering by mode? > > Why not push the limits in another direction and extend the :predicate > of globalized minor modes to support `buffer-match-p' as well? Sure, why not. The problem is that the `buffer-match-p' conditions have a different format. Maybe `buffer-match-p' could be adapted to understand simple lists of mode symbols and (not modes...). Then `define-globalized-minor-mode' could start using `buffer-match-p' and all the variables could be renamed to `global-*-predicate' or `global-*-buffers' with `global-*-modes' obsolete aliases? The question right now is if it is justified to diverge from the `global-*-modes' convention for this single variable - instead of finding a general solution, or just sticking to the existing convention. It is not clear to me why the additional power of `buffer-match-p' is needed. Why is `global-hl-line-mode` special and requires `buffer-match-p' in contrast to other global minor modes? Daniel