Bug 140837 - Placeholder in Regular Expression search is not substituted
Summary: Placeholder in Regular Expression search is not substituted
Status: RESOLVED DUPLICATE of bug 168226
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-29 15:47 UTC by Christoph Burgmer
Modified: 2010-09-05 21:26 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Burgmer 2007-01-29 15:47:44 UTC
Version:            (using KDE KDE 3.5.5)
Installed from:    Debian testing/unstable Packages
OS:                Linux

Using the replace option from the context menu in a textedit field in konqueror doesn't work for a Regular Expression search.
Replacing content with the regex "\[http://[^ ]+ ([^\]]+)\]" that is expected to match a url entry in Mediawiki's syntax (e.g. "[http://google.com Google Website]") results in inserting the string "\1" instead of doing the proper replacement (e.g. "Google Website"), though "Use placeholder" (or whatever the English option is, German version over here) is checked, and the placeholder is selected by "Insert placeholder" (or whatever... see above).
This option works in kate, so I file this report against konqueror, where this is reproduceable for me. I remember having this problem for some time now, so this is nothing that came with 3.5.5.
Comment 1 Christoph Burgmer 2008-04-25 19:40:36 UTC
The problem still persists in Konqueror for KDE 3.5.9, where as it works in KWrite.
Comment 2 Médéric Boquien 2008-05-04 22:06:17 UTC
I confirm this bug is still present in KDE SVN trunk (r803711).
Comment 3 Christoph Burgmer 2008-08-02 13:09:16 UTC
This bug is still present in KDE 4.1.
Comment 4 Christoph Burgmer 2008-08-03 17:00:51 UTC
See Bug 168226 which should be the cause for this behaviour.
Comment 5 FiNeX 2010-09-05 21:26:02 UTC

*** This bug has been marked as a duplicate of bug 168226 ***