From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jim Porter Newsgroups: gmane.emacs.devel Subject: Re: [RFC] Add :invisible face attribute Date: Sat, 21 Dec 2024 09:46:40 -0800 Message-ID: <81970ad8-d2a4-eca6-d8cd-4092fbbac90d@gmail.com> References: <20241218160813.31108-1-mina86@mina86.com> <867c7xlyqp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32117"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Eli Zaretskii , Michal Nazarewicz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 21 18:47:04 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 1tP3Z9-0008FB-LE for ged-emacs-devel@m.gmane-mx.org; Sat, 21 Dec 2024 18:47:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tP3Yv-00077h-6V; Sat, 21 Dec 2024 12:46:49 -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 1tP3Yp-00075I-Ry for emacs-devel@gnu.org; Sat, 21 Dec 2024 12:46:46 -0500 Original-Received: from mail-pl1-x636.google.com ([2607:f8b0:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tP3Yo-0003Of-0W; Sat, 21 Dec 2024 12:46:43 -0500 Original-Received: by mail-pl1-x636.google.com with SMTP id d9443c01a7336-2166651f752so30657965ad.3; Sat, 21 Dec 2024 09:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734803200; x=1735408000; darn=gnu.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id:from:to:cc :subject:date:message-id:reply-to; bh=Y6sru6dyCh0xXL3Sws2mI8+mIyFoPiWGuVEGruqp1Ac=; b=AYfcgJOuRaNIxqwwJubP05gPwR8FuCRBedS/CUPeqmHYpPxAmL/vAaEn6cTkw029vd WEG28aRgbEa1M/Jnfx1sGMrY1ZIqo+/pwHHO9AjKkAZTFZEqCN8pOWgOkOk8FhIs7EiX I+FBOOSBGdXOx9b2hL3+SvkE+Zb0xpE7jXZ2njcXW2EYh6x6xUsot21U0cAYn0VUH/ul PtW6WgqLG/xJEA2bhbvX+1tAN1pjHlm89GMGrJvW0i/PYMUA3RUvWZVY/neEAUfP9uN9 acc9mex6hCVtiXHXIyM+41Zu6XWwOg4r8f6Ip5cfPNvIhWmEaKwAZoVnhm0wCxrDzgMy xYOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734803200; x=1735408000; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Y6sru6dyCh0xXL3Sws2mI8+mIyFoPiWGuVEGruqp1Ac=; b=Go1XOAui1OySR/qHatFdQmhdO2A5wX02X07/LODC1cSnLatiUln56cvPAUdbUVfYfK 45k9xr6pcSh/vxgkIivxPyCk3HgsmECpAosfPq7u03uQX7C56RA11NTGJ2UI+NYq/eE7 WPDW4dgoZYGsvZ261OnDldM7hax2SUiG5H0gFzSLc3rLWvp3nEoadyldF6mTohDkZvrm On78BJRf8Dguow9UCZ5UNak7WnLM4daX6XyWIHG96C5xlkHcETZQBmuQOcIOLLMM3HYC p/Z9B9scb2TGPcxGiEl2amCDBI8HnYVBAFap8589tckC0xUc+VVGcU1pgi8oxZgpr0u3 DZfw== X-Gm-Message-State: AOJu0YzwvLSXRa62VemER6NMeZa3YZe8GSRFdJCIAJ1rElFv9tmxthNJ 9WV/ppAUJQd25bTZenkYxLnSXFC15HqKI3J0GFUL6girrCp/oOkl20qJng== X-Gm-Gg: ASbGncucVJIzi9CAcHiMseMmM7WCnMSUFuUtcuOmGLj6sgzJJsNUAnrvdOqcVfmRW+t GhzHPTatZ7t7pSTipE/1mZRxjG3w19BCjVh6FKofnvwIVBX5gX7MiZozddQlt1Ifz1hKbAcfEUU Jbwh2rPSc8OoUWvSwiP12ZyXP6F86B22bG1M1oA91cqUjtdtU28ONzsLtIVP/KdXB+raDRZb0tu e5yEScGkRqfVzecOdvANeDvAs0xoahw0WQ0xfO3rcr5IUknrN4NMJs1lObqhKmadtFHEOhEbfZe By7lqaw8Iv6vsnAp+eCmF7UM85iQfqREHA== X-Google-Smtp-Source: AGHT+IGsi7jUl4FsBJ/6IeXNBV/XdIwQtyqzu4ClrVoOd8UQSRC7AnWTWq5frDevep20geoveKJflw== X-Received: by 2002:a17:902:d2c6:b0:216:2bd7:1c36 with SMTP id d9443c01a7336-219e6e8bbb6mr103482015ad.1.1734803199836; Sat, 21 Dec 2024 09:46:39 -0800 (PST) Original-Received: from [192.168.1.2] (syn-023-240-098-037.res.spectrum.com. [23.240.98.37]) by smtp.googlemail.com with ESMTPSA id d9443c01a7336-219dc9cdee0sm46560155ad.119.2024.12.21.09.46.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 21 Dec 2024 09:46:39 -0800 (PST) Content-Language: en-US In-Reply-To: <867c7xlyqp.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::636; envelope-from=jporterbugs@gmail.com; helo=mail-pl1-x636.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:326825 Archived-At: On 12/18/2024 8:52 AM, Eli Zaretskii wrote: >> From: Michal Nazarewicz >> Date: Wed, 18 Dec 2024 17:08:12 +0100 >> >> Introduce :invisible face attribute which makes foreground to be the >> same as background rendering the text invisible; or when :invert-video >> is also in effect, background is the same as foreground. [snip] > > A new face attribute adds quite a bit of complexity, so we should > really believe this is a good idea. Given that this can already be > achieved without a new attribute, I'm not sure. Is this really a > frequent need/situation? > > But let's see what others think about this. I'm just brainstorming here, but could Org use a display spec with specified spaces[1] to make Emacs render a space of the appropriate width? That requires a bit of computation, but it's how 'visual-wrap-prefix-mode' and SHR handle (roughly) similar sorts of things. If it's too difficult to get the existing specified spaces to work properly here, maybe we could enhance them? For example, perhaps you could have a display spec like this: '(space :width "**") Which would mean "make a space as wide as the string '**'". That might even allow simplifying some of the code in 'visual-wrap-prefix-mode' (specifically, the parts that compute the width of the prefix; see 'visual-wrap--content-prefix'). Still, if the existing specified space code is enough, it's probably best not to add even more complexity to it. [1] https://www.gnu.org/software/emacs/manual/html_node/elisp/Specified-Space.html