RE: midnight bug - feature request


Well, I've tested it more. There are 3 mode:

 1. i'm "boogie"
 2. i'm "boogie / su / i'm "root"
 3. i'm "boogie / su - / i'm "root"

If I do the 2, just that way I have no problem. When I do like 1 and
like 3 the problem exists.

Looks like something with PATH and possibly with aliases or functions.  
Are you sure it's the same copy of mc?  Can you run "mc -V" is each case 
and compare?  Can you run mc with full path?

I have never seen anything like that.  It's almost certainly - a picture about it... :)

I have never seen that.  Check info.c - the black area after "Mode:" is 
filled with spaces, just like the space later in the same string, that is 
displayed correctly.  mc outputs the same spaces, by the longer gap is 
rendered black either by the screen library (included S-Lang) or by the 

a bug in putty.  I need the version of putty, the value of 
Why I don't think so, is that no problem when i'm a root user, but
problem, when i'm "boogie". And putty don't know, who I am.

Either you have two different mc executables, or they are run with
different options, or it's using different terminfo databases, and putty
is incompatible with one of them.  Please compare the output of "infocmp"  
as root and as normal user.

The other reason is why I think that not putty is buggy, that MC that in
the Debian release works well.

Sorry, I'm not familiar with Debian.  This sentence makes no sense to me.  
Maybe 3.0 is not a release?  Or you mean mc from the release?  mc recently
switched the internal S-Lang to version 1.4.5 - that can be the reason.

Anyway, of course it possible that still putty is the problem. If you
can tell me another ssh client for windows, please do, I will test it
under that, too.

Teraterm Pro.  It uses vt220.

the TERM environment variable (echo $TERM) and the output of
It's the same as root and as an user: xterm.

I don't know any other xterm emulator for Windows except xterm from
Cygwin.  It requires XFree86 for Cygwin.  It may be too heavy for you, but
you can try it.  Cygwin comes with OpenSSH.

The version of my PUTTY is the today's snapshot: 2002-11-08. I have
tested it with 2002-10-26 snapshot, and with the stabil release: release
0.53b. You can download them from

I could not reproduce the problem under today's snapshot of Wine with 
putty 0.53b.

I'm just using xterm. Anyway, you can get my infocmp output here:

I installed it and I still cannot reproduce the problem.  I put my
screenshot here:

It works like the command history is working now. When you leave a file,
mcedit will store your position. The last 20 position will be saved in a
file. It's okay that way as the command history is working. I think that
stores the commands, when I'm exit from midnight. I think it's okay to
store the positions in memory, and when I leave, store in on the disk
for the next time. If you don't store it on the disk, just in the memory
then that will be still okay for me, but maybe better to store/restore
to/from disk as the command history.

Interesting that I never liked this approach (the last mc to exit saves
the history), but users have never complained, so it's probably OK for
other users.

I often exit and enter a large file as a shortcut to go to the beginning
of the file.  It's faster than Alt-L 0 Enter.  Perhaps we should make
Ctrl-PgUp and Ctrl-PgDown work at least on some terminals out-of-box
before adding the feature to store the last position.

For example I am writing a program. I write x=((a+b)-(c+d)). My cursor
is after the last closing bracket. The inconvenience is that I have to
go back one position to see, which opening bracket belongs to my last
closing bracket. I ask for that I wouldn't have to go back one, just
show the opposite bracket this time, too.

Now, what should happen if your cursor is on the last bracket?  Like this:


Should both opening parentheses be highlighted?  Should different colors 
be used for them?  Should this rule apply to the cursor after opening 
brackets?  Like this:


I think it would be too confusing.  I don't need this feature.  If you
need it, make a patch and post it to mc-devel gnome org   Don't forget to
comment your patch.  Maybe some of the developers will be interested.

The way I described the working of it (storing in memory, then save it
to disk when you close midnight) is solved now, the command history
working the same way, isn't it?

There have been reports that the learned keys are lost.  The command
history is lost too.  I've seen it myself.  Adding more things to save
won't make the situation any better.

mc is full of patches based on the principle "if I do it just like the
other guy, it should be OK".  At some point the answer becomes "no".

Pavel Roskin

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]