From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.devel Subject: Re: region-based face-remapping Date: Tue, 9 Jan 2024 15:20:53 -0500 Message-ID: References: <83o7dupskh.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.300.61.1.2\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10050"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 09 21:27:33 2024 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 1rNIhA-0002PG-QP for ged-emacs-devel@m.gmane-mx.org; Tue, 09 Jan 2024 21:27:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rNIgH-0006j8-CN; Tue, 09 Jan 2024 15:26:37 -0500 Original-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 1rNIgE-0006ik-5M for emacs-devel@gnu.org; Tue, 09 Jan 2024 15:26:34 -0500 Original-Received: from mail-qk1-x734.google.com ([2607:f8b0:4864:20::734]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rNIg9-0000OT-QT; Tue, 09 Jan 2024 15:26:32 -0500 Original-Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-78333ad3a17so20206685a.3; Tue, 09 Jan 2024 12:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704831988; x=1705436788; darn=gnu.org; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=9l5AmrjzajBBK3Q3laiKj5gy/080+ZONtWgJsS0Z3Is=; b=M6g1FnvVHXP9v+eTMa5hJ16eVF0MgZ2j71tthBt7GcG79IHnY5E9NJ2F2yQNVSSsNn /P4luqiyAEXhhqSgzyE+E87Y+/H/kQOUTSBoZiZ44OKSaRrVDIfHCBkApYcs9A92qBSE sHCRXgfJHY1AjwcxkXx85qoUb/xeaJoA+jUMmt5ysS2vXfM8YXVKLPYhSNQLaMNuYvsm 1mn6FQJZkmI9q+HZ1rQS7t6iBwtJqBn1DhdGK4uR9l6ljzmxfxK9s74dJWN9B9B/svq0 paKHKHojcH1dZYD4lpaUZiRNZaf6L0pG9j5bd7J+uWQIe5oCcf/lmt+buMsGKrFd8bB6 VjvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704831988; x=1705436788; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=9l5AmrjzajBBK3Q3laiKj5gy/080+ZONtWgJsS0Z3Is=; b=hA/2/MR1uaSXedrCVTI7MMY2wLJn8N8ZX07lTJkyIxt+clphlAGx1/3yTmN6R0J7PN l2dDjyfkbIcLaN4PLd4A728eXwQVGxpNrx84hpzFEbdsaNBBMuWvnUiFaNx4482+feDh MkFNL8vKMXtc/yC6ylsTZddELoRenp1FoR8+GLVGnqZMmvEi8TZphdctBmivToPZESDw A+jPUG66a+ONvf36LmQ+3l/GxidzfVlmDOUyK+jiAT90woUzsi7EJI8k1Am5VG5XKPzd R25V4+pI1zx5X7gDA0+tKe9auuT3Gfy9JcX+sPMSDtZL2oJpoTXNzJeZrBcumHCVU6dm l8Xg== X-Gm-Message-State: AOJu0YyAWxRTFnVGvcUSIhMMjLBVaAHqTBG3faKm6GjxA3rRPKYfWA/e V6hZrPal6jDgxFUXMEOJ+Vc= X-Google-Smtp-Source: AGHT+IGiqpTiiCa1L2EY8q1JIlotIuQte1HMTNCX0iMKnAgrdp0jQ6i67RiGnH13wl+OQF/1e+EeKg== X-Received: by 2002:a05:620a:1a96:b0:783:10d6:2138 with SMTP id bl22-20020a05620a1a9600b0078310d62138mr7334448qkb.30.1704831983684; Tue, 09 Jan 2024 12:26:23 -0800 (PST) Original-Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id e9-20020a37ac09000000b00781d3f29215sm1066247qkm.91.2024.01.09.12.26.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jan 2024 12:26:23 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.3774.300.61.1.2) Received-SPF: pass client-ip=2607:f8b0:4864:20::734; envelope-from=jdtsmith@gmail.com; helo=mail-qk1-x734.google.com 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:314795 Archived-At: > On Jan 9, 2024, at 9:15=E2=80=AFAM, Stefan Monnier = wrote: >=20 >>> What I=E2=80=99m struggling with is how to do something =E2=80=9Clike = font lock=E2=80=9D =E2=80=94 >>> i.e. refontify some potentially substantial fraction of all the = faces >>> in a buffer, not (just) on modifications in an after-change-hook, = but >>> also on point-dependent =E2=80=9Cregion of interest=E2=80=9D = changes, with a priority >>> given to the displayed region in the window. IMO, tree-sitter will >>> make this kind of idea more common. >=20 > [ Sorry, I missed the beginning of the thread and haven't had time to = go > and read the previous messages. ] No worries, thanks for joining. > IIUC you're discussing features where the appearance of parts of the > buffer depends on the position of point. The main design issue with = it > is what to do when the buffer is displayed in several windows (so = there > are several points). Depending on this, the implementation strategy = may > need to be very different. That=E2=80=99s a very good point that I had not considered. In my case, = the selected widow would take precedence, and other windows just get = what they get. >>> Aside within aside: it would be great if `timer-activate' included = an >>> optional no-error argument so you don=E2=80=99t have to check if it = is on >>> `timer-list=E2=80=99 twice. I.e. if a timer is already on = timer-list and >>> `timer-activate=E2=80=99 (with no-error) is called on it, do = nothing. >=20 > The `timer.el` API is geared towards creating/destroying timers. > The other functions (like `timer-activate` and friends) seem to have > been thought mostly for internal use. >=20 > In order to reuse timer objects the API needs a few changes. > One of them could be to expose a `timer-active-p`, indeed. > [ Another would be to merge `timer-activate-when-idle` and > `timer-activate` so the caller doesn't need to care which > one to call. ] I had once heard that constantly allocating and destroying timers (say = every 50ms) is memory inefficient, but that reusing the same timer = overcomes this. Hence timer-activate instead of constantly = run-at-time=E2=80=99ing. It=E2=80=99s possible that=E2=80=99s = apocryphal (haven=E2=80=99t tested).