<table><tr><td style="">cullmann added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D23457">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #8C98B8;
          color: #6B748C;
          font-style: italic;
          margin: 4px 0 12px 0;
          padding: 8px 12px;
          background-color: #F8F9FC;">
<div style="font-style: normal;
          padding-bottom: 4px;">In <a href="https://phabricator.kde.org/D23457#519217" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">D23457#519217</a>, <a href="https://phabricator.kde.org/p/ahmadsamir/" style="
              border-color: #f1f7ff;
              color: #19558d;
              background-color: #f1f7ff;
                border: 1px solid transparent;
                border-radius: 3px;
                font-weight: bold;
                padding: 0 4px;">@ahmadsamir</a> wrote:</div>
<div style="margin: 0;
          padding: 0;
          border: 0;
          color: rgb(107, 116, 140);"><p>Maybe they'll also see it as ktexteditor/kate using a regex engine that matches what the abundance of online pcre docs say, and how other editors that use pcre behave?</p>

<p>IIUC, '\s' was workedaround so as not to match a newline so that the search pattern wouldn't be considered multiline (isMultiLine() function), which makes findAll and replaceAll slower as it took longer, v.s. just matching against each line separately.</p></div>
</blockquote>

<p>Actually, it is not faster.<br />
If you take a look at the code, for single line regex, it iterates over the individual lines.<br />
For multi line regexes, it will first concatinate all lines into one buffer.<br />
For large files that is "very" slow.<br />
And if you e.g. search + hit then "next match", this will be done again and again.</p>

<p>But given it only happens more often for stuff containing \s, I assume that should be not that problematic, thought not sure if the behavior change is that good.</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>The thing is, what kateregexp did was replace '\s' with '[ \t]', which users who want this behaviour can easily use.</p></blockquote>

<p>That is true, perhaps we should add this as extra into the menu as proposal, like \s/...</p>

<blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><p>Technically it's a whole new class, QRegularExpression, some different behaviours are sort of expected...</p></blockquote>

<p>;=) That is really no good reasoning why one changes a behavior.<br />
It is clear that if you port something over to a new class, behavior might change, but that doesn't make it a good thing per default.</p>

<p>On the other side, I see you did a lot of testing, that is highly appreciated.</p>

<p>I will think a bit more about this patch.</p>

<p>As you seems to have now played a bit with this part of the code, are you interested in test out the still not merged <a href="https://phabricator.kde.org/D19367" class="remarkup-link" target="_blank" rel="noreferrer">https://phabricator.kde.org/D19367</a> change?</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R39 KTextEditor</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D23457">https://phabricator.kde.org/D23457</a></div></div><br /><div><strong>To: </strong>ahmadsamir, KTextEditor, dhaumann, cullmann<br /><strong>Cc: </strong>kde-frameworks-devel, kwrite-devel, LeGast00n, GB_2, domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann<br /></div>