From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Colorful line numbers Date: Fri, 22 Jul 2022 14:53:12 +0100 Message-ID: <87v8rpntiv.fsf@gmail.com> References: <87leslpow2.fsf@gmail.com> <83ilnpl8e0.fsf@gnu.org> <874jz9peq0.fsf@gmail.com> <837d45l6ge.fsf@gnu.org> <87zgh1nyo6.fsf@gmail.com> <831qudl1k3.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11043"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 22 16:01:51 2022 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 1oEtDy-0002ar-Lj for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 16:01:50 +0200 Original-Received: from localhost ([::1]:59290 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEtDx-00060W-DP for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 10:01:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48628) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEt4U-0002ka-IC for emacs-devel@gnu.org; Fri, 22 Jul 2022 09:52:02 -0400 Original-Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:40863) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEt4S-0002Su-SR; Fri, 22 Jul 2022 09:52:02 -0400 Original-Received: by mail-wr1-x430.google.com with SMTP id m17so6305845wrw.7; Fri, 22 Jul 2022 06:52:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:in-reply-to:references:date:message-id :user-agent:mime-version; bh=WP4sD3tNtFV4YevohKOnkzgK6hzvMlVC+ZwKEOlw3tI=; b=nrEGKON73mH1V0KNEBwFi3yDN3ZR6MoRJtyDWrWcmOB66xAFDf0JMUOflqw+BywuAO 1YikZEqx8NzVlA1INEm6dT8HGefA90He1lk69bS1gFodHSfn4TVEKgJHc2X5dOxkF8p6 pDYhjk3G7zylVlJ4NQf6Mj8ZU/v4OdreV5PZMgeM9pswAzeSZ09twfEoCjTxSHmhHast wLEQQWc1nTZIxIJDA58KCs5GbQI0nbAfTy8yAub+rz5tYilkcumBs5H4I1AyCw94vemj bcbW3xpIyTUfOsG16LYqIpalRSlX8rS+QiG97lc63TP6GAEwzpJ0f4FDbuUVif0WaFVW Msbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:user-agent:mime-version; bh=WP4sD3tNtFV4YevohKOnkzgK6hzvMlVC+ZwKEOlw3tI=; b=ybm9jnCpogvxTmlQbav8wKkx3D15AfXXuuhUTM38LR6vHUJw3mN6bIztqxBFBxkxN9 q6rqo8O/FTeZBy3kHo+6/9iXzwOGHL6dm1tGN3gwbs8FvlTocs/N+T6tu+CfL7iam5Vf iuPDRviJIM7vBT+kBZzNMnhDbwCfBL2LBGlvhwIbzKkMc5aWRNmmGcykaig9fEHBDmE0 qaMdK3R2dZ7OBGs/FGJc38vYkE1hqwz3cWFG6N36upKcDwAAb+9ciL5OpG4s2ftEe5ly 1WpQUoe1tZtvIFVndhK0iKDBjIB4mSZJj+HhmegpC1Oh3OzB+I3JxOhxQRmUJWobLQ8Y 6DQQ== X-Gm-Message-State: AJIora9QCeIcF6+XPWIPwmbQigq8sdhVOAO5OvAatb79sn13MBVwtq3f oBmbjeENRFA4/RbxDB/AUXw23SC80ko= X-Google-Smtp-Source: AGRyM1uD2PyVGv0vHNtiY6np7aHsGflZJ/ozybjruciRstheQRNc3ScEcfaoleGURXJDddfeWj2tQw== X-Received: by 2002:adf:e84c:0:b0:21d:83ed:2ce with SMTP id d12-20020adfe84c000000b0021d83ed02cemr24986wrn.582.1658497918093; Fri, 22 Jul 2022 06:51:58 -0700 (PDT) Original-Received: from krug (87-196-72-209.net.novis.pt. [87.196.72.209]) by smtp.gmail.com with ESMTPSA id l37-20020a05600c1d2500b003a33227e49bsm4940067wms.4.2022.07.22.06.51.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jul 2022 06:51:57 -0700 (PDT) In-Reply-To: <831qudl1k3.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Jul 2022 16:27:56 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::430; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x430.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=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" Xref: news.gmane.io gmane.emacs.devel:292436 Archived-At: Eli Zaretskii writes: >> >> Does checking for a given text property on some buffer text call into >> >> Lisp? If it isn't, and it's cheap, then this hypothetical feature could >> >> have very low overhead when not used. >> > You want the line number to have the same face as the character >> > displayed immediately after it? >> Not the "same face", rather some face which is the result of querying >> text properties on that text. > I don't understand what that means. Querying the properties how? With the C equivalent of get-text-property. textget() or Ftext_properties_at(), or some callee of those. The lightest possible option. > And doing what with the results of those queries? Eventually, you need a face. If the query (or "lookup" if you prefer) produces something non-nil, the value it returns is a LispObject which is a face. >> > That can be done from C without calling Lisp, but how would that work >> > reliably? Any change in the buffer text will risk breaking the >> > feature. >> It's up to the Lisp package that is interested in this functionality to >> set or unset the correct text property. > Well, good luck with that! Because I don't think this can be > reasonably implemented from Lisp: there are too many aspects involved > that are hidden from Lisp. I don't foresee any great difficulties in selecting a region of a buffer and propertizing the text with some arbitrary property. >> > And even this is already a complication I'd like to avoid: line number >> > of a line is rendered before we examine the buffer text of the line >> > (and even know whether there is any text there). Now we would need to >> > look forward in the buffer and get text properties of that text. >> > Which might not work correctly, btw, if jit-lock was not yet invoked >> > to produce the faces there. >> >> See above. This wouldn't be a problem because I'm not interesting in >> choosing the same face that jit-lock selected. The indirection would be >> some text property, say line-number-face > > I guess this gets back to the question about "queries" and their > processing? To try to clear up any doubts, I meant nothing fancy with the word "query": by it I mean inspecting and retrieving the value of a text property at a certain buffer position. > The answer depends on the condition(s) which that "valid buffer > position" should satisfy. That buffer position should satisfy just one condition: it should exist in the same line to which the line number about to be produced (maybe...) by 'maybe_produce_line_number()' refers to. >In general, IT_CHARPOS(*it) gives you the next buffer position to be >processed. If I'm reading the code correctly, the particular 'it' argument to maybe_produce_line_number _does not_ refer to a buffer position, rather to a thing that may be displayed. In that case, I have to advance (a copy) of this iterator until I find such a buffer position. Otherwise (if it _does_ refer to some buffer text) I think my question is closer to being answered. Jo~ao