[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:       Dominik Haumann <dhdev () gmx ! de>
Date:       2008-06-09 17:50:39
Message-ID: 200806091950.39411.dhdev () gmx ! de
[Download RAW message or body]

On Friday 06 June 2008, Robin Pedersen wrote:
> 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

It makes sense as you describe. If scripts happen to usually have the 
absolute value, we should by all means use the absolute value :)

In the case of [10,8] maybe we should simply ignore the 8?

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