Re: Variable-width font indentation

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Clément Pit-Claudel <address@hidden>
> Date: Tue, 6 Mar 2018 15:11:29 -0500
> 
> > Thanks, but I still don't see why we couldn't simply "adjust" the 
> > width of white space using the 'space' display property.
> 
> Because "I'm not aware of a way to get a specified space whose width equals 
> that of a particular string, without measuring the string beforehand.  Is 
> there a way?" :)

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.  Then translate that into
floating-point "column" numbers by dividing by width of some suitable
character (it could be SPC, but that is a bad idea with some fonts, so
maybe something else, like 'e').

> I'd have used space properties if I had known a way to get a space of the 
> same with as these ghost characters).

See above.  And there's font-get-glyphs.

> And there are many other issues, of course: we don't want to apply the 
> display property to more than one stretch of space, and the code doesn't deal 
> properly with tabs vs spaces, etc.

Please elaborate, because I don't understand those issues well enough
to see if and how they can be resolved.

> >> I do agree that it doesn't look too bad, and presumably a C
> >> implementation of the algorithm above would be very fast, since it
> >> could build the "spine" above during redisplay.
> > 
> > Indenting during redisplay is a bad idea, because it will disable 
> > almost every redisplay optimization.
> 
> I think we're using "indenting" to mean different things.  (Just to be clear: 
> the process I'm describing doesn't call indent-line-function, nor any of the 
> indentation machinery)

Then what _do_ you mean by "building the spine during redisplay"?

> > I actually don't understand why you worry about performance: the 
> > function you wrote is the morel equivalent of C-\
> 
> C-\ is toggle-input-method on my machine; is that what you meant?

Sorry, I meant M-C-\, of course.

> > , and that one is not fast with the current implementation.  We never
> > modify indentation of non-current lines anyway, we expect the user to
> > type TAB or some electric character to reindent a line, and we expect
> > them to use C-\ to reindent more than one line.  Automatic adjustment
> > of indentation might be a good feature, but it would be a separate
> > feature.
> 
> 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.

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