I don't think we need backwards compatibility, it isn't a big ask for people to change their configs - especially now they can use if/run-shell synchronously to do it and ignore the error. But it isn't something we want to ask unnecessarily, just to fix naming nit.
On Tue, Mar 26, 2013 at 03:58:40PM +0000, Thomas Adam wrote: > Hi, > > On Tue, Mar 26, 2013 at 04:08:12PM +0100, Marcel Partap wrote: > > > On Tuesday evening -- I'm planning to release tmux 1.8. > > > Any questions, please let me know. > > Yes, would you be so kind and delay the release a couple of hours. Only > > just took notice of it and imho some of the patches I sent in a year ago > > As Nicholas has mentioned, this isn't going to happen now, since I'm about > to cut a release for 1.8. The code that's going out the door with version > 1.8 has had a settling-in period of some time now, and there's no perceived > breakages which we know about which makes 1.8 unattainable. > > But adding in your changes now -- even by delaying 1.8 by a few days -- > simply is not an option. We would need much more time to ensure new code > isn't going to introduce bugs, and I don't want that. I don't want to have > to release 1.9 because of something which could have waited. > > So no. You're going to have to wait. > > As to the subject of your patches though (and thanks for hijacking this > thread, BTW): > > > and then again couple of months back should really really be in the next > > point release, namely: > > - renaming mode-mouse to mouse-copy-mode (multiple incidents of > > confusion because of the too-general name) > > Why is the name changing anyway? Point me at a thread I can go back and > read again, by all means. To do this "properly", we'd have to maintain a > separate deprecation table to perform old->new command-name lookups to > ensure people's configurations do not break. This adds code-bloat for no > real reason, and whilst I can understand there's a few naming-nits with some > commands, we're by-and-large stuck with what we have. We are making more of > an effort with new commands, to either add additional options to existing > commands (c.f. "-r" to "move-window"), or not require them at all, and mark > the behaviour as default. > > > - pane-active-border-mark option to indicate current pane (as an option > > to the horrible half-line indicator that was committed 12 days ago) > > Opinions notwithstanding, it seems as though this is just another variant on > this half-border solution. I don't care either way, but the half-border > solution has been chosen for now. > > > - mouse wheel scrolling emulation (yes, it is ready since long) > > - fix of unwanted side effects of new osdep_get_cwd() behaviour > > What is this new osdep_get_cwd() change and how has it affectef your > scrolling wheel patch? > > -- Thomas Adam > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > _______________________________________________ > tmux-users mailing list > tmux-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tmux-users ------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d _______________________________________________ tmux-users mailing list tmux-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tmux-users
