the latest multiscreen+b+c patch
Pavel Roskin
proski at gnu.org
Sun Sep 9 05:38:03 UTC 2001
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi, Walery!
On Sat, 8 Sep 2001, Walery Studennikov wrote:
> On Fri, Sep 07, 2001 at 04:58:21PM -0300, FrИdИric L. W. Meunier wrote:
> >
> > BTW, some days ago I asked Pavel privately about the
> > integration of the patch. Quoting:
My advice to you is to ignore such messages after reading the above two
lines. It would be easier for me to reply to your arguments if this
message wasn't one of them. Further moralizing if left to the exercize of
the readers.
> > Ctrl-O is the editor followed by "exit" hangs mc.
>
> IFAIK he reviewed and rewrited Ctrl-O code in editor and viewer himself.
I didn't change your idea that:
1) Ctrl-O is processed by the editor and the viewer dialogs, unlike e.g.
Ctrl-L, which works on a lower level.
2) Ctrl-O goes exactly to the same subshell from all places.
> > Encodings are not bound to termimal.
> > Filenames are neighter recoded nor filtered.
> > There is no option to filter out characters 128-159 without
> > affecting the encoding."
>
> I strongly believe that advantages of most improvements
> are more important than related minor problems and bugs.
I agree with you for the patches that have been applied. I don't have any
intention to revert them because they do add value.
It is not true in general case. If the MC editor were a better word
processor (or just more suitable for clueless users), I would worry that
somebody could lose their 8 hours of typing by pressing Ctrl-O to view the
subshell and using "exit" to leave it.
> Moreover there is no man that can write 100% bug-free (and problem-free)
> code (FIXME). And what, only this virtual man can write for MC?
I agree with you that nobody can write 100% bug-free code. But the
quality requirements for different projects may vary.
There are two big problems with MC:
1) MC has more latent bugs than other software. Whenever you touch it,
you almost invariably find something that doesn't work as intended.
2) Many of MC who don't feel any responsibility for the problems with
their code, once it is in the release. If e.g. you have a problem with
the serial driver in Linux (it's ansient!), you can find the developer who
wrote it, ask questions, and possibly fix the problem for you. If you
have a problem e.g. with samba support in mc, you cannot find the author
and ask question about the code (I actually tried it today, but samba is
just and example), let alone fixing the code.
It should not be interpreted as a reproach for the MC authors. I should
be glad that MC existed at all back in 1996 when I first tried it. MC
enabled me to learn more than I possibly could in any shell. Using more
strict coding standards could delay MC significantly and reduce its
functionality.
It's just a fact - MC is a tool for hackers, not for an average user who
started with Windows 95. Nobody is inspired to code MC to change the
world (except me, maybe). But many want to improve the tool that they are
using every day. No wonder that such occasional MC hackers don't have
time to maintain the parts of the code that they contributed.
What I'm trying to do is just to change the quality requirements, so that
the code would be easier to keep in a good shape even if the developers
who last touched the code don't have time or desire to make further
imprevements.
- --
Regards,
Pavel Roskin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE7mwBE5AxqmNHPNskRAqScAKCX7B5lmLcVEoaLcOefmzf8yh+nyACaAk5T
As3X0BbZbHczNZUw9/o8ouI=
=F6oQ
-----END PGP SIGNATURE-----
More information about the mc-devel
mailing list