Re: Variable-width font indentation

[Eli Zaretskii <eliz@gnu.org>]

> Cc: emacs-devel@gnu.org, eggert@cs.ucla.edu
> From: Clément Pit-Claudel <cpitclaudel@gmail.com>
> 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.