After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 328637 - Search and replace: document \t, \n and \r
Search and replace: document \t, \n and \r
Status: RESOLVED FIXED
Product: gedit
Classification: Applications
Component: docs
3.11.x
Other All
: Normal enhancement
: ---
Assigned To: Maintainers of Gnome user documentation
Gedit maintainers
: 332549 527624 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-01-25 19:58 UTC by Mario Fuentes
Modified: 2013-11-05 14:16 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Mario Fuentes 2006-01-25 19:58: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:
Comment 1 Paolo Maggi 2006-01-27 08:50:56 UTC
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).

Comment 2 Paolo Borelli 2006-01-27 11:03:15 UTC
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?)
Comment 3 Mario Fuentes 2006-01-27 15:05:04 UTC
Paolo, yes I used \\t and \\n (By my programmer skills I suppose this), but it isn't intuitive.
Comment 4 Paolo Maggi 2006-02-22 16:36:18 UTC
pbor: yes, it seems a regression to me (but I have not checked).
Comment 5 Paolo Borelli 2006-02-25 15:51:16 UTC
*** Bug 332549 has been marked as a duplicate of this bug. ***
Comment 6 Radu-Cristian Fotescu 2006-07-04 19:53:41 UTC
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!
Comment 7 Josselin Mouette 2006-12-08 22:49:48 UTC
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.
Comment 8 Pedro Villavicencio 2007-09-04 13:13:47 UTC
There's an Ubuntu bug about it too: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/32490
Comment 9 Philip Ganchev 2007-12-23 00:36:48 UTC
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.
Comment 10 Ignacio Casal Quinteiro (nacho) 2009-08-22 18:06:14 UTC
*** Bug 527624 has been marked as a duplicate of this bug. ***
Comment 11 Ben Root 2009-11-16 17:55:44 UTC
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?
Comment 12 Ben Root 2009-11-16 18:06:55 UTC
I would also like to note that this behavior still exists in version 2.26.3
Comment 13 Ben Root 2009-11-16 18:19:06 UTC
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
Comment 14 Philip Ganchev 2009-11-17 00:53:06 UTC
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.
Comment 15 Urmas 2010-05-18 01:32:10 UTC
Why use this? All functionality should be presented. Just make a corresponding checkbox in search window.
Comment 16 Sébastien Wilmet 2013-08-31 16:48:33 UTC
(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.
Comment 17 Jacob 2013-11-05 02:25:11 UTC
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.
Comment 18 Urmas 2013-11-05 02:44:58 UTC
If it is not focused on programmers, why does it (last time I checked) have syntax highlighting?
Comment 19 Urmas 2013-11-05 02:52:01 UTC
If it is not focused on programmers, why does it (last time I checked) have syntax highlighting?
Comment 20 Kat 2013-11-05 14:16:49 UTC
(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.