Re: Variable-width font indentation

[Clément Pit-Claudel]

On 2018-03-06 15:40, Eli Zaretskii wrote:
>> 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.

Yes and no: it might be offscreen.  But posn-at-point is a useful suggestion, 
thanks :) 

> 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 don't think I need that part.

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

Thanks, I'll look into this.

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

That code was just a rough draft, so it's plenty of corner cases that I didn't 
think about yet.  That's all :)

>>>> 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 meant build a prefix string (which the code I sent called the "spine") to use 
instead of leading spaces.
The ghost characters that you noticed are the value of the spine on that line.

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

Ah, yes, I see. That's not what the code I offered does at all, I think.

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

Wait, never do what?

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

Clément.