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 150010 - Search & Replace only selected text
Search & Replace only selected text
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: search and replace
3.2.x
Other All
: Normal enhancement
: ---
Assigned To: Gedit maintainers
Gedit maintainers
: 303960 372655 387489 396691 425409 564477 648891 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-08-13 01:10 UTC by Antonio Ognio
Modified: 2020-11-24 09:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
SubEthaEdit's Find window (31.45 KB, image/png)
2007-01-21 03:01 UTC, Matthew Paul Thomas (mpt)
Details
TextWrangler's Find & Replace dialog (66.18 KB, image/png)
2007-01-21 03:07 UTC, Matthew Paul Thomas (mpt)
Details
Apple Mail's Find window (much simpler) (25.17 KB, image/png)
2007-01-26 03:13 UTC, Matthew Paul Thomas (mpt)
Details
Eclipse Find/Replace with selection (46.08 KB, image/png)
2009-07-09 06:05 UTC, Andrew Taylor
Details
Geany rearch/replace dialog (39.38 KB, image/png)
2012-01-21 17:29 UTC, Märt Põder
Details

Description Antonio Ognio 2004-08-13 01:10:44 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:
Comment 1 Ross Golder 2005-02-05 04:56:29 UTC
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 ***
Comment 2 Paolo Borelli 2005-02-05 10:05:30 UTC
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).
Comment 3 Bhuvaneswari 2005-04-17 20:20:21 UTC
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.
Comment 4 Bhuvaneswari 2005-06-28 04:54:59 UTC
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?
Comment 5 Paolo Maggi 2005-07-25 12:50:27 UTC
For some strange reason the  Bhuvaneswari is attached bug #150010.
Comment 6 Paolo Maggi 2005-07-25 12:51:00 UTC
ops... I mean bug #303960
Comment 7 Paolo Maggi 2005-07-25 12:51:25 UTC
*** Bug 303960 has been marked as a duplicate of this bug. ***
Comment 8 Antonio Ognio 2005-09-17 18:53:51 UTC
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.
Comment 9 Paolo Borelli 2005-09-17 19:05:39 UTC
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...
Comment 10 Michaël Arnauts 2006-04-22 10:41:50 UTC
I noticed yesterday that gedit doesn't have this feature... This is something an text editor should have IMHO...
Comment 11 Ajay Gautam 2006-06-16 14:25:40 UTC
Adding a me too. This feature would be REALLY REALLY helpful
Comment 12 Paolo Borelli 2006-11-25 16:44:41 UTC
*** Bug 372655 has been marked as a duplicate of this bug. ***
Comment 13 Paolo Borelli 2006-12-29 15:00:20 UTC
*** Bug 387489 has been marked as a duplicate of this bug. ***
Comment 14 Paolo Borelli 2007-01-16 11:13:28 UTC
*** Bug 396691 has been marked as a duplicate of this bug. ***
Comment 15 Paolo Borelli 2007-01-16 11:15:18 UTC
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...
Comment 16 Matthew Paul Thomas (mpt) 2007-01-21 03:01:04 UTC
Created attachment 80793 [details]
SubEthaEdit's Find window
Comment 17 Matthew Paul Thomas (mpt) 2007-01-21 03:07:40 UTC
Created attachment 80794 [details]
TextWrangler's Find & Replace dialog
Comment 18 Matthew Paul Thomas (mpt) 2007-01-26 03:13:42 UTC
Created attachment 81245 [details]
Apple Mail's Find window (much simpler)
Comment 19 Philip Ganchev 2007-12-23 10:52:48 UTC
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.
Comment 20 Paolo Borelli 2009-01-02 14:18:15 UTC
*** Bug 425409 has been marked as a duplicate of this bug. ***
Comment 21 Paolo Borelli 2009-01-10 17:26:46 UTC
*** Bug 564477 has been marked as a duplicate of this bug. ***
Comment 22 Andrew Taylor 2009-07-09 06:00:20 UTC
/me also raises hand
Comment 23 Andrew Taylor 2009-07-09 06:05:07 UTC
Created attachment 138099 [details]
Eclipse Find/Replace with selection
Comment 24 Martin Kunev 2010-03-07 16:04:02 UTC
I miss this feature very much. It would be good to finally see it in gedit.
Comment 25 Märt Põder 2012-01-21 17:29:42 UTC
Created attachment 205767 [details]
Geany rearch/replace dialog
Comment 26 Märt Põder 2012-01-21 17:48:30 UTC
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.
Comment 27 Sébastien Wilmet 2013-07-01 11:36:29 UTC
*** Bug 648891 has been marked as a duplicate of this bug. ***
Comment 28 Daniel Loureiro 2013-09-25 02:08:08 UTC
this bug is very annoying
Comment 29 Matěj Cepl 2015-09-03 17:14:40 UTC
(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.
Comment 30 Sébastien Wilmet 2015-09-03 18:22:49 UTC
What about right click on selection -> search in selection? I.e. add an item to the context menu.
Comment 31 Fernando 2017-09-19 17:25:13 UTC
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.
Comment 32 Sébastien Wilmet 2020-11-24 09:57:10 UTC
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.