Re: Upcoming X.org release and splitting packages

[Thomas Dickey <dickey at his dot com>]

On Fri, 19 Mar 2004, [ISO-8859-1] Frédéric L. W. Meunier wrote:

> On Fri, 19 Mar 2004, Harold L Hunt II wrote:
>
> > Frédéric L. W. Meunier wrote:
> >
> > > --with-terminal-type=xterm-xfree86 was just so I wouldn't get
> > > it set to xterm by default (lynx etc are black and white with
> > > it).
> >
> > I'm not sure this would be a good idea to change the default if we were
> > not doing this before anyway.  Then again, I would rather defer
> > judgement on this one to someone with more knowledge on this subject.
>
> Question to Thomas: Why make xterm the default if all (?)
> ncurses applications run in black and white with it ? Sure, you
> can change .Xdefaults etc, but go figure.

That's one of those situations where any of the solutions are not good
for everyone.  If you're using xterm for one machine - sure, that's good.
But if you ssh/rsh/telnet/etc to another machine where that $TERM value
doesn't correspond to anything in the remote machine's termcap/terminfo,
then it doesn't work well.  Two problems may occur there: the
ssh/rsh/telnet/etc client may check $TERM and refuse to complete the
connection (this applies to some telnet daemons apparently).  Even
when the connection is completed, many users don't cope well with
the fact that their $TERM isn't useful.

The other solution as you note - setting $TERM to "xterm" works, but
color usually isn't available.  Setting it to one that does color has
the disadvantage that there's always a terminal emulator (or two, etc)
that doesn't match the terminfo.

I compile-in the correct $TERM value for each client for which I have
source (and have little use for the ones that hardcode it, anyway except
for testing).  On remote machines I've updated the terminfo entries so
they work.  But that's too much work for the typical user.  The solution
you choose really depends on the type of questions you want to answer
about what's broken...

>
> > > --disable-tek4014 --disable-vt52 seems to be recommend because
> > > it adds bloat and only a few people use it.
> >
> > Might not be a bad idea, but the .exe is only 233 KiB at the moment.  It
> > isn't exactly bloated.  :)
>
> According to INSTALL:
>
> "This reduces the executable size by 17% (checked 1999/3/13)."
>
> Thomas should update it. I didn't notice 1/4 of it in the
> size.

That probably depends on the platform.  Some executable formats are
not really byte-granular, for instance.  But I'll check on one of my
Linux boxes to see if a dependency has crept in.  17% would be about
20kb.

-- 
Thomas E. Dickey
http://invisible-island.net
ftp://invisible-island.net