On Sat, Jan 9, 2016 at 8:58 AM, Bram Moolenaar <[email protected]> wrote: > > Justin Keyes wrote: > >> On Fri, Jan 8, 2016 at 12:15 PM, Charles E Campbell >> <[email protected]> wrote: >> > Ben Fritz wrote: >> >> On Friday, January 8, 2016 at 2:33:04 AM UTC-6, Christian Brabandt wrote: >> >>> Having said that, I personally don't like the <restore> argument as >> >>> well. Perhaps we could use a new command modifier like >> >>> :keeppos windo ... >> >>> >> >>> That could be useful for other commands as well. >> >>> >> >> I like that idea better as well. >> >> >> > I, too, like the "keeppos" (short for keepposn?) command modifier. >> > >> > I agree that one shouldn't change the default behavior due to backwards >> > compatability considerations. My own plugins typically do a >> > save&restore position and so wouldn't be affected by whether or not that >> > default behavior changed. >> >> It would not make sense for a plugin to depend on the current behavior >> because the current behavior is unpredictable: if an error occurs the >> cursor could end up anywhere; and the contents of each buffer are >> unpredictable. >> >> So again I ask, can anyone name one reasonable, realistic scenario >> where a plugin would break by fixing this long-standing pain-point? I >> think that "backwards compatibility" has become the easy way out of >> giving extra thought to making the occasional bold decision in favor >> of usability. > > Then current behavior ends up on where the last change was done. That > can be useful. Especially for :argdo, where there very well would not > be a change at the cursor, or even in the current buffer. E.g.: > > :argdo %s/\<that_var\>/\<thatVar\>/g
I don't think any plugin depends on that. And even if there exists such a plugin, the usability benefit greatly outweighs the cost of a broken plugin which made this fragile assumption instead of using the '[ and '] registers. Good engineering weighs cost vs. benefit: the cost here is hypothetical and small, and the benefit is that a long-standing usability problem in Vim will be fixed. Justin M. Keyes -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
