Hello, On Sun, 10 May 2015 14:51:17 +0200 "Yury V. Zaytsev" <y...@shurup.com> wrote:
[] > > That's why it's important that *maintainers* take formal criteria of > > "completeness" and "lack of random gaps in functionality". And > > higher-level criteria, like mc being an open-source project, which > > naturally should be expected to be used for, and appreciate needs of > > open-source software. And OSS is very diversified, including > > line-endings. I'm, as an open-source developer, deal with at least a > > dozen new projects each month, and regularly hit cases when mc > > instead of helping, complicates me contributing to such software > > (by not allowing to edit files comfortably). > > > > So, yes, you personally may not care about it, but this issue - of > > diversity of real-world files - objectively exists. > > Your argument is zum Besten der Armen; everybody knows that the > situation with the maintenance of mc is suboptimal to say the least. > > However, it's all in your hands: > > 1) You can maintain your own patchset on top of mc, like I did for > years, and it's not as difficult as it might seem That's kinda what I do, but I find myself behind it all the time (mc is basic background tool for me, I don't dream about maintaining my won fork of grep). And when I spawn a new EC2/vagrant/docker box, I want to use it right away, not clone and build source. I also want to grin at the sight of vim/emacs/idea/whatever and say that solution of my community is better (so far I would lie). > > 2) You can keep pesting the current maintainers and hope for the best > (like Egmont does, and more often than not, he is successful at that, > so maybe if you aren't, then there is something you could have done > differently, if success is your ultimate goal in the first place) My ultimate goal is mc's success, not my patch's. I'd be happy if someone reimplemented that patch with "complete binary safety". That's certainly what I tried first, but found that with current editor codebase it will be quite cumbersome (entails lots of bugs), and will make the codebase even more cumbersome. As you guessed, my next step was not to rewrite editor, but to look for realistic and sustainable way to implement it, and I keep "pushing" it, because other folks actually contributed to it to make it better, so it would be nice to lead somewhere. [] > The possibilities are endless. Instead, you keep complaining on the > mailing list that somebody who submitted something you didn't like got > the attention you think should have been rather given to you. That's > your choice. Good luck! I'm discussing it. And attention not to me, but to issues (I just have one to be really concerned about, all other were already resolved.) -- Best regards, Paul mailto:pmis...@gmail.com _______________________________________________ mc-devel mailing list https://mail.gnome.org/mailman/listinfo/mc-devel