emacs-devel
[Top][All Lists]
Advanced

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

>>>> * 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)) 
'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?

(progn
  (wwwwwwww a
            b
            c)
  (iiiiiiii a
            b
            c))

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

Clément.




reply via email to

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