[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 11:30:51 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-08 10:39, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <address@hidden>buffer.
>> OK, understood.  So for example if I have this snippet:
>>      01234567
>>      --------
>>   0 |x = (y + 
>>   1 |     z)
>> …then on line 1 the indentation function would put display properties on 
>> each of the 5 spaces leading to `z` to align it with the `y`.  Correct?
> 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 

i = (y + 

w = (y + 

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?

>>>> * What happens in major modes that don't provide indentation support?
>>> The same as what happens today: the default functions are invoked.
>> I don't understand this part.  Concretely, what will the snippet above look 
>> like if it's shown in a prog-mode buffer, in a variable-pitch font?  Will 
>> the indentation just be off?
> When a major mode doesn't provide an indentation function, indent.el
> uses the default function, so I'm not sure what problem you see here.

I don't know what the default function is, or how it could help us determine 
proper alignment :/
I thought from earlier emails that you'd use existing indentation functions to 
determine proper indentation.

>> For example, if I have this in a C buffer:
>> /* FIXME:
>>    - long
>>      text
>>      here
>>    - more text */
>> what will this look like in variable-pitch mode?
> Hopefully, very similar, although we won't be able to guarantee
> column-wise alignment for arbitrary text.  But leading whitespace will
> certainly be aligned, something that is not universally true today.

Ah, that I understand :)
I've been using the following for that purpose for a long time:

  (font-lock-add-keywords nil `(("^[[:space:]]+" 0 '(face fixed-pitch) append)) 

>>>> * Do I need to call M-x indent-region every time I switch between 
>>>> variable-pitch and fixed-pitch?
>>> Not necessarily, not if the idea of controlling the SPC width is
>>> workable.  If it is, then the mode will simply set the value of two
>>> buffer-local variables, calculating them from the font in use.
>> That I don't understand.  Which two values are you thinking of?
> tab-width and (the hypothetical) space-width.  Actually, only the
> latter, since tab-width must be its integral multiple.

OK, I see.  This won't help with cases like the following, right?

  int main(int argv,
           char** argc)

>> As another concrete example, consider this snippet:
>> (do-stuff a
>>           b
>>           c)
>> won't you need to recompute the width of each leading space every time you 
>> change fonts?
> Hopefully, no.  At least not for approximate alignment.

OK. I don't understand how that part works yet.
The solution you propose doesn't get alignment right if I have the following 
ELisp code, right?

  (wwwwwwww a
  (iiiiiiii a

>>>> * If I close and reopen a file in variable-pitch mode, do I need to re-run 
>>>> M-x indent-region?
>> I don't understand this part either: ow will you determine how to scale each 
>> space without calling the indentation function?
> Hopefully, by calculating some representative metrics of the font.

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?


reply via email to

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