On Sun, Jan 10, 2016 at 1:21 PM, 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. > > You misunderstand. I want that command to end at the last change, not > at whereever I happened to start it from.
Fair point. I retract my objection then. 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.
