emacs-devel
[Top][All Lists]
Advanced

[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: Tue, 6 Mar 2018 15:11:29 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-06 11:36, Eli Zaretskii wrote:
>> From: Clément Pit-Claudel <address@hidden> Date: Mon, 5 Mar
>> 2018 20:40:14 -0500
>> 
>> The following code gives a preview of what the algorithm that we've
>> been discussing produces:
> 
> 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?" :)

IOW, I'm all for it, but I don't know how.

> Your implementation has a few issues.  First, if you move the cursor 
> vertically at column zero, do you see "ghost" characters displayed
> at cursor position?  Hiding characters by displaying them with
> foreground color identical to the background color has its limits
> ;-)

That's a feature :) (Just to be clear: that was the easy way to get a feel for 
what the algorithm that Paul and I were discussing would produce; I'd have used 
space properties if I had known a way to get a space of the same with as these 
ghost characters).

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.

> Also, with this implementation, the braces in the 'if' and 'else' 
> blocks no longer align.  E.g., try to indent this snippet:
> 
> foo () { if (something) { do (anything); } else { do
> (something-else); } }
> 
> I think this misalignment will be annoying.


Indeed, this was discussed in this thread; Paul thinks it's not an issue; I'm 
not convinced (I tend to agree with you) :)

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

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

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

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

Clément.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]