Hi dmitry,

lets say I have php file that looks like this:


Now I wan't to replace with this one

So I hit Ctrl + R, set options "Regular Expressions", "Promt on replace".
Text to find: \*/
Replace with: *\r\n* $Id$\r\n*/

After replacing, I got such a line in code:

After closing and re-opening the php file, I get normal code representation (new lines are correct), but before closing the file, I thought I messed something up...

Hope you understand .

Bye

It is an expected behaviour as neither new lines (\n) nor line feeds (\r) are supported in Find and Find/Replace functionality.

No it isn't, so you want to tell, that your product supports find/replace with regular expressions, you document it in your phped.chm help file and it's actually working, just you didn't finished such characters rendering at fly time, but it's not supported. Did I understand that right?

P.S. '\r' is not a line feed as you say, it's a cariage return.

I've not gotten as far as testing whether it sort-of-kind-of-works with the replacement text, as would appear in your example, but I can tell you that the IDE falls flat on its face and quietly fails if you try to *search* for multi-line text. Right now, I have to do about 60% of my searches in another text editor because of this. Admittedly, PhpED is far from the only editor to have this huge deficiency, but it's disappointing nonetheless.

(Interestingly, this seems to be more of a Windows issue. I've never run into a Mac editor that supported PCRE but not over multiple lines. Before using Windows, this sort of limitation would never have even occurred to me as being a realistic possibility. However, it's a very common limitation on Windows. I wonder if there's some issue with the Windows port of the PCRE library, or something like that. It sure is a big limitation, though, whatever its root cause.)

Hi bobwilliams,

you can search multiline texts in phpEd, but you have to check "Regular Expression" checkbox before, and then type regular expression to have ability to search through multiline texts. You also have to know what type of new line break type your document uses - \r\n, \r, or \n.

It's a headacke for me too... BTW, what editor do you use to search multiline texts?

Cheers

I've not been able to get it to work. If I have this in a UNIX-format file:

a
b
c
d
e
f
g

and I search for "b\n\c\n", the IDE won't find it, and Dmitri has said it won't work.



For simple stuff, I use TextPad. However, it only supports POSIX syntax, which is much more limited than PCRE syntax... but at least it works. For the heavy lifting--like when I'm refactoring code--I am forced to resort to BBEdit over on my Mac. I've yet to see any tool on any platform with search/replace functionality better than BBEdit's. (BBEdit costs money, but its free sibling TextWrangler sports the same core search/replace engine, just without so many bells and whistles wrapped around it.)

I've yet to find something on Windows that does what I want. I *think* UltraEdit would fit the bill (just looking at the features list), but that's not something my employer would buy for me....

I've been trying to think of a way to use PhpED's integration features to enable use of PHP's own preg_xxx() function set for searches in the editor, but I haven't found any real docs for the integration features, nor have I been able to spend much time trying to figure it out. But if someone else knows how to whip this up and share it, I'm sure it'd be highly prized in the community here.

It's because most of the editors are line-based, in other words, internally it represents the text as array of lines. It's hard to impossible to run multiline searches with this representation. At least we'd need a stream-capable regexp supporting library and form the stream on the fly. I tried to talk to PCRE maintainers/developers and explain them why it would be good and important but it went to nowhere.

Here's a question, then. Many languages, including C/C++ (with which I assume PhpED was written), represent an array in memory as if serialized into a simple byte vector. Assuming you can insert or maintain the appropriate line break sequence as the last element/character of each line, this should mean that the array representing the text data would in fact be stored in memory as a vector perfectly suited to passing into PCRE.

From my understanding of PCRE, it essentially just requires you to hand it the compiled pattern and a string of data, and tell it what characters to consider line breaks, and it goes to work. So passing in your array of data should, theoretically, require nothing more than a cast.

Is there something I'm missing here? Does your text representation include more than just the text itself? If so, could it be converted on-the-fly? I obviously don't know anything about PhpED's internal implementation, so I'm interested in whether this issue is one that can we can reasonably assume may be addressed in a near-future update, or if it's the sort of thing that would require a major rewrite to accomplish.

no, there is no way to pass it into PCRE.
It's a wrong assumption that an array of strings stores them in memory sequentially. What if you add one character in the middle of the 1st line? Will it re-allocate or move all the remaining lines to keep them together? No. It will allocate new line buffer for the edited line and it will be stored somewhere in the memory, not necessarily before the 2nd line.

Regardless of how you store text internally, why can't you serialize it for sending to PCRE? Given the need to do so for numerous other features in the IDE (from integration to copying to the clipboard to saving to ...), you obviously have this ability. You'd have to re-parse the result, but I imagine the whole process would be similar to saving, closing, and reopening a file. Or am I missing something?

you're right.. it only takes time to get the lines serialized. For example file like nusoap.php is serialized in 0.3 sec. So each find-next will be slower by at least 0.3 sec.

I'd like to have that option. Right now, I'm frequently forced to follow this series of steps:

1) Select all or some portion of my code.
2) Copy it to the clipboard.
3) Fire up another editor.
4) Paste.
5) Do the search-and-replace.
6) Select everything.
7) Quit the editor.
8) When it asks, tell the editor that I don't want to save changes.
9) Switch back to PhpED.
10) Paste.

Needless to say, all this takes *far* long than 0.3 seconds :-). And, I suspect that the vast majority of PHP files are no more than a few hundred lines, which means the operation should be faster than with nusoap.php (which, if I remember right, is quite a bit bigger than a few hundred lines). And if you're working on a selection, as I usually am, the search text may only be several to several dozen lines. In other words, the performance penalty will be small and very much worth it. And as hardware gets faster, the time will just go down, and hopefully, you will someday be able to work around the problem.