linuxmint / cinnamon

A Linux desktop featuring a traditional layout, built from modern technology and introducing brand new innovative features.
GNU General Public License v2.0
4.55k stars 742 forks source link

Xed replaces all occurrences when wrap is turned off #12255

Open Fool4UAnyway opened 4 months ago

Fool4UAnyway commented 4 months ago

Distribution

Linux Mint Cinnamon

Package version

6.0.4

Graphics hardware in use

Nothing special, NVidia 730

Frequency

Always

Bug description

When I want to replace all occurrences of a search string from a specific point, I cannot do this at once with Xed. Replace All always replaces all occurrences, even if Wrap is turned off. So I have to do this by manually clicking Replace for all occurrences from the specific point.

I would expect Xed to do this with Wrap turned off, because replacing all occurrences always can be done when Wrap is turned on. If one wants to replace all occurrences, one could also do that from the top of the document with Wrap turned off and Replace All.

I filed this as a bug, though I can understand if one thinks it is a feature request. Shall we vote?

Steps to reproduce

Enter the same line a number of times Place the cursor caret halfway the lines Press Ctrl+R to open the Replace dialog Enter a specific word to search for Enter whatever to replace it by Turn Wrap off Press Replace All

Expected behavior

All occurrences from the cursor caret will be replaced, not the ones above it

Additional information

I'm Ma Baker. Put your hands up and give me all your money! Yes, also all your money on your bank accounts. You do understand "all", don't you?!

DirkHaar commented 4 months ago

I understand all as "I said all, wfs, why didn't you replace the first line?" - no bug.

But I'm in for a feature request of a new setting "selection only" (you name it)..

Fool4UAnyway commented 4 months ago

Hello,

No, it's very simple. If search wrap is on, it can just go on. If it has to replace, it can stop after one round.

If search wrap is off, it should stop at the end of the document. If it has to replace, it will stop at the end of the document, too.

Searching or replacing in a selection is yet another option. But it requires to select first.

So if I Replace All from the second line, it definitely should not replace on the first line, if Wrap is off. It does now.

Whether that is a bug or the opposite a feature request doesn't make much of a difference to me. I would like to see it solved/added.

Kind regards,

Stefan

Op 25-06-2024 10:29 CEST schreef DirkHaar @.***>:

I understand all as "I said all, wfs, why didn't you replace the first line?" - no bug.

But I'm in for a feature request of a new setting "selection only" (you name it)..

— Reply to this email directly, view it on GitHub https://github.com/linuxmint/cinnamon/issues/12255#issuecomment-2188298397, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFSWILF4EUOJQMSO767I663ZJES6PAVCNFSM6AAAAABJYGXESKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBYGI4TQMZZG4. You are receiving this because you authored the thread.Message ID: @.***>

DirkHaar commented 4 months ago

First, there is no "find all" (besides the already implemented highlighting of all occurrences) wrap on or off. Second, if replace is realized like this, I would expect it could also be working in both directions, i.e. upwards from where the cursor currently is like find does. This might result in very ugly accidents. You see the text you'd like to replace downwards but the last search was upwards. You replace all - and that's exactly the wrong part. No problem as long as the replacing string doesn't occur elsewhere or the buffer is big enough to support a full undo. I don't want a scenario with 5000 loc and some ( at the end have been written as / due to an unlucky keyboard language switch and a backward change ends in a mess.

Fool4UAnyway commented 4 months ago

I replacing backward is a problem, it should not be implemented at all, regardless of which other option is used.

I think that does not matter. In a forward replace I always can apply other changes than in a backward replace. It really should not matter at all.

If it is a problem, don't do it.

Replace All, from the current position, forward, with Wrap off, should not be a problem either: just do it and stop at the end of the document. I cannot see how that can be a problem if the wrapped version is supported. If you are talking about undo buffers, then that goes for these replacements as well.

Op 25-06-2024 14:32 CEST schreef DirkHaar @.***>:

First, there is no "find all" (besides the already implemented highlighting of all occurrences) wrap on or off. Second, if replace is realized like this, I would expect it could also be working in both directions, i.e. upwards from where the cursor currently is like find does. This might result in very ugly accidents. You see the text you'd like to replace downwards but the last search was upwards. You replace all - and that's exactly the wrong part. No problem as long as the replacing string doesn't occur elsewhere or the buffer is big enough to support a full undo. I don't want a scenario with 5000 loc and some ( at the end have been written as / due to an unlucky keyboard language switch and a backward change ends in a mess.

— Reply to this email directly, view it on GitHub https://github.com/linuxmint/cinnamon/issues/12255#issuecomment-2188811536, or unsubscribe https://github.com/notifications/unsubscribe-auth/BFSWILE4FFHDINXQ2RAUEKDZJFPNHAVCNFSM6AAAAABJYGXESKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBYHAYTCNJTGY. You are receiving this because you authored the thread.Message ID: @.***>

cplittlfield commented 3 months ago

I can't reproduce this behavior. "Replace all" always replaces all, regardless.

What I personally would prefer is three buttons: (1) "Replace" (i.e., the current instance), (2) "Replace All", and (3) "Replace Selected". This is very clear and very user-friendly, since it is explicitly clear what the choices are and the range on which the choices will operate.

Next, could you please also add a feature that would execute the option I meant to click on, instead of the one I did click on? :smiley: