GNOME Bugzilla – Bug 150010
Search & Replace only selected text
Last modified: 2020-11-24 09:57:10 UTC
Description of Problem: The Search & Replace dialog does not have an option to search and replace only inside the selected portion of text. This feature is really useful in general but specially if you're programming and using a chunk of code as a "template" for some other code. Actual Results: When you select text and replace text all ocurrences get replaced not only selected text. Expected Results: I'd expect selected text only to be searched and replaced. I guess this should have a checkbox on its own title something like "Search current selection only" which should be checked by default if you open the Replace Dialog when you have some portion of text selected. This is a very common feature in many other text editors. Additional Information:
This is probably a duplicate of bug #100821 http://bugzilla.gnome.org/show_bug.cgi?id=100821. *** This bug has been marked as a duplicate of 100821 ***
actually I don't think this is a dup of 100821. That bug deals with the general UI of the find dialog, while this bug asks for a specific enanchement: to restrict the search and replace to the selected text (if present).
I have added a checkbox in the dialog window and also, after that I made the checkbox checked by default if i select a particular text. After that, find operation is not working. I am trying to do it by make the find as sensitive as soon as we select particular text.
Now, when i select some portion of text in a paragraph, then new checkbox i have added "current selection only" is checked default. Then, when i press find button, the first matching word get searched and the cursor doea not move to the next matching word in the selection. any ideas?
For some strange reason the Bhuvaneswari is attached bug #150010.
ops... I mean bug #303960
*** Bug 303960 has been marked as a duplicate of this bug. ***
Maybe it helps if some general strategy is outlined here as a comment by some of the mantainers. e.g. what to do, where to look for, stuff like that.
well, from an implementation standpoint it should be enough to set the iter at which the search starts at the beginning of the selction and stop searching at the end of the selection. However what needs to be figured out is the UI for this: I don't want to grow the number of toggles in the search prefernces... in fact I want to reduce them, given the fact that we are getting rid of the dialog and we need to fit the search ui in a search bar or a search panel. On the other hand I'm not sure if just defaulting to always limiting the search to the selected text when the selection is bigger than X characers would end up beeing confusing...
I noticed yesterday that gedit doesn't have this feature... This is something an text editor should have IMHO...
Adding a me too. This feature would be REALLY REALLY helpful
*** Bug 372655 has been marked as a duplicate of this bug. ***
*** Bug 387489 has been marked as a duplicate of this bug. ***
*** Bug 396691 has been marked as a duplicate of this bug. ***
Pasting the comments I made on Bug 396691 since they are useful: This comes up from time to time and I think it's a valid request, but there are things that need to be worked out both in the UI that in the implementation: UI: * Adding checkboxes/options to the find dialog makes me a bit unconfortable, especially since there are other valid requests of options to be added there * should this just be on Replace? Can you post screenies of the SubEthaEdit and TextWrangler dialogs? Implementation: while searching in the selection should be easy enough (just grab the start and end iter and make sure to not search further), there is a problem with the display of the selection: given how X works there is always just one available selection: this means that has soon as something is selected in the search entry in the dialog (autocompletion included) the selection in the textview vanishes, making this option way less useable. Not sure how we can work around this...
Created attachment 80793 [details] SubEthaEdit's Find window
Created attachment 80794 [details] TextWrangler's Find & Replace dialog
Created attachment 81245 [details] Apple Mail's Find window (much simpler)
About the UI questions raised in comment #15: The search and search/replace dialog or pane should have a "From selection only" check box The "Wrap around" check box should be removed, and searching and replacing should stop at the end of the text with a beep and status message, and be continued from the start of the text after the appropriate button is hit again The "Search backwards" check box should be replaced by a Previous button and the Find button with a Next button. This UI is less modal and clear.
*** Bug 425409 has been marked as a duplicate of this bug. ***
*** Bug 564477 has been marked as a duplicate of this bug. ***
/me also raises hand
Created attachment 138099 [details] Eclipse Find/Replace with selection
I miss this feature very much. It would be good to finally see it in gedit.
Created attachment 205767 [details] Geany rearch/replace dialog
I just want to add that Geany has nice solution from the GTK+ implementation point of view, which also (accidentally?) coincides with the meaning of the option. Besides the fact, that In Selection is really needed only for Replace function, it's only needed for automatic replacement (à la Replace All). For manual replacement we can just point cursor to a place in file and then replace forwards from that point, pressing Replace/Next every time and supervising the process. No taking into account of a selection is needed. So probably in addition to Replace All button there should be Replace In Selection button and not a checkbox or anything like that. If we think that we are lacking the space for an extra button, we could maybe offer this advanced option in some more advanced way, for example, while holding down Shift (or Alt or Control), the Replace All becomes Replace In Selection. This practise is used in Gnome's session menu anyway, so it's not too awkward. And I add that this option is really essential if you do some dirtier programming, where you don't want to (temporally in a testing phase etc) present everything as functions and want to replace variables conveniently in specific part of the source code. This actually happens really often. I somehow believe that not implementing this option could have some educational value: People would define more functions and write cleaner code... But I'm not sure if it's worth it.
*** Bug 648891 has been marked as a duplicate of this bug. ***
this bug is very annoying
(In reply to Paolo Borelli from comment #9) > On the other hand I'm not sure if just defaulting to always > limiting the search to the selected text when the selection is > bigger than X characers would end up beeing confusing... I would actually vote exactly for this. Perhaps for the first time user gets confused, but otherwise it seems to me that this it the most obvious UI.
What about right click on selection -> search in selection? I.e. add an item to the context menu.
I really miss this functionality. I'm afraid I don't have coding skills to help but wouldn't it be possible to add tree functionality, maybe as a plugin, from a more up-to-date project like Latexila? Latexila's search functionality is in a vala file, and gedit admits vala plugins.
Mass-closing of all gedit bugzilla tickets. Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing: 2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3 By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements. We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.