Re: Variable-width font indentation

[Clément Pit-Claudel]

On 2018-03-08 14:07, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Thu, 8 Mar 2018 11:30:51 -0500
>>
>>> Not necessarily display properties, maybe some (most? all?) of the
>>> effect could be achieved by modifying the display width of a space and
>>> a tab according to some buffer-local variable, by the display code
>>> itself, similarly to how we render tab characters now.
>>
>> Hmm, interesting.  How would that work? For example, if I have these two 
>> snippets:
>>
>> i = (y + 
>>      z)
>>
>> w = (y + 
>>      z)
>>
>> with monospace fonts 'i' and 'w' have the same width, but with 
>> variable-pitch fonts they don't and if you assign a constant width to each 
>> space the 'y' and 'z' will line up in at most one of the two examples, right?
> 
> Maybe we could find a middle ground, whereby each one of the examples
> will approximately align.  If that can be done, and the result is
> acceptable, then the problem of recording the text properties in the
> file and/or reindenting when the file is revisited goes away.

Maybe :)  I don't know how good it would look, in practice, but it's easy to 
experiment.
Paul's algorithm is not too bad in that sense: these two examples align 
pixel-perfectly.

>> I've been using the following for that purpose for a long time:
>>
>>   (font-lock-add-keywords nil `(("^[[:space:]]+" 0 '(face fixed-pitch) 
>> append)) 'append)
> 
> Is it really needed?  With most font back-ends, a tab is displayed as
> a stretch glyph whose width is an integral multiple of the width of
> the space glyph for the same font.  So they should align even without
> the fixed-pitch font trick.

Hmm, indeed.  So which problems did you have in mind when you said the 
following?

> But leading whitespace will certainly be aligned, something that is 
> not universally true today.
>> OK, I see.  This won't help with cases like the following, right?
>>
>>   int main(int argv,
>>            char** argc)
> 
> It might get reasonably close, though.  Maybe this will be good
> enough.

OK

>> OK.  I think I follow you at this point, although now I'm not sure anymore 
>> what role indentation functions will play.  A few emails ago you mentioned 
>> teaching indentation functions about variable-pitch, but the solution you're 
>> offering now doesn't seem to require that anymore, does it?
> 
> That's more relevant for text-derived modes, where indentation levels
> are rigid and not determined by previous lines.  There we could do a
> better job, I hope.

OK.  I tend to think of indentation even in text modes as being somewhat 
previous-lines dependent (wrapped paragraphs align relative to bullet points, 
for example), but I agree that it isn't as much as in programming modes.