Re: Variable-width font indentation

[Clément Pit-Claudel]

On 2018-03-07 15:09, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Wed, 7 Mar 2018 13:27:35 -0500
>>
>>> Not AFAIU, no.  It is an implementation of a different indentation
>>> method.  I don't see why we should want to go that way, since there's
>>> nothing wrong with the existing algorithm, except for handling of
>>> variable-pitch fonts.
>>
>> Can you clarify what you call an indentation method? I think that's the 
>> source of my confusion.
>> I wouldn't call what I wrote an indentation method.  Maybe I'm not 
>> understanding you because of that?
> 
> I feel that we are somehow bogged down in a miscommunication from
> which I see no way out...

I think we're making progress, actually :) At least, I'm understanding things 
better.

> An "indentation method" is a method used to determine the indentation
> of a line and to insert whitespace in order to achieve that
> indentation.

Understood.  Then what I'm offering isn't an indentation method: it doesn't 
insert whitespace.
But what I'm offering is indeed an imperfect heuristic to determine the 
indentation of a line.


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

That's also what I do, only I compute the width of the spaces without calling 
the indentation function.

>> If it is correct, then it solves a problem that's different from the one I 
>> was thinking in, which is to display existing code with a variable pitch 
>> font, without the indentation function.
> 
> We cannot possibly DTRT with indentation without an indentation
> function.

Well, no, we can't DTRT every time without an indentation function.  But we can 
do fairly good, or at least it looks like that to me given the snippet I posted 
earlier.

(But note that I said the same thing at first, responding to Paul that his 
technique couldn't work.)

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

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

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

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

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?

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

>> * In variable-pitch mode, what gets saved to disk after I run M-x 
>> indent-region?
> 
> Same as what we have now.

OK.