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: Local face remapping Date: Thu, 5 Oct 2023 09:12:58 -0400 Message-ID: <8EA60CCA-70A7-40FC-86E7-649EB10AE6E7@gmail.com> References: <1AB6E9C8-1BCB-4C0A-A4AF-45F5C64D9B4C@gmail.com> <838r8i5nwe.fsf@gnu.org> <5E16BC09-3063-4509-9DF6-7C8EC25E1285@gmail.com> <83y1gh4os9.fsf@gnu.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) 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="31363"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 05 15:14:20 2023 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 1qoOBG-0007yF-Tx for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Oct 2023 15:14:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qoOAI-0000W6-NI; Thu, 05 Oct 2023 09:13:19 -0400 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 1qoOAG-0000QK-Lm for emacs-devel@gnu.org; Thu, 05 Oct 2023 09:13:16 -0400 Original-Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qoOAE-0004aD-Nt; Thu, 05 Oct 2023 09:13:16 -0400 Original-Received: by mail-qk1-x72c.google.com with SMTP id af79cd13be357-7743448d88eso61215685a.2; Thu, 05 Oct 2023 06:13:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696511591; x=1697116391; 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=mnNB33t3jkiEcFgmxL1CQLgvFtOS+XRuUPxHmwkgXKQ=; b=Yj3+zB2ULlfgma2eG2ErZufQ+WlVKc4CPgVnFV+NsrXZcmAcwSQD828NFD94KM+70m uYLUacEaITj4B7Eder8NEkFFjnFhP63pUlQrRzvP8l/mE8Ys52ke4mBAkzdgOJk9XFYS 9Gc7S06HZYYCtCE2Xks16TSlt4SMjtaJi7yoJY2rnbKT5Pl7+hoFMGHUFMZlVsMXuOnm gr5AMNjVz4nAcX+sLXPnu7sjHJh54zuBuL4hsEbvkLem4tdy42wxES4mXzhkr0nw1cRf 85ViM8mEdxQH0sQJu/Fo3PO20HpDXVLHm9qfMPmcfz0VW7OfZZbLcOlcbEdxqOteJQx0 9qxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696511591; x=1697116391; 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=mnNB33t3jkiEcFgmxL1CQLgvFtOS+XRuUPxHmwkgXKQ=; b=uwBkQiZRYmP49K+ZYZUxT3O2mx/f/yOqZwnGPCnDIChrGnDWDctXGv7jdIM1JjmoqR 1txY3zmvmWcUH5W+M3EL40blIOrW0h5ISlCpBoypI9Dl0GkfcFEruqqmxBzQrpsgw0o1 XJ/Pb+k+hOWDDwjyaf52jkYRGwyIB0Y0fYraohxOko6zzpzoZFqfRV1G7Xo+aG/pqFUE rWPJZ/E0LYjVan96BD2WmW9kY+gvnN1WAY3yf3sRsWqkaHgICh1acgUI76BZ3eOp9Flj wciXE+TwglVtG8Iu+P9VxFnGd048XmxER6BWw2uIBUjb5hpVxorgSTIzoPNaPtTJGxYR jikw== X-Gm-Message-State: AOJu0YyJylw8cRnZ7NNEN1fjOEdWwPaYgyWeLEyjrM3KbWhUrAWra9ve 5hTNd8IafDyd/Glbmv5+EiBi13DGIfZXMQ== X-Google-Smtp-Source: AGHT+IEJoMiTVh6Pn/HvHnXhu6XopUv4FF8AyE4l2R07ahV64BM9jKBQCKhnP0vkBthtHH25/JkpGA== X-Received: by 2002:a0c:f0ca:0:b0:64b:997f:5a73 with SMTP id d10-20020a0cf0ca000000b0064b997f5a73mr4967495qvl.0.1696511591167; Thu, 05 Oct 2023 06:13:11 -0700 (PDT) Original-Received: from smtpclient.apple (cm-24-53-187-34.buckeyecom.net. [24.53.187.34]) by smtp.gmail.com with ESMTPSA id s13-20020a0ce30d000000b0065b0d2f9121sm481364qvl.68.2023.10.05.06.13.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Oct 2023 06:13:10 -0700 (PDT) In-Reply-To: <83y1gh4os9.fsf@gnu.org> X-Mailer: Apple Mail (2.3731.700.6) Received-SPF: pass client-ip=2607:f8b0:4864:20::72c; envelope-from=jdtsmith@gmail.com; helo=mail-qk1-x72c.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 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:311300 Archived-At: > Let me help you understand the situation better. Thanks very much for your detailed explanation. > In Emacs, faces are defined per-frame. That is, each frame can have a > different definition of the same face symbol. >=20 > face-remapping-alist doesn't (and cannot) change that simple fact, so > it is a trick: it creates new faces based on default faces, in a way > that is buffer-local. This works (btw, not in all places) because the > display engine consults the buffer-local value of face-remapping-alist > each time it needs to realize a face for display. If that variable is > non-nil, and the face to be realized is mentioned in the alist, then > the display engine generates a new face on the fly and uses that new > face for display. Interesting. I presume with caching? > So, if you want face-remapping that depends on buffer positions, you > will need to change the implementation of face-remapping: instead of a > simple alist, we will probably need to also allow a function returning > such an alist, and the C code will need to be taught to deal with > the situation where face-remapping-alist's value is a function. That=E2=80=99s an interesting idea, more flexible than hard-coding a = simple function that considers START=E2=80=A6END. You wouldn=E2=80=99t = want to call such a function for each FACE character, and if the region = divides a FACE interval, that adds complexity. But maybe tractable. > My suggestion to use different faces just does explicitly what > face-remapping-alist does implicitly. But much less efficiently, if the faces to be altered appear in many = non-contiguous intervals, and within =E2=80=98display strings in that = (potentially large) region. The advantage of the =E2=80=9Cjust in = time=E2=80=9D face substitution you describe is it operates from the top = down and is thus suitable for rapid updates via, e.g., = post-command-hooks. It also plays nicely with font-lock, etc. A perhaps related concept would be allowing code (including font-lock) = to apply secondary face(s) to text, via an alist, perhaps. Secondary = faces would lie dormant, unless and until an overlay or text property = explicitly enables one of them (`use-secondary-face =E2=80=98foo', or = similar). In this way it would be similar to mouse-face, but explicitly = under programmatic control instead of implicit mouse position control. = An overlay or text property could then be applied to an entire region = enabling specific secondary faces within it to =E2=80=9Ccome alive=E2=80=9D= , quite similar to how mouse position causes mouse-face to activate.