search

radian-software / ctrlf

⌨️ Emacs finally learns how to ctrl+F.
MIT License
347 stars 22 forks source link

Find-and-replace interface #21

Open AmaiKinono opened 4 years ago

AmaiKinono commented 4 years ago

I think we need replacing functionalities to make this package complete. Do you already have some thoughts or design on this?

raxod502 commented 4 years ago

No, aside from that it should be a similar interface to the one used in other text editors, but it does sound reasonable to add "replace" to "find".

dylanjm commented 4 years ago

I really like the anzu approaches find and replace by interactively highlighting the regexp as you type it in, and then shows an inline replacement after matching on the regexp.

raxod502 commented 4 years ago

Yeah, that's a nice interface. See also visual-regexp which implements a similar idea although not quite as attractively.

AmaiKinono commented 4 years ago

I'll write down a somewhat "corner" case here.

The one thing that pushed me to switch from ivy+swiper to selectrum+CTRLF is I found sometimes I need to find and replace ^$ (blank lines). There's bugs in swiper that make this don't work. Once it's fixed (in an ad-hoc way) and then there's regression that breaks this again.

I hope this works. Now CTRLF doesn't deal with zero-width matches, which make sense. But when it can do replace, I hope it works when I want to do this. Of course I can switch to isearch or query-replace-regexp to do this, but If the user already sticks to CTRLF, it would be a bonus if they can do all kinds of search/replace in it.

raxod502 commented 4 years ago

I didn't think of zero-length matches that only match at certain points of the buffer. I think that they're a reasonable thing to want to be supported, but somebody would have to do the work to make it so the code for them isn't a disgusting mess. It's also an open question how to indicate that a zero-length match is selected, since there are no characters to highlight.

raxod502 commented 4 years ago

Zero-length matches are now implemented, so all the machinery exists to support replacement as well. I do not plan to work on this anytime soon, however.

terlar commented 2 months ago

I just found this alternative package: https://github.com/szermatt/visual-replace

I wonder if replicating some of this logic or creating some integration point makes sense.

I'm currently evaluating this as a replacement for visual-regexp. But of course would be nice to have one package less.