Re: [ANN] mc^2

[Paul Sokolovsky <pmiscml gmail com>]

Hello,

On Sun, 10 May 2015 14:51:17 +0200
"Yury V. Zaytsev" <yury 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:pmiscml gmail com