Re: Variable-width font indentation

[Eli Zaretskii <eliz@gnu.org>]

> Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> Date: Wed, 7 Mar 2018 08:15:39 -0500
> 
> > The "string" you refer to is already in the buffer on display, right?
> > If so, you can simply use the likes of posn-at-point to measure
> > portions of text in pixel units.
> 
> Yes and no: it might be offscreen.

Then the text you need to indent below it is also off-screen, and you
don't need to re-indent it, right?

> > Then what _do_ you mean by "building the spine during redisplay"?
> 
> I meant build a prefix string (which the code I sent called the "spine") to use instead of leading spaces.

What would be the advantage of building such a string at redisplay
time?  Consing a short string is very fast, and has the advantage of
being done only when needed (by contrast, display code is many times
invoked for reasons utterly unrelated to actually displaying stuff).

> >> I never meant to adjust indentation (that is, to change the contents of the buffer): just to display existing leading spaces differently based on the contents of previous line. 
> > 
> > We never do that with the existing indentation machinery, either.
> 
> Wait, never do what?

What you say in the sentence I quoted: display existing leading spaces
differently based on the contents of previous line.

> >>> In any case, I'd suggest to reindent via buffer-modification hooks, 
> >>> not as part of redisplay.
> >>
> >> Right, and that's why I worry about performance.
> > 
> > Then don't automatically reindent, let the user initiate that.
> 
> The feature I'm offering is like font-locking, not like reindenting: it changes the display of existing buffer elements in a way that doesn't modify the underlying text.  Given this, it makes more sense to me to run it automatically (rather than on demand)

"Automatically" doesn't necessarily mean "like font-lock".  I think we
should know better than get ourselves once again into an adventure
like font-lock, which even today, with JIT and all the years of
experience and improvements, is still a headache, if not a PITA.  If
there's no other way to do something that's really necessary, fine;
but we should avoid such features as much as possible.

For example, in this case, I'm beginning to think that we should
render SPC characters similarly to what we do with TABs: produce a
stretch glyph of a suitably computed width, and perhaps introduce a
variable space-width (like tab-width) to help Lisp programs with
controlling that.  Note that 'space' display property supports values
that are symbols, in which case it uses the symbol's value -- this
allows Lisp programs to change the value of a buffer-local binding of
the symbol, and have the indentation change at the next redisplay
cycle (a.k.a. "immediately").  Doesn't that provide a better way for
controlling indentation than font-lock style scanning of the visible
portion of the buffer "just in time"?