RE: midnight bug - feature request :))


Thanks for your help, it seems that I solved the problem. Anyway I
answer your letter. :)

Either you have two different mc executables, or they are run 
You are right. The working midnight commander is version 4.5.99a. The
snapshot versions have the bug.

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? 
Yes, the mc from the Debian 3.0 release.

 mc recently switched the internal S-Lang to version 1.4.5 - 
that can be the reason.
I don't understand it.
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.
It seems to works well, except the colors are totally different (red
background - no blue, etc).
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.
Putty can work as an xterm emulator, you can set it at it's
configuration settings.
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 seems that the problem was really with PUTTY, my ssh client. I don't
know what's really, but after I created a new connection for testing for
the same server, everything works well. Strange "feature". Thanks for
your help. I tried to do the same as you: create a new connection
without settings for the screen size, font and other things, and it
worked. :) Sorry for it, I thought that the problem somewhere about the
configuration files or the rights.

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.

Well, bash works the same way with it's history. I don't think this way
is the bad way. :)
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.

It would be a great thing. My problem is the opposite: going to the end
of a large file... Of course I think storing last position should be a
feature, that you can turn on, or turn off globally. It can be strange
for the first time, that it stores 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 you misunderstood me. Here's another example. I checked how FAR
works, this example explains that:


When I'm position A, let the position B highlighted.

 A  B

 0  -
 1  -
 2  2,10
 3  3,5
 4  3,5
 5  3,5
 6  3,5
 7  7,9
 8  7,9
 9  7,9
10  2,10
11  2,10
12  -

So it highlights both bracket. If i'm on a bracket, then the pair is
evident. There is another rule: when I am after a closing bracket (and
i'm not a bracket again), then the pair is the closing bracket and the
other belongs to it. I don't think it's confusing, because it's totally
evident which to brackets are currently shown. The difference between
the current working of mc and this is just that it highlights brackets
when you are after a closing bracket, too. I think it help you, when you
are currently typing a difficult expression, and would like to know, if
you closed all brackets, or not? How do you know it now? You have to go
back to the last bracket to check, if the opening bracket that belongs
to it is the first or not?

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.

I don't speak C well. :(

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.

But it won't be wronger, too. If you solve that problem, it won't be a
problem... :)

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".

Well, these are just a few things are I _really_ miss. I don't like
emacs, vim, because they are too difficult, and not thinks the same way
I am. MC do it well... That's why I ask it from you: there is no other
solution for me.


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