Version: 2.1 (using KDE 3.1.1) Installed from: SuSE Compiler: gcc version 3.3 20030226 (prerelease) (SuSE Linux) OS: Linux (i686) release 2.4.20-4GB both Kate and Kwrite are not able to find newline characters in files on my machine. no matter if I type in \n into the search field or select 'newline' from the regular express dropdown the result is always a message saying 'Search string '\n' not found!' (with the regular expression checkbox is checked) things that DO work are TAB \t, and WHITESPACE \s the setting of End of Line Mode doesn't influence the result. newlines can't be found in files created on Mac, Windows, or Linux
why do you want to find \n ? it is not supported, atm, as these chars are not in the buffer, but why to find them at all ? you can detect lineend/start via regex, no need for \n, multiline searches not work at all atm, that would be a valid reason perhaps
add it to the wishs, multiline searches would be nice indeed, I guess
wish :)
> why do you want to find \n ? because automatic wrapping prevents from finding sometimes. looking for "blah bloh" does not match if between blah and bloh a wrap occurs. mfg
Multiline search is a must for programming development issues.
Multiline searches would be really helpful for writing code. Pretty much the only time I use vim instead of kate is when I need to do a multiline search.
Question: How do you in a simple way replace end-of-line with space in ADAM BERTIL CESAR DAVID ERIK ... in order to produce ADAM BERTIL CESAR DAVID ERIK ... This is a trivial and common task in not only programming and easily done in all normally designed editors that recognise end-of-line (written \n, ^p, or similar). And the other way round: To convert space-delimited words into a column is carried out equally simple. -- Please, Kwrite/Kate team!
Tore: the second part of your question is a duplicate of bug 45529. And yes, four years? It's about time this got done! Since KATE is line-based, I have a suggestion on how to do this. (This assumes 'regular expression' is on; the BOL/EOL matching will be different otherwise and I'm not sure what you would use for the delimiter if not using a regexpr.) 0. Split the expression at all '\n's. 1. If the current split part is not the last one, add '$' to the end. 2. Find the first match (if no match, display dialog as usual). 3. If the current split part is the last one, we have found a match; exit. 4. Make the next split part 'current', and add '^' to the beginning. 5. Repeat step 1 (but continue with 6). 6. If the next line matches the current split part, go to 3. 7. Reset the current split part to the first part and start over at 1.
> 0. Split the expression at all '\n's. ^(\n)+$ --split--> ^( and )+$ This will never work. You can not simply split a regular expression.
>> 0. Split the expression at all '\n's. > > ^(\n)+$ --split--> ^( and )+$ > > This will never work. You can not simply split a regular expression. Hmm, good point, you'd have to somehow do this logic in the regexpr matcher... but it still might be possible to do something conceptually similar (no, it wouldn't be easy or pretty) to do the matching without having to do the match against the entire document as one long string.
you for example can have a multiline-edit. If line 1 of matches, try to match line 2 etc. This will work and should even be pretty fast. The other idea was to add an additional interfaces which is character based and not line-based. As kate internally is line based, the character based interface would be very slow I think.
*** Bug 36803 has been marked as a duplicate of this bug. ***
*** Bug 143661 has been marked as a duplicate of this bug. ***
Bug 36803 mentions that this isn't limited to \n. Also, this isn't only about find, but replace as well. Microsoft Word's find & replace utility uses escapes like ^p for new paragraph, ^l for linefeed, etc. It might be worth looking at that. It's easier to use than regex, but still lets you specify commonly used whitespace formatting characters.
...but I only see bug 36803 talking about tabs and newlines. Searching for tabs ('\t') already works, and there is already a separate bug (bug 45529 and/or bug 127765) dealing with the ability to use '\n'/'\t' in replace. Maybe the various parts of it are independently duplicates of different bugs, but it still does not report anything new. I don't want to go the Microsoft way, they don't do ANYTHING consistently. Using '\n' is The Right Way AFAIAC. Anyway there is no such thing as a distinction between a hard break (paragraph) and a soft break (linefeed) in pure text. It's a typesetting distinction. (Unless you count '\n\n' as a hard break, but I just gave the search pattern for that; no need for some new sequence.)
*** Bug 131157 has been marked as a duplicate of this bug. ***
*** Bug 55949 has been marked as a duplicate of this bug. ***
Note: some of the duplicates talk about deleting lines containing certain text (or lack thereof, i.e. blank lines). Assuming 'replace' removes the right text, multi-line find/replace will allow this, but we should be sure to test.
This feature is now implemented in KDE4 trunk. Be sure to search in Escape sequences or in Regular Expression mode. Both now allow multi-line searching. (For regex the dot ('.') does not match newlines. If you need that search for "(?:.|\n)". The "?:" makes the parentheses non-capturing.)
There is no option to choose the needed mode, so: http://bugs.kde.org/show_bug.cgi?id=174281 "continuation" of this report.