Re: Variable-width font indentation

[Clément Pit-Claudel]

On 2018-03-07 12:22, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Tue, 6 Mar 2018 16:47:51 -0500
>>
>>> I don't see a need for such a feature, sorry.  We have indentation
>>> already; its only problem is that it doesn't work well with variable
>>> pitch fonts.  That's what we need to try to fix, if we care about the
>>> capability of displaying program code with such fonts.
>>
>> I'm thoroughly confused: doesn't the algorithm that Paul proposed, and that 
>> I show an implementation of, do exactly that?
> 
> 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?

>> Do you want to get the indentation code involved because the heuristic isn't 
>> perfect?
> 
> More like because the existing indentation algorithms are okay, and I
> see no need to change them to something else.

Neither do I, and indeed I'm not proposing to change existing indentation 
algorithms :)

>> In your world, concretely, what happens when I open xdisp.c and press M-x 
>> variable-pitch-mode? Does everything look misaligned until I M-x 
>> indent-region the whole file?
> 
> Yes.  It isn't different from what happens when you change tab-width.

But changing tab-width doesn't change the contents of the buffer, whereas what 
you're advocating for does, right?

>> What about a file from a different project that uses a different indenting 
>> convention?
> 
> Not sure how that is relevant.  A different indentation convention
> will look differently, of course.

This is relevant because the method that Paul originally proposed (which I'm 
not even advocating for — I'm not even sure yet whether it's good or bad) does 
not require changing the buffer or the actual number of spaces present on each 
line in the buffer.

Maybe I just don't understand what you're advocating for.  AFAIU, you're 
suggesting that we should teach indentation methods about variable-pitch fonts, 
so that they indent text to a particular pixel offset instead of a particular 
column.  Is that correct?

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.

Some questions on the solution you propose:

* What happens in major modes that don't provide indentation support?
* What happens in indentation-sensitive languages (Python, F#, Haskell, etc)?
* What happens in comments?
* Do I need to call M-x indent-region every time I switch between 
variable-pitch and fixed-pitch?
* If I close and reopen a file in variable-pitch mode, do I need to re-run M-x 
indent-region?
* In variable-pitch mode, what gets saved to disk after I run M-x indent-region?

Thanks,
Clément.