Bug 175509

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; nb-NO; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7

Description of problem:
I noticed the problem when editing a Latex file, meaning it ended in .tex and was displayed in Gedit using the Latex syntax highlighting mode.  I have not tested whether the bug appears for other types of files in Gedit, but I suspect that it does.

The problem relates to text containing backslashes, e.g. the string \rightarrow, and being able to do search and replace on this.  The bug has several aspects, which are pointed out explicitly in the "steps to reproduce section" below.

Version-Release number of selected component (if applicable):
gedit-2.10.2-4

How reproducible:
Always

Steps to Reproduce:
1. Make a .tex file and let it contain the word \rightarrow at various places.
2. In Gedit, select one of the instances of \rightarrow and click the Replace button (or choose to search and replace in some of the other ways available); note that the selected text \rightarrow is already entered into the search field, which is correct behaviour.
3. Click the Search button.
4. At his point, Gedit should jump to one of the instances of \rightarrow, or perhaps remain at the already selected one. The observed behaviour is however quite different:  It claims that it could not find the selected text. This is aspect number 1 of the bug.
5. Since we have some experience with programming, formal languages and escape sequences, we guess that perhaps Gedit gives some metacharacter meaning to the backslash (which b.t.w. is no excuse), and so we add another backslash at the start of the Search field, so it now reads \\rightarrow.
6. Clicking Search now finds the various instances of \rightarrow in the file we're editing. This behaviour is aspect number 2 of the bug, since no-where in the file is the text \\rightarrow present.
7. Anyway, sensing we're on track to getting the search&replace job done, we push ahead by entering some text in the "replace with" field, e.g. "hello".
8. We click Find, it jumps to the next instance of \\rightarrow
9. We click Replace, and it should now replace the highlighted "\rightarrow" by "hello", but it doesn't!  This is aspect number 3.
10. The hightlight nevertheless jumps to the next instance of \rightarrow in the file.
11. We click Replace some more, and notice that sometimes the Replace button doesn't even depress or react (apart from getting that dotted line box around the text, indicating it received keyboard focus). After some experimenting, we see that the pattern is that if the mouse has left and re-entered the area of the button before between the two successive click, it works, but if it has stayed within the area of the button between the two successive clicks, the button doesn't work.  This is aspect number 4 of the bug.  (It might even be an entirely different bug, I don't know.)
12. In desperation, we click Replace All.  Astonishingly, it works!

Some more aspects of the bug can be displayed following another path:

13. We have a Latex file with some instances of the text "A -> B" in it, and we want to replace this ad-hoc right-pointing arrow with a proper arrow.
14. We select one of the instances of "->" and hit the Replace button in Gedit, noting that the selected text appears correctly in the the Search field.
15. We write \rightarrow in the Replace With field.
16. We hit the Search button, and notice that one of the instances of -> is correctly selected.
17. We hit the Replace button, and note that the instance of -> does in fact get replaced, though not by \rightarrow but instead by the text ightarrow, with additionally a linebreak added immediately in front of "ightarrow".  This is aspect number 5 of the bug. (Hitting the "Replace All" button behaves the same way.)

Actual Results:  (Actual results are embedded in the steps to reproduce section above.)

Expected Results:  (Expected results are embedded in the steps to reproduce section above.)

Additional info:

I also had a brief chat with someone using current rawhide (12th of december, 2005), and he at least had some of the same problems, though we didn't have time to do any thorough testing of his Gedit.