[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-06 21:44:42
Message-ID: op.uccj0sbo9lgty9 () lenobin
[Download RAW message or body]

On Fri, 06 Jun 2008 20:00:28 +0200, Leo Savernik <l.savernik@aon.at> wrote:

> Am Donnerstag, 5. Juni 2008 schrieb Dominik Haumann:
>> We also could allow both:
>> If the return value is a number, treat it as it is now.
>> If the return value is a array, interpret it as tabs + spaces.
>>
>> returning [2, 18] means 2 tabs followed by 18 spaces.
>>
>> That's not a problem at all. The only question is whether to provide a
>> config option... I'd say no and interpret it like this:
>> If replace tabs with spaces is enabled, simply always use spaces. If  
>> this
>> is not enabled use tabs + spaces...
>
> I'm ok with this solution. It keeps it easy to write new indenters and  
> stays
> compatible to what we have now (btw BC does count for the indenter api,  
> too!).
>
> I'd like to make the following clarifications on the notion you  
> suggested.
>
> Variant 1
> return <indent-spaces-count>;
>
> <indent-spaces-count> is the number of spaces the given line shall be
> indented. Spaces will be replaced automatically by tabs as specified by  
> the editor settings.
>
> Variant 2
> return [ <indent-depth-factor>, <surplus-spaces-count> ];
>
> <indent-depth-factor> represents the base indentation for the current  
> line in
> spaces multiplied by the current indent width. The spaces will be  
> replaced
> automatically by tabs as specified by the editor settings.
> <surplus-spaces-count> specifies a count of spaces additional to
> <indent-depth-factor> to indent the current line with. The surplus  
> spaces are
> never replaced by tabs regardless of editor settings.

I just want to clearify, in case there was any doubt about this. The most  
recent patch that was posted here did allow both the current way of  
returning a simple integer, in addition to an array containing the indent  
level and the "alignment".

It works like this:

Variant 1: return <indent-spaces-count>
This is like Leo described, and how it is currently implemented.

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:

return X
return [ X , 0 ]

The question that remains is should X be "spaces-count" or "indent-depth".  
With this feature, I think some of the motivation for using the  
"spaces-count" is lost. It might be possible to use "indent-depth", and  
remove the "indentWidht" parameter to the script indent function, because  
it wouldn't be needed anymore if you would use lastIndent + 1 to indent  
instead of lastIndent + indentWidht.

I don't have anything against changing the second element to a number of  
spaces to add in addition to the indent, instead of an absolute value.

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