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.devel Subject: Re: Colorful line numbers Date: Fri, 22 Jul 2022 17:33:35 +0300 Message-ID: <83sfmtjjy8.fsf@gnu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25925"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?Jo=E3o_T=E1vora?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 22 16:34:26 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 1oEtjV-0006W2-F5 for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 16:34:25 +0200 Original-Received: from localhost ([::1]:57656 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEtjT-0000Tc-VY for ged-emacs-devel@m.gmane-mx.org; Fri, 22 Jul 2022 10:34:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58078) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEtin-0008D5-0G for emacs-devel@gnu.org; Fri, 22 Jul 2022 10:33:41 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:44242) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEtim-0005QD-O5; Fri, 22 Jul 2022 10:33:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pj4qc/BcNaa7ZQmNNAKVWzDZu3iF5tOkT6YhxaqMO3g=; b=DzFR+VKlWTdneGVawVgc G4VtAQ8CqvcNtJKgwp3pyZCTkAwF8veCFPSmivTge+c/y5o/dvLaxcRoiQeaa1r4k2lf21U43Z6+y WwyT1+VNpUkjpDimiY5jTVhvKumF/npryBIUwLYru/Xky6uUPxZDfZefog7LPL82bucvp09fDxeni wQNnZX6TOZPf7WuWG5Skiz0NjcxGHBLx6pCGyL7ccAHIRvc2Cbaf639dgSt+us0KROFQpoPZ8fx5F kSJKQmqUALIbUiOwn/FkC+Gv5q0yyPWyak9IPIdASPQTwefr3lsqly3gg6yhPEx9dJNLMxFbjdtnF MxORFBLIK+RRBQ==; Original-Received: from [87.69.77.57] (port=3078 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEtim-0000Ku-7D; Fri, 22 Jul 2022 10:33:40 -0400 In-Reply-To: <87v8rpntiv.fsf@gmail.com> (message from =?iso-8859-1?Q?Jo=E3?= =?iso-8859-1?Q?o_T=E1vora?= on Fri, 22 Jul 2022 14:53:12 +0100) 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:292441 Archived-At: > From: João Távora > Cc: emacs-devel@gnu.org > Date: Fri, 22 Jul 2022 14:53:12 +0100 > > Eli Zaretskii writes: > > >> 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. 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? > >> > 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. 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? > 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? > > 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. So, to know that no character on the line has this property, we'd need to scan all of the line's characters? > >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. 'struct it' is an iterator through text. It includes all the state information needed for the iteration, and also the metrics of the last "display element" (character glyph, image, stretch, etc.) that it calculated. > In that case, I have to advance (a copy) of this iterator until I > find such a buffer position. Which "such"? 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). > 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".