[bugreport] can't search files containing text in .tar[.gz] files, misc bugreports and wishitems

Tomasz Kłoczko kloczek at rudy.mif.pg.gda.pl
Fri Jul 13 01:34:06 UTC 2001


On Thu, 12 Jul 2001, Pavel Roskin wrote:

> Hi, Tomasz!
> 
> > > mc-4.5.35-xtermcolor.patch - Ximian-specific hack - xterm may be
> > > black-white, it's just _believed_ to support color on all systems
> > > supported by Ximian.
> >
> > Instead believig this kind things it will be better if Xiniam people will
> > change own xterm programs for negotiate not TERM=xterm but
> > TERM=xterm-color :> (??)
> 
> Please don't post messages when you are angry - rereading the message and
> fixing spell errors usually helps :-)
> 
> > "Beliving" or not TERM=xterm is color terminal is "Bad Design (TM)".
> 
> Terminal databases may be broken or out of sync

Terminal database can be fixed also witout root permission. All is
described in termcap or terminfo man page. IIRC mc in source tar ball
provides source tic and termcap file. Only one thing must be fixed: must
be added additional fix for xterm-color.

> with the actually used software.

You can use separated (own) terminal definition per apllication (simple
shell alias can handle this :).

> This cannot be avoided because software changes all the time.

But we are talking about mc :)
Mc can be fixed (?) :)

> Remote access and abundance of UNIX clones makes it a commonplace.

Ones more. Each user can override system database.

> There are many ways to fix possible problems, but the user should
> generally have a choice, dependent on how well she knows the system,
> whether she has root access, how many different programs she wants to run
> and how much time she want to spend setting the environment.
> 
> Sometimes setting a separate terminfo database and pointing $TERMINFO to
> it is the right solution if you don't have root account. But sometimes
> it's just not worth the trouble.

You see ? ... You know about this abilities :)

> Choice is important. There are many ways to make user experience better.

All can be described in few lined in doc. How to check is term description
is correct and what must be fixed if terminal desc isn't correct.
But still .. I thint 99% (or more) people uses xterm or few well known
TERM types.

> We cannot be as strict to the users as we are (or should be) to ourselves.
> 
> > Instead beliving better look into terminal database and check "colors"
> > term sequence. Current MC have also some "Bad Design (TM)" things like
> > handling in ini file section like:
> >
> > [Colors]
> > color_terminals=<list_terminal_types>
> >
> > IMHO thing like this will be better remove from MC.
> 
> I agree that it's a bad design, but for another reason. It's a bad design
> beacuse MC doesn't provide menu interface to this setting. We really need
> a menu item "Terminal Settings" instead of just "Display bits..."

Yes it is bad design because listed in default mc configuration terminal
tyles are from usualy used TERM types .. TERM which have correct
definition on (I think) more than 90% computers. Especiali xterm, linux.

> > Yes I know many Linux distribution have incorrecly builded xterm emulation
> > applications (but some not) which negotiates instead TERM=xterm-color bad
> > TERM=xterm which drives some developers to implement "Bad Design (TM)".
> > But sorru - no excuses .. all xterm, aterm, rxvt and many othes are realy
> > *color* terminals and for allow using colors in proper way in applications
> > all this xterm applications must be fixed for negotiate TERM=xterm-color :>
> 
> Try discussing it with the developers of those terminals. Just one
> objection that they may (or may not) have - many old UNIX machines don't
> know "xterm-color".

Is it problem provide in mc tar ball terminfo/terminal definition for this
people ?

> If you login from your shiny eterm to such machine you
> have to set TERM to something else, for example "xterm".

Seems You want say "eterm must be fixed" ? :-)

> It's just an example. I mean, I'm not the right person to discuss what
> terminals should do.

Look above: it is kind of few areas. One area is using any TERM as color
without lookup into term datadabase. Next area is using TERM=xterm as
color terminal and next is using some BD(TM) on terminal handling in case
when some systems haven't by default correct termilan definition. And also
next area is fixing in all Linux, BSD* distribution terminal emulation
apllications for negotiate correct TERM variable. Probably if last area
will be cleaned this discuss will be insubstantial/unpurposeable.

> The reason why I don't want "xterm" to be there is because MC without
> Ximian packaging is widely used on various UNIX systems, not because I'm
> against reasonable workarounds for problems that not every user can fix
> (wants to fix, has permission to fix, has time to fix) in other way.

Sorry but in this case IMHO it is still rather Xiniam problem .. not MC :)
Try before rebuild some xterm application and again look is it real mc
problem :)
If You want some patches for fix this kind things I can list some URLs:

http://cvs.pld.org.pl/SOURCES/Eterm-xterm-color-fixes.patch?rev=1.1
http://cvs.pld.org.pl/SOURCES/XFree86-xterm-color.patch?rev=1.1

for other like aterm, rxvt add to autoconf parameters
--with-term="xterm-color" during configure sources code.

After this again try and probably You will see not only mc will run as
color application without modify ini file or run with -c switch but also
*all other* like, lynx, w3c links, pinfo, twin and all other which
correctly uses terminal database information. Seems You don't know it is
not only MC problem but *all other* term applications which tries use
colors or not on varoise terminal types. All this problems can be and must
be fixed not each term applications by usung BD(TM) or other bad hacks but
on [x]terminal emulation applications.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek at rudy.mif.pg.gda.pl*





More information about the mc-devel mailing list