[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Variable-width font indentation

From: Clément Pit-Claudel
Subject: Re: Variable-width font indentation
Date: Thu, 8 Mar 2018 14:55:20 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

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 
Paul's algorithm is not too bad in that sense: these two examples align 

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]