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

List:       kwrite-devel
Subject:    Re: kte autobrace
From:       Jakob Petsovits <jpetso () gmx ! at>
Date:       2009-10-23 3:55:41
Message-ID: 200910222355.41733.jpetso () gmx ! at
[Download RAW message or body]

Sorry for breaking the thread a bit, I'm not currently subscribed to the 
kwrite-devel list. Please CC me in any replies for this thread.

On Wednesday 21 October 2009, Milian Wolff wrote:
>The thing is: Many use the following style:
>
>namespace foobar {
>class someclass {
>};
>}

True. I even know of code bases (undisclosed to protect the guilty) where 
namespace contents will be indented in header files but not in the .cpp.
It's probably difficult to solve this perfectly (leading to lots of uncool 
configuration and bugs), which tempts me to solve it in a simpler fashion.

>I actually use it myself most of the time, just not in the snippet above
>:) Here of course, kte_autobrace fails. Using indendation is imo not good,
>instead it should look at the number of opened/closed braces and act
>accordingly.

Nah, I think indentation is totally the way to go. Opened/closed braces are 
*much*, **much** more complicated as they also involve stuff like string 
contents and comments; worse, they break if you haven't closed a brace 
somewhere; but worst, they require full parsing of the rest of the file.

I did my best to design the algorithm in a way that is both robust and 
scalable, which is significantly harder when you use proper parsing.
Thus I retract my previous statement - it's not just ease of implementation,
I also believe the indentation/regexp approach makes for a better user 
experience for the reasons outlined above.

May I suggest a different solution instead which involves a simple list of 
strings or regexps to search for in a line, causing the plugin not to trigger, 
with "namespace" being in the default list of exceptions? That will work just 
as well, and can even be configured easily if you put it in a kte_autobracerc 
file. (Such a file would also make it very easy to customize the characters to 
trigger the plugin.)

>> On Wednesday 21 October 2009 20:02:04 Jakob Petsovits wrote:
>> > On Wednesday 21 October 2009, Milian Wolff wrote:
>> > I doubt making the code more intelligent, maybe by using a simple parser
>> > instead of regular expressions, would introduce such a big performance
>> > penalty.
>>
>> Using regexps was not so much about performance but rather about ease
>> of coding :P
>
> Having the above in mind, maybe a parser is really required, since using 
> regexps on the whole, possible big, file will lead to noticably performance 
> penalties. One could potentially even make it somewhat "smart" with storing 
> brace occurences, though this might fail on LISP or other docs with much 
> braces/parens and the like. One should probably profile/benchmark this, and
> see how much time would be spent on a big file, when inserting a line at the 
> bottom.

I cast a big "no" vote for everything that has O(n) characteristics for 
scanning the remainder of the file ("n" being the number of remaining lines).
I'm obviously a big fan of parsers, but I think they are just not the right 
tool for tackling this problem.

Cheers,
  Jakob
_______________________________________________
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]