[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 08:15:39 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
On 2018-03-06 15:40, Eli Zaretskii wrote:
>> Cc: address@hidden, address@hidden
>> From: Clément Pit-Claudel <address@hidden>
>> Date: Tue, 6 Mar 2018 15:11:29 -0500
>>
>>> Thanks, but I still don't see why we couldn't simply "adjust" the
>>> width of white space using the 'space' display property.
>>
>> Because "I'm not aware of a way to get a specified space whose width equals
>> that of a particular string, without measuring the string beforehand. Is
>> there a way?" :)
>
> The "string" you refer to is already in the buffer on display, right?
> If so, you can simply use the likes of posn-at-point to measure
> portions of text in pixel units.
Yes and no: it might be offscreen. But posn-at-point is a useful suggestion,
thanks :)
> Then translate that into
> floating-point "column" numbers by dividing by width of some suitable
> character (it could be SPC, but that is a bad idea with some fonts, so
> maybe something else, like 'e').
I don't think I need that part.
>> I'd have used space properties if I had known a way to get a space of the
>> same with as these ghost characters).
>
> See above. And there's font-get-glyphs.
Thanks, I'll look into this.
>> And there are many other issues, of course: we don't want to apply the
>> display property to more than one stretch
of space, and the code doesn't deal properly with tabs vs spaces, etc.
>
> Please elaborate, because I don't understand those issues well enough
> to see if and how they can be resolved.
That code was just a rough draft, so it's plenty of corner cases that I didn't
think about yet. That's all :)
>>>> I do agree that it doesn't look too bad, and presumably a C
>>>> implementation of the algorithm above would be very fast, since it
>>>> could build the "spine" above during redisplay.
>>>
>>> Indenting during redisplay is a bad idea, because it will disable
>>> almost every redisplay optimization.
>>
>> I think we're using "indenting" to mean different things. (Just to be
>> clear: the process I'm describing doesn't call indent-line-function, nor any
>> of the indentation machinery)
>
> Then what _do_ you mean by "building the spine during redisplay"?
I meant build a prefix string (which the code I sent called the "spine") to use
instead of leading spaces.
The ghost characters that you noticed are the value of the spine on that line.
>>> I actually don't understand why you worry about performance: the
>>> function you wrote is the morel equivalent of C-\
>>
>> C-\ is toggle-input-method on my machine; is that what you meant?
>
> Sorry, I meant M-C-\, of course.
Ah, yes, I see. That's not what the code I offered does at all, I think.
>>> , and that one is not fast with the current implementation. We never
>>> modify indentation of non-current lines anyway, we expect the user to
>>> type TAB or some electric character to reindent a line, and we expect
>>> them to use C-\ to reindent more than one line. Automatic adjustment
>>> of indentation might be a good feature, but it would be a separate
>>> feature.
>>
>> I never meant to adjust indentation (that is, to change the contents of the
>> buffer): just to display existing leading spaces differently based on the
>> contents of previous line.
>
> We never do that with the existing indentation machinery, either.
Wait, never do what?
>>> In any case, I'd suggest to reindent via buffer-modification hooks,
>>> not as part of redisplay.
>>
>> Right, and that's why I worry about performance.
>
> Then don't automatically reindent, let the user initiate that.
The feature I'm offering is like font-locking, not like reindenting: it changes
the display of existing buffer elements in a way that doesn't modify the
underlying text. Given this, it makes more sense to me to run it automatically
(rather than on demand)
Clément.
- Re: Variable-width font indentation, (continued)
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/05
- Re: Variable-width font indentation, Paul Eggert, 2018/03/05
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/05
- 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, Daniel Colascione, 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, Clément Pit-Claudel, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06
- Re: Variable-width font indentation,
Clément Pit-Claudel <=
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/07
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/09
- Re: Variable-width font indentation, Clément Pit-Claudel, 2018/03/07
- 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/06
- Re: Variable-width font indentation, Daniel Colascione, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06
- Re: Variable-width font indentation, dancol, 2018/03/06
- Re: Variable-width font indentation, Eli Zaretskii, 2018/03/06