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

List:       kwrite-devel
Subject:    Re: Mixed tab and space handling
From:       "Robin Pedersen" <robinpeder () gmail ! com>
Date:       2009-02-24 15:59:24
Message-ID: op.upu5dapn9lgty9 () arch
[Download RAW message or body]

On Tue, 24 Feb 2009 16:13:32 +0100, Parker Coates  
<parker.coates@gmail.com> wrote:

> On Mon, Feb 23, 2009 at 03:00, Robin Pedersen wrote:
>> On Sun, 22 Feb 2009 21:07:19 +0100, Parker Coates wrote:
>>
>>> Hello folks,
>>>
>>> I'm from the camp of developers who prefer to use both tabs and
>>> spaces. Tabs for structural indentation; spaces for aesthetic
>>> alignment. I won't bother you with the usual arguments as they've been
>>> put down elsewhere.
>>>
>>> Kate doesn't do all that well with this set up. The major issue issue
>>> is that when Kate changes the indentation of a line, it first removes
>>> all whitespace from the line and then blindly reinserts the required
>>> amount of brand new whitespace. All the alignment information is lost
>>> in the process.
>>>
>>> --->int someSpecialFunction( int number1,
>>> --->.........................int number2
>>> --->.......................)
>>>
>>> becomes
>>>
>>> --->--->int someSpecialFunction( int number1,
>>> --->--->--->--->--->--->--->--->.int number2
>>> --->--->--->--->--->--->--->...)
>>>
>>> when indented (assuming tab and indentation width are both four).
>>>
>>> The attached patch (against kdelibs/kate/utils/kateautoindent.cpp)
>>> attempts to correct this behaviour by preserving the space based
>>> alignment when indenting. The code itself is pretty straightforward,
>>> but I'd appreciate any comments. I would like to hear your thoughts on
>>> the conditions used to enable this alternate indentation mode. At
>>> first I considered adding a user visible switch, but I quickly
>>> realised this indentation mode conflicts with several existing
>>> settings:
>>>  - It only makes sense to use when using tabs for indentation.
>>>  - It only works when the indentation width is a multiple of the tab
>>> width, otherwise the combination of tabs and spaces causes a conflict.
>>>  - It only works properly when "Keep extra spaces" is enabled as
>>> otherwise the alignment would be truncated to the nearest multiple of
>>> the indentation width.
>>>
>>> Because of these restrictions I don't really think a UI setting could
>>> be implemented cleanly. I also don't think it is really necessary, but
>>> that's based on the assumption that those using the above combination
>>> of settings would prefer the new behaviour. That seems likely to me,
>>> but I guess there could be a use case I'm not considering.
>>>
>>> Feedback is very much appreciated.
>>>
>>> Parker
>>>
>>> P.S.: Please copy me on replies as I am not subscribed to the list.
>>
>> Last summer I implemented the feature that allows an indentation script  
>> to
>> return an "align" amount in addition to the indent amount, which makes  
>> it
>> possible to implement the kind of  indenting you want. This is used by  
>> the
>> ruby indenter, but unfortunately not by the cstyle indenter yet.
>
> As implemented, my patch takes effect only if an alignment of 0 was
> passed to the indentation function. So this shouldn't cause a
> conflict.
>
>> When I committed the change, I realized that using the manual indent  
>> actions
>> whould break the alignment. I didn't try to fix it simply because, like  
>> you
>> say, it's impossible to implement a clean UI setting for it. The  
>> problem is
>> that it's very difficult to do it correctly when indent width is equal  
>> to
>> (or a multiple of) tab width, which isn't the case with kate default
>> settings, intent=4 and tabs=8.
>
> I guess I'm arguing that since there is only one specific combination
> of settings for which this new behaviour makes sense, there is no need
> for a UI setting. I'm proposing we enable this behaviour if and only
> if we're using tabs, we're keeping extra spaces and the indent width
> is a multiple of the tab width.
>
>> If an indentation script was originally used to create the tab intent +
>> alignment, it could be possible to do it corectly even if indent isn't a
>> multiple of tabs, by involving the intentation script when using
>> intent/unindent. This is the idea:
>> 1. Remember the current sum of indent+alignment
>> 2. Call the indent script, to get the correct indent+alignment
>> 3. Subtract the alignment from the sum, to get the current indent
>> 4. Increase/decrease the indent
>> 5. Update document with the changed indent + the correct alignment
>>
>> The alignment value could be cached the first time, but can't be saved
>> across sessions, so the implementation must be prepared to use the
>> indentation script.
>>
>> However, this would only work with a alignment-aware indentation  
>> script. My
>> guess is that you didn't use an indenter, but just want kate to  
>> preserve the
>> alignment that you created by hand (or using another editor). In that  
>> case,
>> I think it's impossible unless indent is a multiple.
>
> Correct, I don't use an indenter and simply want Kate to preserve my
> alignment when indenting manually.
>
> What do you actually think of my patch? Do you think it makes sense to
> commit? I can see that you have big ideas of using indentation scripts
> to give roughly the same behaviour, but to be entirely honest, that's
> beyond my knowledge.

I think the patch itself is fine. However, you should wait for others to  
comment, as I'm not really involved in kate development atm.

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