Re: Colorful line numbers

[João Távora]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 22 Jul 2022 14:53:12 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> 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?

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 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?

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.
>> 
>> 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ão