GNOME Bugzilla – Bug 328637
Search and replace: document \t, \n and \r
Last modified: 2013-11-05 14:16:49 UTC
Please describe the problem: If your text containt \t, \n, etc. strings, and then you try repleace this, GEdit repleace TABs and End of lines. Steps to reproduce: 1. Open your GEdit and create an empty document. 2. Type [like] this: function test () { echo "<html>\n"; echo "\t<head><title>Hello World</title></head>\n"; echo "\t<body>\n"; echo "\t\t<h1>Hello World</h1>\n"; echo "\t</body>\n"; echo "</html>\n"; } 3. Open the "Repleace" dialog and try to repleace \t for a White Space or \n for other string. Actual results: Expected results: Does this happen every time? Other information:
You need to escape \t and \n using \\t and \\n. Actually we should document it (I just noted the documentation is lacking this information).
Paolo: while I was checking out this issue, it occurred to me that selecting 'foo\nbar' in the text should probably escape the string before putting it in the dialog entry... (regression to 2.12?)
Paolo, yes I used \\t and \\n (By my programmer skills I suppose this), but it isn't intuitive.
pbor: yes, it seems a regression to me (but I have not checked).
*** Bug 332549 has been marked as a duplicate of this bug. ***
May I have the opinion that this is _not_a documentation bug? It would be so if the it were about this scenario: "if you want to and replace \t, write them in the dialog box as \\t, for not taking the for tabs". But the scenario is this: "if you select a text containing \t, the search and replace dialog box shows automatically the selected text with \t instead of \\t". This is a behavioral bug. The select and replace dialog should replace in the selected text \ with \\ before displaying!
A very similar bug was reported to http://bugs.debian.org/402209 Basically, the submitter agrees with Radu-Cristian, and wants this behavior to go away, or at least a means to disable it. As a personal comment, I'd like to add this feature is useful, but even having it documented makes the thing very counter-intuitive. A checkbox to disable would definitely help, but it would also help cluttering more the search dialog. Not an easy problem.
There's an Ubuntu bug about it too: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/32490
Perhaps there should be a regexp option in the search/replace window. If it is selected, search patterns are treated as regular expressions. Otherwise, they are treated as plain text.
*** Bug 527624 has been marked as a duplicate of this bug. ***
Hello, I am curious if there has been any decision regarding how to treat this bug. There have been some Ubuntu users who have been reporting this issue as a bug, and we are not sure how gnome wishes to treat this. Personally, I would like to avoid cluttering the search box, but I think many non-programmers would expect that the string they see is the string that is going to be used for matching. Maybe a message should come up below the search box if it detects a backslash to determine the desired behavior?
I would also like to note that this behavior still exists in version 2.26.3
sorry for the deluge of emails (I am new at bug triaging), but I should also note that this behavior has been reported as still existing for version 2.28.0
Another solution is to "escape" regular expressions using some predetermined string, such as "regexp". For example "regexp:(col1+)\tco.2" would search for the regular expression "(col1+)\tco.2", while "(col1+)\tco.2" would search for the literal string. This avoids cluttering the dialog box, and allows casual users to use literal strings without knowing about regular expressions, while more advanced users can be expected to know about them. I still think such an essential option would not clutter the dialog box, though.
Why use this? All functionality should be presented. Just make a corresponding checkbox in search window.
(In reply to comment #15) > Why use this? All functionality should be presented. Just make a corresponding > checkbox in search window. We don't want to add a check button for enabling or disabling \t, \n and \r. When selecting a tabulation or a newline in the buffer, and then starting a search, the selected text is inserted in the text entry, and it should Just Work™. But the current behavior is not documented. Jim, can you have a look please? So the character sequences \t, \n and \r are considered as tabulations, newlines and carriage returns, respectively. To search for a literal \t, (for example to search the \textit{} LaTeX command), the backslash needs to be escaped: \\textit{}. It is also the case for regex searches.
It's important to remember that gedit isn't focused on programmers and the highly computer-literate. Though I like the current behavior, as do most of the people in this discussion, it is unintuitive to most users and should not be the default. The choice is not (or should not be) between 'keep current behavior and document it' and 'add a checkbox to change the behavior', it is between 'remove current behavior and treat \t,\n,\r naively' and 'add a checkbox to change the behavior'. Whatever is done, the naive expectations should be met, and that means treating '\t' as plain text should be the default.
If it is not focused on programmers, why does it (last time I checked) have syntax highlighting?
(In reply to comment #1) > Actually we should document it (I just noted the documentation is lacking this > information). Documented in commit 678e1987b74d0bdcdd3b69894bbeb9b07a15bbce Please take discussions about features to the mailing list.