Re: Variable-width font indentation

[Eli Zaretskii]

> Cc: address@hidden, address@hidden
> From: Clément Pit-Claudel <address@hidden>
> Date: Wed, 7 Mar 2018 15:32:53 -0500
> 
> >> But changing tab-width doesn't change the contents of the buffer, whereas 
> >> what you're advocating for does, right?
> > 
> > No, it doesn't.  I'm advocating a way of changing the width of
> > whitespace characters on display to account for variable-pitch font,
> > not any change in the 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.

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

> >> * What happens in indentation-sensitive languages (Python, F#, Haskell, 
> >> etc)?
> > 
> > Same as today (the buffer contents will not change from what it is
> > today).
> 
> I meant to ask what the code would look like, not what the buffer contents 
> would change to.

Hopefully, the buffer will look like users of those languages expect
it to look.

> >> * What happens in comments?
> > 
> > Nothing special.
> 
> Same question: what do the contents look like (what text properties do you 
> apply on leading spaces in comments?)

I hope we will be able to manage without display properties at all.

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

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

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

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