Re: test results mc.hlp.it 156+ M

[Andrew V. Samoilov]

Hello!

Pavel Roskin wrote:

This is used to print the table of contents.  If cnode-heading_level is
negative, some stupid versions of fprintf may try to print an infinite
number of spaces.


Negative width means left justified output. BTW, why do you complaim 
against ?: operator?
--
Regards,
Andrew V. Samoilov



___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: removing the obsolete gnome (gmc) support?

[Pavel Roskin]

Hello, Arpi!

 While searching for the current MC homepage/download/cvs etc
 (btw where is it? i still not find it, the http://mc.blackdown.org/mc/
 url points to some java4linux crap!) i've found an interesting mail:

You must have lived under rock for years.  Maybe you are Kevin Mitnick?
:-)

Go to www.google.com and enter Midnight Commander homepage.  Click I'm
feeling lucky.  The answer will be prominently displayed in your browser.

 I thought i'm the only not using/liking gmc and wanted to remove gmc
 from the code years ago.

You are not alone.

 Yes, I was who started AMC 3 years ago, to
 make a cleaner, stable mc version targeted for console only.
 (ftp://thot.banki.hu/esp-team/linux/mc-4.1.35-A12pre1[.txt|.tar.gz])

I know about it.  I always wanted to take your FXP support in VFS, but I
never had time for that.

 Now, that i'm about leaving the MPlayer project, I plan to work again
 on AMC. But I didn't decided yet if i'll continue patching the old 4.1.x
 series or fork the 4.5.x code and remove the crap (mainly gmc), or maybe
 start a new project from scratch and maybe porting some parts from 4.1.x
 or 4.5.x.

I'm glad to welcome you in our team.  The existence of AMC was an
important argument for removing the GNOME frontend.  Your expertize will
be very useful.  It would be great if you help us merge changes made in
AMC.

 So, the question: are you planning to remove gnome gmc hack in the
 near future from 4.5.x tree?

Why do you care about 4.5.x tree?  4.6.x tree won't have it from the
beginning.

Please test 4.6.0-pre3 or the CVS version.  I hope to release 4.6.0 very
soon.  There are no problems, but I want to make some testing on
64-bit systems and wait for bugreports about 4.6.0-pre3.

-- 
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: removing the obsolete gnome (gmc) support?

[Arpi]

Hi,

  While searching for the current MC homepage/download/cvs etc
  (btw where is it? i still not find it, the http://mc.blackdown.org/mc/
  url points to some java4linux crap!) i've found an interesting mail:
 
 You must have lived under rock for years.

sure. i was busy 24/7 with mplayer development and with my job in the rest.
(and still using amc 4.1.35-a12pre (yes a12 was never finished) on all my hosts)

i didn't even know about being a big difference between 4.5.x and 4.6.
i've seen 4.6.0rcX announce recently but i thouht it's just 4.5.xx (xx == too
big number) renamed :)

 Maybe you are Kevin Mitnick? :-)
not (yet) :)

 Go to www.google.com and enter Midnight Commander homepage.  Click I'm
 feeling lucky.  The answer will be prominently displayed in your browser.

Eh. I've tried midnight commander download patch fix :)

  I thought i'm the only not using/liking gmc and wanted to remove gmc
  from the code years ago.
 
 You are not alone.

Nice to hear!

  Yes, I was who started AMC 3 years ago, to
  make a cleaner, stable mc version targeted for console only.
  (ftp://thot.banki.hu/esp-team/linux/mc-4.1.35-A12pre1[.txt|.tar.gz])
 
 I know about it.  I always wanted to take your FXP support in VFS, but I
 never had time for that.

I've never really used the FXP thing (added for request by friends) but i'll
try to port it now.

  Now, that i'm about leaving the MPlayer project, I plan to work again
  on AMC. But I didn't decided yet if i'll continue patching the old 4.1.x
  series or fork the 4.5.x code and remove the crap (mainly gmc), or maybe
  start a new project from scratch and maybe porting some parts from 4.1.x
  or 4.5.x.
 
 I'm glad to welcome you in our team.  The existence of AMC was an
 important argument for removing the GNOME frontend.  Your expertize will

Eh. I'm really surprised :)

 be very useful.  It would be great if you help us merge changes made in
 AMC.

I'll try to do my best.

  So, the question: are you planning to remove gnome gmc hack in the
  near future from 4.5.x tree?
 
 Why do you care about 4.5.x tree?  4.6.x tree won't have it from the
 beginning.
 
 Please test 4.6.0-pre3 or the CVS version.  I hope to release 4.6.0 very

I'm downloading (cvs co mc) CVS right now.
I think it will take some time to re-learn the mc code structure, i
haven't seen it since years...

I thought that 4.5.xx is the current version, and its bugs are not fixed 
there since years because no one develops mc nowdays or they're all working
on the gmc part :)
It is the reason why i planned to fork or start a new project from scratch.

It's amazing to see that it's still under development and the goal is again
making a stable bugfree console tool instead of yet another winblows-exploder
or win-commander clone for gnome/X.


A'rpi / Astral  ESP-team

--
Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: removing the obsolete gnome (gmc) support?

[Arpi]

Hi,

[ please do not cc:, i'm subscribed on mc-devel ]

   I'm glad to welcome you in our team.  The existence of AMC was an
   important argument for removing the GNOME frontend.  Your expertize will
 
  Eh. I'm really surprised :)
 
 It was a clear indicator that something wrong was going on with the
 project.  Another reason was the appearance of gmc alternatives, such as
 Nautilus and Gentoo.

I've never understood why was it good to hack mc to hell to get the gmc
thing, especially after trying gmc. Writing such thing from scratch must
have been simpler...

 As for the text edition, I wanted to release 4.6.0 much earlier, but it
 was a heavy race against bugs.  As soon as somebody was fixed, another
 critical bug was reported.  Sometimes it seemed that I'm losing the race,
 but finally I could concentrate and deal with the remaining issues.

:)
I've done exactly the same with mplayer 0.90. We're delaying teh release
since 2002 april because of serious bugs keep appearing, and now after
few months of heavy bug-hunting and feature-freezee it's finally stable.
We'll release 0.90 final in a few days.
I've decided that before I start mplayer generation 2 (new core etc,
instead of hacking 0.90 more) I will tidy my desktop, ie fix the bugs
and add missing features i'm fighting every day in development tools,
especially in mc and mailer3. So I'm here :)

 Of course, a lot of stuff was moved to the TODO file.  We also have a bug

I've read it. I'll come up soon with my own TODO, probably a stripped down
version of yours, with things i'm interested to work on.

 tracking system and a patch manager on savannah.gnu.org.  There are still
 serious problems in the code, such as an unsafe rewriting of the config
 files without locking and doing backups.

ah, the config system...
i usually run several instances of mcedit on tty1..tty9, editing various
source files (yes i know i should use some multifile-capable IDE but i
like mcedit) and if i change something (indenting, tab size etc) in one
mcedit then it will be saved and new mcedit instances will have that values
set as default. It's really annoying... Imho there should be something like
'Ok for this instance' and 'Save as default setting' choices at the
preferences/settings panels.

 There is a lot of work to be done.  4.6.0 is just the beginning.

Sure. I've find this in TODO:

* Internal terminal - no more console saving.

Imho it's one of the most important issues/problems of mc.
I'm use dto norton/volkov comamnder under dos, and far under win32,
they behave the same way when panels are visible and when they are hidden.
In opposite, mc is tricky: if panels are enabled, then you're in mc's line
editor, with mc hotkeys working. When panels disabled: you're in raw shell,
no mc keys or things available. Even the command history in panels on/off
mode is independent...

The question is that how to solve this duality. Or is it planend at all?
The first thing came in to my mind is the approach used by Volkov commander:
You're always in the commandline editor, even if panels disabled.
If you enter sth and press enter, it execute sthat command in a new shell
(command.com /c yourcommand). If you press alt+enter, it executes it in
parent shell by calling the int 4Bh syscall (something like the exec*()
posix calls, running the commands in the current shell). This is very
important if you want to execute shell setting commands, like setting
environment variables, set up alias-es etc.
Anyway i'm not sure it's doable, but i think it is.

Also, I like your idea of builtin terminal emulation.
Btw, it would be nice if it could run commands in new tty. Some utils, for
example fte, ht or biew supports raw keys (to utilize shift+control+Fx
etc combinations) but they don't work when executed from mc. It's boring to
exit mc whenever i want to run biew on a file...
It should be optional, and is useful only for local console use.
(i opposite, i like that dosemu doesn't get raw access when run in mc,
so i can copypaste with gpm from/to dos apps :))

  It is the reason why i planned to fork or start a new project from
  scratch.
 
 Please avoid forking by all means.  If you have problems with the current
 code, I'd like to hear from you.

Ok i'll try to avoid forking :)
But I will (have to do) if we can't agree on some important change later,
since getting the issues solved is more important for me than waiting years
for some api change or end of code freezee :)
(I just don't want to fight against others too much to get my patches
accepted. When i did AMC, i knew that those changes are not clean and will
never be accepted to the official code, or if they will be it's even worse
because it means that clean code is not a goal... but the more important
reason was that gmc mess all around in 4.5.x...)

  It's amazing to see that it's still under development and the goal is
  again making a stable bugfree console tool instead of yet another
  winblows-exploder or win-commander clone for 

About urar in 4.6.0-pre3

[Andrew Borodin]

  Greetings!

  My previous message about urar problem is here:
http://mail.gnome.org/archives/mc/2003-January/msg00044.html.
The Andrew Samoilov's patch (in Andrew's reply to my message) works fine,
but it is not applied in pre3.

  Regards,
  Andrew.

___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: About urar in 4.6.0-pre3

[Pavel Roskin]

Hello!

   My previous message about urar problem is here:
 http://mail.gnome.org/archives/mc/2003-January/msg00044.html.
 The Andrew Samoilov's patch (in Andrew's reply to my message) works fine,
 but it is not applied in pre3.

Applied now.  Thank you!

-- 
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: rpm --nosignature

[Andrew V. Samoilov]

Pavel Roskin wrote:

Hello!



It could be a good idea to remove the --nosignature options (rpm)
from the extension files. As an example, neither Mandrake's RPM 4.0.3
(Mandrake 8.2) nor 4.0.4 (Mandrake 9.0) has this option.
(Is it RH-specific, or is it only present in newer versions?)



The CHANGES file in rpm-4.1 says that --nosignature appeared in the
version 4.1.

I wanted to suppress the warning about signature but retain other error
messages.  I didn't know that it's a very new option.  I think I'll remove
it for now and redirect all errors from rpm to /dev/null.


Fixed in CVS:
2002-12-29  Andrew V. Samoilov  [EMAIL PROTECTED]

* extfs/rpm: Use --nosignature only if rpm supports this.

--
Regards,
Andrew V. Samoilov



___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel

Re: title refreshing (xtt) and the 4.6.0 release

[Pavel Roskin]

Hello!

 The patch using the Xlibs is 'clean' and efficient for refreshing the
 title on a _local_host_.

 Tested various combinations of Solaris 8, 9, Linux kernel 2.4.17 xfree86
 4.1.0, 4.2.0, 4.2.1 with 6 or 7 different terminals, but have yet to
 reconfigure one or two solaris machines to test with the XSun xserver.
 All favorable results on a local machine.

I'm really surprised by the amount of interest to this topic and by the
amount of time spent on it.  I even start thinking that maybe I shouldn't
have applied the patch for changing the title, because the time spent on
this issue could have been better spent on something else.

  - It can't really be done in less than 100 lines of code.
 (at one point I had 250 lines)
 As a non-critical function, to avoid bloating main.c,
 should it be moved out to something like xtt_restore.c ?

I'd rather remove 10 lines to set the title than add 250 lines to restore
the title.

 - For use on a local host, a delay in the request/read xtt
of a few millisec using usleep() resolves any mis-reads
of  the output from \033[21t . But on a remote host,
the delay can't be less than one second. Because most
users are on a local host (correct me if I'm wrong),
the default delay should be set for local. Then, for remote
host sessions, the delay for the timeout could be adjusted
on-the-fly (by editing $HOME/.mc/ini or even better,
by a command line option like mc -r).

Just imagine that you know nothing about mc and you are reading the help.
Would you understand what this is about?  I can imagine that some users
would be confused and will blame unrelated problems on the incorrect
delay.  I can imagine users writing a wrapper around mc to set the
timeout correctly if they log in remotely.  Yet the same users will close
mc together with the terminal without ever needing the saved title.

On exit from mc, just print something generic like:
xterm: [shell] or username@hosname
 to overwrite the hanging xterm_title.

It used to be Thank you for using GNU Midnight Commander in 4.5.55.
Too long for my taste.

I think that if you expect the audience of the patch (i.e.  those who
really care about the title after they exit mc) to edit $HOME/.mc/ini
and/or give command line options when running mc remotely, then probably
the same users won't have any problem adding something like this to the
environment:

PROMPT_COMMAND='echo -ne \033]0;${USER}@${HOSTNAME%%.*}:${PWD/#$HOME/~}\007'

It's standard in Red Hat 8.0 and it sets the title after every command,
not just mc.

-- 
Regards,
Pavel Roskin
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel