GNOME Bugzilla – Bug 443956
Search: \n not taken literally
Last modified: 2007-08-25 08:22:15 UTC
If I create a document with printf ("Two\nLines"); and then search for "Two\nLines" then it is not matched. However, this search *does* match Two Lines Searching for "Two\\nLines" does match the original text. I think this is the wrong behaviour, since the search dialog doesn't provide any indication that it's interpreting these as special characters. It might be considered intuitive for programmers but it isn't for users in general. If it is decided that the search behaviour is to keep this quirk, please note that selecting some text with a "\n" in and then opening the search dialog writes it into the dialog in its unescaped form, such that it does not match the original selection. This should at least be escaped when the search dialog is opened.
I've observed this in gedit 2.18.1, Ubuntu Feisty. Personally I like the ability to search for \n, but he's right in two points: 1) It's not obvious that it does this. Nowhere does the Find dialog contain a note expressing this behaviour or having an option to switch it off. and 2) If backslashes are going to be treated as escape characters, then literal backslash characters in the highlighted text should be escaped before inserted into the Find dialog textbox. Otherwise the find dialog isn't even able to locate the highlighted text that it was instantiated with, let alone other matches in the document.
This is not a bug ! It's just question to have an more
This is not a bug ! The question is to have an UI more configurable or not for have more friendly UI. Do you think that is useful to add an check box for use or not the backslashing convention or not ?
part (2) of what Miachel said *is* a bug: > 2) If backslashes are going to be treated as escape characters, then literal > backslash characters in the highlighted text should be escaped before inserted > into the Find dialog textbox. Otherwise the find dialog isn't even able to > locate the highlighted text that it was instantiated with, let alone other > matches in the document. Unfortunately when I took a quick look at it I couldn't find the problem since we do escape the slashes before inserting the selected text in the dialog...
With gedit 2.18.1, if I have text alice \north bob \south Then I can select and search bob's name correctly but not alice's. Paolo: I guess you're working with svn trunk, might this have changed?
John, I am working with trunk, but should not make any difference. In your example what matters is that we only interprete \n (new line) and \t (tab). \s is taken literally.
This bug is the same as the bug number #300977. It's just explain with another characters, but the base problem is the same ! You must know witch characters must have a backslash for be find.
well, it's not 100% the same thing of #300977. Anyway we looked into it and fixed the issue that selecting a literal \n in the text and pressing Find should put \\n in the search entry, which is what this bug is about.