From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.help Subject: Re: How to Display a Zero Height Line Date: Thu, 12 Dec 2024 11:23:42 +0200 Message-ID: <867c851cgx.fsf@gnu.org> References: <86cyhx1jpu.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26698"; mail-complaints-to="usenet@ciao.gmane.io" Cc: help-gnu-emacs@gnu.org To: Psionic K Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 12 10:24:14 2024 Return-path: Envelope-to: geh-help-gnu-emacs@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 1tLfQb-0006jn-RZ for geh-help-gnu-emacs@m.gmane-mx.org; Thu, 12 Dec 2024 10:24:13 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tLfQC-0006Tc-1n; Thu, 12 Dec 2024 04:23:48 -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 1tLfQA-0006ST-Dv for help-gnu-emacs@gnu.org; Thu, 12 Dec 2024 04:23:46 -0500 Original-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 1tLfQ9-0003rk-HA; Thu, 12 Dec 2024 04:23:45 -0500 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=0iuXmSufiCyopYYRNo9oungZDW5VcJxbwWBzNUMg2Vk=; b=jV4of42b1tXS /h6ynBR2qrUU2JhtkthWL2T2lVyfGKXGGUmHpnhJ1Pne1IsEI4erEvvAmRbEMkp9KZ59XKQB1QXWu yRNoblPAhIh8l3ZuzoOYmyyPQEID9/PmZaHebejeHEgWXBPfoq5KUD723YRhHTssNrN95pySOIr0H DrsKsA0IhwMDYRRv8PneDHaiDpLk46PpSzW/5pS5q377SQisVVe22ssJVsydaJI16BK8dQlFoNSNR APouqABtofMj+K3V8XVEB5LD9R1aCktZ0dD+xVQf5A9scwdoU+n7WdPTM0NpZRO/pUz2P07q3k1JS D4r4Er5GMpo8kTJbdtzUng==; In-Reply-To: (message from Psionic K on Thu, 12 Dec 2024 18:00:15 +0900) X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:148769 Archived-At: > From: Psionic K > Date: Thu, 12 Dec 2024 18:00:15 +0900 > Cc: Psionic K , help-gnu-emacs@gnu.org > > > > The background of TODO extends vertically in a graphical client. I > > > want the space between the two lines. I do not want the background of > > > the TODO to extend to the previous line. Any and all intended > > > workarounds are acceptable. I am merely choosing an implementation of > > > an effect in Dslide and it doesn't matter how it works. > > > I still don't understand, but did you try to use the :extend > > attribute? > > Why would I be in such a rush to horizontally :extend that which must > be vertically truncated? I thought you wanted the background extended horizontally past the end of line? If not, what is it that you want to achieve? Can you explain your goal in simple words what kind of background extension are you after? > I have further inspected the possibility of using empty lines with > actual newlines in the buffer text. No combination of assigning the > current line, an extraneous line used to create space, and the newline > before the next heading, via overlays with line-height, face height, > and line-spacing of zero, appear to overcome the font locking > behavior. Sorry, I don't understand what you are saying here. What "font locking behavior" you want to overcome? > Directly manipulating the font locking behavior is acceptable if there > is a precise means of targeting. I have in the past applied > properties independent of font locking and then read these via new > font locking rules. As an implementation I prefer to avoid it because > if org learns tree-sitter, my solution will break depending on the > font locking in use. I don't understand that, either, probably because it is based on the previous paragraph, which I also didn't understand. Sorry for being so dumb. Feel free to terminate this discussion if it doesn't help.