[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-05 19:06:58
Message-ID: 200806052106.58676.dhdev () gmx ! de
[Download RAW message or body]

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

Anyway, the scripting indenters are meant to be changed, so a _developer_ is 
also able to edit a .js-file and e.g. change an option at the top of the 
file. That's how you can configure the cstyle.js indenter.

So I'm not against supporting it, but the default should be to not require 
the separation of tabs + alignment... It's much harder to do in js anyway.

Dominik

On Thursday 29 May 2008, Robin Pedersen wrote:
> This is an updated patch. The functionality is the same, but the
> implementation and the scripting API is different:
>
> Instead of returning the alignment as a global variable, the script's
> indent function can either return only the indent amount like before, or
> an array with the indent amount and the alignment. An example is given in
> the ruby indenter included in the patch.
>
> Please let me know what you think.
>
> On Wed, 28 May 2008 00:10:39 +0200, Robin Pedersen <robinpeder@gmail.com>
>
> wrote:
> > This patch makes it possible in an indent script to align code with
> > spaces, even if tabs are normally used to indent.
> >
> > Example situation where this is useful:
> >>   >   foobar("Hello, world",
> >>   >   ......."How are you?")
> >
> > Notice how the second line is aligned under the opening parenthesis in
> >
> > the first line. Currently, the kate indenter does this instead:
> >>   >   foobar("Hello, world",
> >>   >
> >>   >   >   ..."How are you?")
> >
> > If the tab width is changed from four to eight, you get this:
> >>       >       foobar("Hello, world",
> >>       >
> >>       >       >       ..."How are you?")
> >
> > The second line is no longer aligned.
> >
> > The result is that if you're using tabs to indent, you can't change the
> > tab width, which is the whole point of using tabs in the first place.
> > If all alignment is done like this, and tabs are only used for the part
> > that is actually indenting, team members can edit the same file using
> > different tab width without problems with unaligned code.
> >
> > The scripting API implemented by the patch works like this: The script
> > returns the indent width /without/ the extra spaces for alignment.
> > Before returning, the script updates a global variable named "align",
> > setting it to the column where the alignment should be. If the value of
> > the align variable is greater than the returned indent with, the
> > difference is added as spaces, otherwise it's ignored.
> >
> > This is backwards compatible. Indent scripts that don't use this
> > feature work like before.
> >
> > I haven't found a way to keep the alignment when indenting manually
> > (e.g. ctrl+i), but I'm not sure if it's needed.
> >
> > What do you think? I'm not sure if this is the best way to do it, but
> > I'd really like to have this feature.


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