[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.
- Re: Variable-width font indentation, (continued)
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06
- Re: Variable-width font indentation, Paul Eggert, 2018/03/06
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/07
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/07
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/07
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/07
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/08
- Re: Variable-width font indentation,
Clément Pit-Claudel <=
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/08
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/08
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/09
- Re: Variable-width font indentation, Paul Eggert, 2018/03/09
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/09
- Re: Variable-width font indentation, Paul Eggert, 2018/03/09
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/09
- Re: Variable-width font indentation, Paul Eggert, 2018/03/09
- Re: Variable-width font indentation, James Cloos, 2018/03/09
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/10