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 16:10:54 +0100 Message-ID: <87fsitnpxd.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> <87v8rpntiv.fsf@gmail.com> <83sfmtjjy8.fsf@gnu.org> Mime-Version: 1.0 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="34443"; 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 17:15:07 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 1oEuMs-0008jC-ER for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 17:15:06 +0200 Original-Received: from localhost ([::1]:57662 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEuMr-0008Km-Bo for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 11:15:05 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38060) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEuHf-0007Pu-QK for emacs-devel@gnu.org; Fri, 22 Jul 2022 11:09:46 -0400 Original-Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:46769) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oEuHd-0002CX-Il; Fri, 22 Jul 2022 11:09:43 -0400 Original-Received: by mail-wr1-x42c.google.com with SMTP id z13so6891253wro.13; Fri, 22 Jul 2022 08:09:40 -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:content-transfer-encoding; bh=quT3QOiqIa62bIqINBYhR9qqz8CHrF5TZa2tNf6pX2A=; b=jVpAEaj7aO1l2GBG6HgGY+nK8LVPEjllDlIWaVkWjiwtajWVK6C9EsRRT60Pm3ecFF U3H/YdC8UquSfJpjlPZslFCcOXeExM2bHWRlhKX+Dre5jIHragwXnz5dpm/urx06NnDm hf0dfLuBA7JJOj5ELwJBxmlte8n+2Md2XsdwsHLlKzYxCtmJQvpimYTaIM4HnKuNTo9B 31NUZnfOJvh+5o7J3Zh3dBu/gaMB6FSrwxialD3hO4yfUhL4PMcH1YiBfLEhO200lHnd H6QgWOfhtP0qZmHyQ3n9qiPOcqqlpeaX7HGQMjQrjw0799ymvCa7Kp55ARtYpzsZ7U0l GasQ== 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:content-transfer-encoding; bh=quT3QOiqIa62bIqINBYhR9qqz8CHrF5TZa2tNf6pX2A=; b=VU8WdpPb4qIsAJeGmUMDpkjARiJ6Ex6lmjpjCvSZcYSHB+d77iK5CzFlyeNEm6mGfs GwTC85NnFeeTaJWHY2Nw1j73gpJiWPpcyPLb08SEMGljEZ8XDhotxAu+b8s/JE3l6fFs Il7GPKzPVGuazBq7CEYi2DsLkKPhiLmbyW0k6BPgzVetDHJj0w2hCIVQYz818TEAQ3HW OILlVUsU/Mk7oNUSrlWPv1BmjrgR0zVm/SICVcbPZ4kBV7R2h2YKwarhBO9hgZFuOmD1 iYUTeubLeGkBV0CNlxpZbB/q+EhGvwM3l8/sInR+eFwLElokgZbLdffjkNpLR5TN/CsO mMoA== X-Gm-Message-State: AJIora+x1uwdQVO196gdkABtWwWCDSrdSiIt9eQksY2D3PU6Cb9W4i9H EjfkTujnPkiBtk1g5NXqyPBLsfFmwsA= X-Google-Smtp-Source: AGRyM1vJOynQH07Wi5fMXSzwpdE3RUjXurWhf3bkmeKrfcDFQbYxSFW/8I8gi6a5Zx0XqGen8VX8Sg== X-Received: by 2002:adf:fc0e:0:b0:21e:490f:3a7f with SMTP id i14-20020adffc0e000000b0021e490f3a7fmr259132wrr.273.1658502579034; Fri, 22 Jul 2022 08:09:39 -0700 (PDT) Original-Received: from krug ([87.196.72.209]) by smtp.gmail.com with ESMTPSA id h7-20020a05600c2ca700b003a3253b706esm3391164wmc.34.2022.07.22.08.09.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Jul 2022 08:09:38 -0700 (PDT) In-Reply-To: <83sfmtjjy8.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 22 Jul 2022 17:33:35 +0300") Received-SPF: pass client-ip=2a00:1450:4864:20::42c; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x42c.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:292450 Archived-At: Eli Zaretskii writes: >> From: Jo=C3=A3o T=C3=A1vora >> Cc: emacs-devel@gnu.org >> Date: Fri, 22 Jul 2022 14:53:12 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> >> Not the "same face", rather some face which is the result of querying >> >> text properties on that text.=20 >> > I don't understand what that means. Querying the properties how? >>=20 >> With the C equivalent of get-text-property. textget() or >> Ftext_properties_at(), or some callee of those. The lightest possible >> option. >>=20 >> > And doing what with the results of those queries? Eventually, you need= a face. >>=20 >> If the query (or "lookup" if you prefer) produces something non-nil, the >> value it returns is a LispObject which is a face. > > So the value of the text property will be a face? > > If so, how will that property be set on the text, and what will > trigger whatever sets it? A Lisp function that is called once in a while, either manually or via a idle timer. >> >> > That can be done from C without calling Lisp, but how would that wo= rk >> >> > 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.=20 >> > 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. >>=20 >> I don't foresee any great difficulties in selecting a region of a buffer >> and propertizing the text with some arbitrary property. > > You mean, the Lisp program will scan the entire buffer text and update > the properties upon each and every change to buffer text? Like in > some post-command-hook or something? In some hook yes, but not "post-command-hook" and not on each and every change. And I don't think the "entire buffer text" has to be scanned. >> 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. > > So each character of each physical line will have those text > properties set whose value is the face in which you want to show the > line number? And some post-command-hook will update the values in the > entire buffer? See above. Not "each character" and not the entire buffer and not in the hook. At least for _my_ application. Some other application might want to do that, but not the one I was thinking to build with this feature. Also my application typically works with small files. And it already suffers from significant lag from calling an external process. >> > The answer depends on the condition(s) which that "valid buffer >> > position" should satisfy. >>=20 >> 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. > > So, to know that no character on the line has this property, we'd need > to scan all of the line's characters? To know that piece of information, yes. But only if that information is useful. It would be essential if the hypothetical feature advertised itself like "put a property on any character and I will take care of the rest". Instead, if it advertises itself as: "put this text property on only this one (first/last) character of the line..." or even "put this text property on _every character_ of the line...", then no such scan need exist, I think. >> In that case, I have to advance (a copy) of this iterator until I >> find such a buffer position. > Which "such"? I employed the word "such" because I was not sure that the iterator referred to (or "iterated through") buffer positions. I used it to express conjecture/doubt. > And please note that copying an iterator is not just copying a > structure, there's a protocol for that (see the macros SAVE_IT and > RESTORE_IT). OK. >> Otherwise (if it _does_ refer to some buffer text) I think my >> question is closer to being answered. > I don't think I understand what you mean by "refers to buffer text". I don't know how else to express it. But I perhaps your phrase "an iterator through text" answered by question. Given one iterator such as the the one passed to maybe_produce_line_number, it seems I can get some value that I can eventually use to call Ftext_properties_at. Jo=C3=A3o