[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:       Leo Savernik <l.savernik () aon ! at>
Date:       2008-06-06 18:00:28
Message-ID: 200806062000.29174.l.savernik () aon ! at
[Download RAW message or body]

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.


Does this description accurately describe how you (pl) think this api 
extension should be?

mfg
	Leo
_______________________________________________
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]