Re: Proposal for simplification

[Egmont Koblinger <egmont uhulinux hu>]

> Time will show.  I think S-Lang is better maintained than ncurses, so
> we'll submit patches if needed.

I have no experience with slang, but I do have with ncurses. Once I had a
minor problem (with the build infrastructure IIRC, not with the library
itself), I reported to the author and he correctly replied and fixed it
within a few days. There are patches released to the current version every
week, so it's easy to stay up with development versions.

For slang I don't see such patches or open cvs server or similar, so I can
only download tarballs. Slang doesn't have releases too often, either. It
seems to me that nearly three years elapsed between 1.4.0 and 1.4.9, which
was followed by 2.0 in more than two years. I see that 2.0.4 followed 2.0
very shortly, but that is most likely (I guess) because of some new bugs
introduced by larger code-changes and Unicode support, and I don't really
think it means that slang will have a faster development cycle from now on.

So based on these I don't see why slang is better than ncurses.

> As I understand, there is a UTF-8 patch for S-Lang but not for ncurses.
> You can ask the author of the patch about the motivation.  I assume that
> it's just easier to support one library.

ncurses has Unicode support (the installed library is called ncursesw,
./configure needs an --enable-widec). The oldest version I found now, namely
ncurses 4.2, which was released 7 and a half years ago, already has this
configure option so Unicode support is not new at all in ncurses.

For some reason, the default ncurses library does not support Unicode, so
distributions usually install a non-unicode aware version as libncurses.so,
as well as a unicode-aware version as libncursesw.so. I guess there are some
compatibility issues why the wide version cannot fully replace the old one.


A huge difference between slang and ncurses is, if I read the ncurses
manpages and slang2's news correctly, is that ncurses functions use wchar's
(that is, UCS-4), while Slang functions use UTF-8. This, I guess, would make
thinks even more complicated if mc with unicode support would like to
maintain both ncursesw and slang support.


Basically I absolutely agree with Pavel's simplification proposal, and
actually I never understood why mc was a utility (and actually the only one
I know) that supported both ncurses and slang. More compilicated code, more
developer resources spent for nothing, different bugs in the two cases,
tester people devided into two categories and all hunting for bugs only in
mc's usage of one of these two libraries etc...

I (as a Linux distribution maintainer as well as developer of some really
small pieces of software) believe which library to use is not a decision
users or distribution maintainers should make. It is a decision that should
be made by mc's developers. Users should accept it and install the library
mc developers say mc requires.


Personally I vote for ncurses because of the following reasons:

- As descussed above, I think ncurses is maintainer better.

- Ncurses is much more wide-spread, much more applications use it, hence
it's most likely for bugs to arise and get caught and fixed by developers of
other applications. So due to its wider use, I guess it's much likely to
have less bugs as well as better compatibility with various systems.

- Also due to its wide-spread use, ncurses is most likely to be already
present in many small (size-limited, e.g. pendrive) rescue systems, since
other handful utilities (cfdisk, vim ...) also need it. However, I don't
think such systems have any applications (except mc) that use slang.

- Ncurses has support to hard-code the terminal description of some
terminals to its libraries, hence the terminfo database is not needed at all
to operate in some very common terminals (linux, vt100, xterm...) if they're
compiled into ncurses. Slang doesn't have this option as far as I know, so
it relies on the terminfo database (which is actually shipped by ncurses).
>From a packager's point of view, where we have ncurses with built-in support
for the terminal types I mentioned above, on a rescue system mc w/ slang
introduces another big dependency: the big terminfo database. Okay, I can
remove all files from this package except three of them, but there are cases
when it's much easier to install either a whole package or nothing at all.


However, the most important point should be which library the developers are
more familiar with and which library is more likely to make implementing Unicode
support easier.



Also I agree with Pavel's proposal concerning gettext and other stuff. I
could never understand people who say "I have this extremely old system with
out-of-date faulty libraries lacking lots of important and cool features, I
cannot (or will not) upgrade it, but I need the latest mc, 4.6.1 is not good
enough for me when 4.6.2 is already out there". Programmers of libraries
invent new features for people to use them, and not for people to just stare
at them and wish "oh, if only I could use them... but I cannot because of
compatibility issues with ancient systems".




-- 
Egmont