:%s/test/newtext/ corrupts filenames in editmode when path/filename include "test"... about ctrlsf.vim HOT 5 CLOSED

It's not difficult to fix this 'bug' because CtrlSF explicitly checks if a file's name is changed and raises an error if it is, remove this check can let you save file properly.

But it will cause a problem when you want to undo that change by u, as the original filename is modified and CtrlSF can't figure out what is the correct path to save.

I also don't think saving without complain even if filename is changed is a meaningful behavior, it seems more likely a bug.

from ctrlsf.vim.

Well here is the use case:

Open a large project and CtrlSF a function name that I want to change. CtrlSF loads the buffer with all matches. The function name matches a few (or more) paths/filename parts in those matches. I want to run a standard sub (:%s///g) on that functionname or maybe just the start of the word and change it and save. or undo and resave.

As it currently stands, in CtrlSF the fact that the sub changes the text in the filename or pathname throws the error and no changes are made on :w. in vim-ags edit mode the filenames/paths are changed via the sub but the files are still written to properly and undo still works properly (this is very meaningful). there is a mismatch between the filenames shown in the buffer and the filenames stored on disk (with it doing the right thing and ignoring the subed filenames in buffer). I am not sure how it does this, I assume it has another version of the buffer stored and just pulls the ranges between the filename lines for action?

from ctrlsf.vim.

If you need this feature so bad, you can change one line to make it work.

1. Open CtrlSF's source file ~/.vim/bundle/ctrlsf.vim/autoload/ctrlsf/edit.vim. (suppose you are using Vundle)
2. Look at lines between 11 and 12. (here)
3. Remove the a:orig.filename !=# a:modi.filename || part.
4. Save and restart vim, now you can save files even if their name is changed.

But you still have not convinced me that this is a meaningful feature so I won't add it to master. I think a more specific match pattern or substitution with confirm :%s///cg makes more sense.

from ctrlsf.vim.

I missed this response, I went back to ags to get the work done. Thanks for the info, I am not sure what you believe the "feature" is here that is worth protecting. As I look at that code you dont actually seem to use a:modi.filename for anything at all except to throw an error in the case the name has been changed in the window. It seems like the happy case there is an error?

It is of course completely up to you, but I would think either ignoring the file name lines (which are just informational and not used) is a much better user experience vs forcing the user to void modifying informational lines tat seem to be checked for no reason. Another option which would seem to be another type of advantage is to actually use the modified filename lines to rename a file. All of that said, i just dont get why the filename lines are checked at this point (its the only place I see the modified name used anywhere in the code).

from ctrlsf.vim.

For your question, a:modi.filename will replace a:orig.filename later and be used as filename for your further change, that is why undo is breaking after your saving.

I don't like feature you request is just I don't like the idea that 'what a line means is not what it shows', I think it breaks consistency. But I agree that it's useful in some case, maybe I will change my mind later. Before that, I will close this issue.

from ctrlsf.vim.