[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    Re: [patch] Ability to force indent with spaces in alignment from
From:       "Robin Pedersen" <robinpeder () gmail ! com>
Date:       2008-06-09 11:34:08
Message-ID: op.uchbq6079lgty9 () lenobin
[Download RAW message or body]

On Mon, 09 Jun 2008 00:11:09 +0200, Leo Savernik <l.savernik@aon.at> wrote:

> Am Freitag, 6. Juni 2008 schrieb Robin Pedersen:
>> Variant 2: return [ <indent-spaces-count> , <alignment-virtual-column> ]
>> The first element is exactly like variant 1. The second contains the  
>> absolute column for alignment (counting as spaces like the first  
>> element).
>>
>> Example: return [ 8 , 14 ]
>> Indent 8 spaces (if using tabs with a width of 4, use two tabs  
>> instead).  
>> Then align by adding 14 - 8 = 6 spaces.
>>
>> The second element may be thought of as a "minimum" alignment. The  
>> first  
>> non-whitespace character in this line must be at least 14 spaces,  
>> meaning  
>> that any value less or equal to the first element is equivalent to  
>> returning just the first element using variant 1.
>>
>> The reason that the alignment column is absolute, and not a number of  
>> spaces to add to the first indent was simply because the script I was  
>> working with happened to have it available as an absolute value, taken  
>>  from a cursor object on the previous line.
>>
>> > Does this description accurately describe how you (pl) think this api
>> > extension should be?
>>
>> I don't know why you want the first element in variant 2 to be  
>> interpreted
>>   differently than the return value in variant 1. I think it would be
>> better to use same value, so that these two are guaranteed to be
>> equivalent:
>
> Oh, I didn't say I want it that way, I just wanted to clarify how I  
> understood
> the API would work. I'm ok with your solution, as long as it's properly
> documented (which it now is). And you're right, the number of spaces is  
> more
> flexible than the indent-depth-factor, we should keep that.
>
> Still one question: If we have, say [10, 8], what happens? Does 10 take
> precedence over 8?

Yes. As of the most recent patch, it does. As long as the second element  
is less than or equal to the first, it's as if it doesn't exist.

It could also be changed so that [10, 8] would mean indent the equivalent  
of 10 spaces + 8 extra spaces. To get that, you currently need [10, 18].

> mfg
> 	Leo

-- 
Robin Pedersen
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel

[prev in list] [next in list] [prev in thread] [next in thread]