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: Thu, 8 Mar 2018 11:30:51 -0500
> 
> > 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?

Maybe we could find a middle ground, whereby each one of the examples
will approximately align.  If that can be done, and the result is
acceptable, then the problem of recording the text properties in the
file and/or reindenting when the file is revisited goes away.

> >>>> * 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 :/

Looking in indent.el, my reading of the code is that the default
function is indent-rigidly.

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

Is it really needed?  With most font back-ends, a tab is displayed as
a stretch glyph whose width is an integral multiple of the width of
the space glyph for the same font.  So they should align even without
the fixed-pitch font trick.

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

It might get reasonably close, though.  Maybe this will be good
enough.

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

That's more relevant for text-derived modes, where indentation levels
are rigid and not determined by previous lines.  There we could do a
better job, I hope.