[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Variable-width font indentation
From: |
Clément Pit-Claudel |
Subject: |
Re: Variable-width font indentation |
Date: |
Wed, 7 Mar 2018 15:32:53 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
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.
- Re: Variable-width font indentation, (continued)
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06
- Re: Variable-width font indentation, Paul Eggert, 2018/03/06
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/07
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/07
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/07
- Re: Variable-width font indentation,
Clément Pit-Claudel <=
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/08
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/08
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/08
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/08
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/09
- Re: Variable-width font indentation, Paul Eggert, 2018/03/09
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/09
- Re: Variable-width font indentation, Paul Eggert, 2018/03/09
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/09
- Re: Variable-width font indentation, Paul Eggert, 2018/03/09