Bug 45529

On Monday 22 July 2002 03:14 you wrote:

> If regexp search is on it should be
> > inserted as a line break (Nedit does it that way).
>
> Why? that would mean that I couldn't replace the string "\n" when using
> regexp.

Sure you could use \\n just like in real regexp.

regards
 Daniel

--=20
http://www.danielnaber.de

Have you tried the sed-like functionality, with Ctrl+M? Eg   
s/oldtext/newtext/g 
 
Does this cater to your needs?  I guess we should keep this open anyway... 

s/oldtext/newtext/g doesn't work for me (doesn't replace anything), but maybe it's because my CVS checkout is already two or three weeks old. 

Wow, 2 years old and _still_ it is not possible to use this advanced text editor for a simple replacement of a comma to a tab (csv -> tsv) in an easy way. I can not take suggestions like s/ serious. If I have to use vim style, I use vim.
Please improve this text replace feature of kate in a way that every kde user can use it.

Thanks

  Thorsten 

Ctrl+M does nothing here. I think this functionality was removed a few years ago.

The functionality from CTRL + M  was merged with the katepart commandline. Press F7 and enter your command in the line edit that appears on the bottom of the editor view. You may as well set several configuration values from there, and a few other things.

Milti line searching is not possible, because kate stores the text in lines, and noone so far took the time to write the code for multiline search, and this affects normal find as well as regular expression find. It's on my TODO, and I expect to have it ready for the next release ot Kate (with KDE 3.4 or 4.0, which ever arrives first). 

My plan is to use a visual representation in normal find, for example "^P" and "^T" for newline (Paragraph) and TAB. In the case of regular expressions, \n and \t will be used of cause. If anyone have a better idea for how to represent newline and tab in normal find, please let me know btw.

IMHO the finding part is feature complete and usable thanks to the regexp editor - someone can only say that regexp is powerful but does not fit in terms of usability. The power and learning curve between simple search and regexp seems too high.

Why not a new, more semantic approach? Kate should be friendlier than vim or emacs so why not develop a better way for search and replace? Maybe a small interactive query language tool is more powerful than trying to fit a strange search string into one line?

But the real problem is that kate has no advanced replace feature - not only advanced, the basics are missing cause you can not use any magic characters like \t \r \n in the replace dialogue. (KDE-ML gave me the hint to copy a tab from the text and paste this into the replace dialogue to change csv into tsv! This works!)
  
Bye

  Thorsten

Copy-and-pasting tab or newlines from a text window was my solution.

Under Win32 I use a program called EditPlus. Its regular expressions are quirky, but it did have a nice feature that solved this issue in the find and find-and-replace dialogs. It had two buttons labeled More, one next to the Find button and one next to the Replace button. When you clicked on either More button, the text fields were changed from single line to multiline. You could then enter tabs and newlines in the field. To get out of the text field, I think you pressed Ctrl-Enter.

Just an idea. Implementing \t\r\n etc. would be plenty for me. EditPlus had those also and I used them a lot more than the More button. But non-techies won't know to use those. I'd eventually like to show K to my mom and the sales and billing staff at work, but I guarantee they'll never use \t and \n. But the More button they might use.

I'm for separating plain find/replace from regexp and giving regexp full Perl/POSIX/egrep (or all of them) functionality. I really miss replacing newlines and almost every replace I remember needs regexp. No regexp is a step back to Notepad. I don't say that everyone should learn, but I think most of people already know how to use them and if it's done standard (Perl/POSIX/egrep) way it's gonna be used. Making up another language for this is in my opinion a bad idea. Regex have been on this planet long enough to proove, that it's good for it's purpose. Some visual replacer, might be better in some cases, but it won't replace fast and plain command line regexp. I guess I have to use perl scrpits for now.

On Saturday 18 June 2005 16:08, Adrian Dziubek wrote:
> I'm for separating plain find/replace from regexp and giving regexp full
> Perl/POSIX/egrep (or all of them) functionality. I really miss replacing
> newlines and almost every replace I remember needs regexp. No regexp is a
> step back to Notepad. I don't say that everyone should learn, but I think
> most of people already know how to use them and if it's done standard
> (Perl/POSIX/egrep) way it's gonna be used. Making up another language for
> this is in my opinion a bad idea. Regex have been on this planet long
> enough to proove, that it's good for it's purpose. Some visual replacer,
> might be better in some cases, but it won't replace fast and plain command
> line regexp. I guess I have to use perl scrpits for now.


You do have regex.

Kate is storing the text in lines, which makes finding text that crosses line 
boundries non-trivial, but using the commandline search, you can *add* 
newlines allready. it also supports regex quite nicely, you can do 'replace:r 
PATTERN REPLACEMENT' and have a regex engine close to the perl5 one, it's 
using the regexp available in Qt.

I guess I'm stuck with some old version in Debian, I found this regexp command line in manual, but still don't have it. Sorry anyway.

> using the commandline search

Still GUI doesn't support this. Command line is a workaround, ok, but it is not a serious tool in GUI editor, after all.

Full regexp would be great, really, but at least special characters handling would also help a lot.

Gee, this bug is *slightly* old. It's also a subset of bug #127765. Anyone want to mark it as such?

They are nearly identical, the bug you mentioned is a duplicate (compare dates).

"Nearly identical", yes (and I am fully aware that bug #127765 is a lot more recent). However, that one is asking for *full* regexp replacement support (including things like '&' and '\1'). This one only covers escape sequences. That is why I called the other one a "superset" of this.

Come to think of it, it would be better if this one were blocking that one.

> However, that one is asking for *full* regexp replacement support

The titles say the same thing really -- full regexp replace feature, and funny thing both authors give the same examples -- escape characters ;-DDD

I think everybody is aware that it would be great to have regexp (see the title) but escape characters are needed most.

I am not inististing that bug #127765 should be a duplicate, not vice-versa, just a technical thing -- this one has 144 votes, the other one about 10. It is easier to redirect attention from bug #127765 to here, not otherwise. And Daniel spotted this feature (lack of feature) four (?) years earlier.

*** Bug 127765 has been marked as a duplicate of this bug. ***

In the CTRL-R replace feature, putting \1 in the ‘Replace’ box will replace a literal “\1” in the text, and not refer back to the regexp you searched for.  you can use positive look-ahead in some cases, but if you are not going to implement back references, some sort of pos/neg ‘look-behind’ would be useful.

Alternatively, while you sort out the problem of searching over lines, if the sed style syntax (F7) were extended to do single line searches through the whole file (not just the current one) that would fix a lot of situations we havn’t yet got a fix for.

Nicholas: it works fine for me; note that '\1' only matches the first parenthesized sub-expression, to match the whole thing use '\0'. Also make sure 'use placeholders' is checked.

Sorry. I must have a slightly older version.

kregexpeditor from kdeutils package allows to select special characters (\n,\r,\t,\a,\f,\v) from drop-down list and can insert formed regexp into search field of search/replace dialog of any kde editor... that's confusing...

This feature is now implemented in KDE4 trunk. Checking "Use placeholders" enables escape sequences for the replacement text as well.

I still wonder if we shouldn't give that a better name now, or even make its value coincident with 'regular expression' search mode (I mean, placeholders are only meaningful when the search expression is a regular expression, although '\n' and friends obviously can be meaningful always).

The \0 reference works with all search modes now, isn't that cool? :-)